Cooling The Raspberry Pi 4 With The Fan SHIM & FLIRC For Better Performance

[tuxd3v]

And sure, 1-3 dead pixels is fairly normal for a used product after some time and is probably not covered by warranty but for a new product I think it really should be none. Maybe I'm used to too good.

Even Apple, don't return your LCD with death pixels on it..
Other vendors the same..

I don't recall now,
What is the mount of dead pixels, but I think, is his measured per inch( I am not sure right now the ratio.. ).

Its used by all players in the market..

[tuxd3v]

Yeah, I saw those specs, too.
But, as I said about DRAM clocks, you can't just latch on to a couple specs and use them to characterize the performance of the entire system. There's a lot more to the A73 than that.

Here's a good overview of the A73. Particularly, the second page goes into some of the various performance improvements it contains:

I saw that big article you showed,
and it basically states the same thing I guessed in my previous comment..

With some things more,
like optimisations in the decoder, and launching uop from there on. instead of doing that in the dispatcher..
They were made by ARM France Team,
Even tough that there are a great degree of true, on that..., its not a universal truth..

Why?
Because they state that the improvements are so great that you can decode in one cycle( but only some intructions can be decoded in one cycle...they say the majority...).
What is the majority???
If my application only uses the minority of them...is my application faster? OfCourse not..

Its an improvement for the decoder?
Maybe, if you rely in that specific instructions then yes, it his, otherwise no, but it could be a improvement for the dispatcher, the uops since are smaller they do less things each one, and so, the pipelines are shortened, it could lead to less latency, that I 'guessed' in previous reply..

They have done improvements in the dispatcher, but I don't consider them so important, has the improvements in the decoder..
This changes are the most significant, in the decoder/dispatcher, in my opinion, for them to use the word 'optimisations'..

But the article also states there there are situations were you have degraded performance..since they share lots of resources between execution units..
A72 have this resources for each execution unit
OfCourse that could mean more power consumption, but 'there are no launches'..and the same article also states that sooner or later they will have to increase the decoder with again, like in the A72..

The biggest improvement they state, is theoretical is 15%, there are also there a 10% improvement in other thing that I don't recall now..
But IMO, you should not add improvements percentages arithmetically, because it doesn't work that way..

That article just plotted values from a different wikipedia page, which seems to have changed since the article was written.

Well I think, the values for A73 were retrieved from the A72 metrics, has a base..
But they only put there a 6.35 DMIPS/Mhz, they dropped the maximum value that A72 could achieve( 7.4 DMIPS/Mhz ), and after that article you showed, its now clear why..

Since the execution units on A73 share resources between them,
When one is using a resource the other one cannot use it, so they stamped a 6.35 DMIPS/Mhz, for A73, and forgot the maximum value the A72 can achieve which is 7.4 DMIPS/Mhz...

Also you can see by yourself,
RK3399,
Has 2x A72@2Ghz + 4x [email protected]
S922x
Has 4x [email protected] + 2x [email protected]

So you doubled the big cores, you even boost the frequency of them,by a considerable margin, you boost the frequency of the A53 too, Again by a considerable margin, and you achieve around 30% improvement over RK3399?

I would be expected something between 40-60% more at least..

I don't really understand your preoccupation with node size. The SoCs we're talking about only come in one node size, each. So, they should be judged and compared as is. Because that's how they're actually used, not based on some theoretical performance estimate of a different node size.

Agree,
I spoke about 16nm, because A72/A73 share that node size( both can be made in that node size.. )
The Idea was to compare side by side on same frequencies/node size..

Ofcourse comparing by Soc, s922x has half the node size, and that its important..

[coder]

I saw that big article you showed,
and it basically states the same thing I guessed in my previous comment..

Not really. They go into quite a bit of depth in areas where the architecture was improved to reduce things like pipeline bubbles and so improve the typical case, even if the best case isn't as good as the A72.

Because they state that the improvements are so great that you can decode in one cycle( but only some intructions can be decoded in one cycle...they say the majority...).
What is the majority???
If my application only uses the minority of them...is my application faster? OfCourse not..

If you read the whole article, they say it's the vector instructions that take two cycles to decode. The reason is probably that vectorized code tends to be in loops that are larger and more easily branch-predicted, so an extra cycle in the pipeline isn't a big deal for them.

The biggest improvement they state, is theoretical is 15%, there are also there a 10% improvement in other thing that I don't recall now..
But IMO, you should not add improvements percentages arithmetically, because it doesn't work that way..

You can try to guess how the performance improvements stack up, but you forget that they're each estimates for some particular workload, and they might react differently to different workloads. Again, what you need is real-world benchmarks, like the ones on ODROID's N2 page, rather than a lot of guessing.

Well I think, the values for A73 were retrieved from the A72 metrics, has a base..
But they only put there a 6.35 DMIPS/Mhz, they dropped the maximum value that A72 could achieve( 7.4 DMIPS/Mhz ), and after that article you showed, its now clear why..

I think it's a waste of time to argue about Dhrystone MIPS, but start by find a reliable source for these numbers and then we'll talk. IMO, it's less relevant than any of ODROID's benchmarks.

Also you can see by yourself,
RK3399,
Has 2x A72@2Ghz + 4x [email protected]
S922x
Has 4x [email protected] + 2x [email protected]

So you doubled the big cores, you even boost the frequency of them,by a considerable margin, you boost the frequency of the A53 too, Again by a considerable margin, and you achieve around 30% improvement over RK3399?

I would be expected something between 40-60% more at least..

Okay, so we're now comparing SoCs. So, where did you get 30%?

[Raphexon]

"S922x
Has 4x [email protected] + 2x [email protected]"

The A73 cores of the Odroid N2 are clocked at 1.8 ghz. (Their A53 cores at 1.9 ghz)
While the S922x can be clocked higher, Hardkernel has decided on 1.8 ghz, not 2.21 ghz. (For the A73 cores)

And the A53 on the RK3399/S922x can reach 2 ghz, though I don't think any of the boards will sustain that frequency without a good heatsink.