Hardlimit test bank

[cobito]

@NakedCOOL has brought us a kind of rarity as it is a single-core Athlon II that was marketed in 2010. I am not too sure about the end of the single-core era on the desktop, but this must have been one of the last models (someone correct me if I am wrong).

It is impossible to compare as its single core has a performance similar to the first processors of the Core era. Of those I have found a model (that is not in our database) that is a Peryn Core 2 Solo, appeared a year before this one. Coincidentally, the most similar model is also a Peryn, but with two cores so this Athlon II is possibly a competitor of the ephemeral Core 2 Solo. Looking a little more, Intel only released 4 models of this type, the last one from 2009. The models are the Core 2 Solo ULV U2100, ULV U2200, SU3300 and SU3500. After those, I do not see anything else single-core from Intel for desktop or laptop. Now, in October 2013 appeared the last Intel processor of a single core that I have found: the Atom E3815 intended for industrial and automotive fields.

Looking for AMD processors and more specifically about the Sargas core (like the one in this Athlon II) it turns out that there are only two models: this one and the Sempron 150, both from the same date. So yes, this Athlon II 170u is one of the last of its kind.

Its performance, as I have said, is comparable to one of the two cores of the Core 2 Duo T6600.

[cobito]

A few days ago, @krampak brought us an i7-9900K. The processor was already in the database and that's why it hasn't been published on the front page. The thing is that the CPUID of his micro is 906ED while the 9900K of @Xevipiu has CPUID 906EC. I noticed this because the CPUID is taken as a reference along with the processor name to identify it within the database and the fact that there are two models exactly the same with different CPUIDs causes a small problem that I will have to solve (it's the first time it happens).

The thing is that when looking for it, it turns out that the 906ED corresponds to an i7-9900 plain and looking a little more I found that sometimes Intel renames models, that is, that instead of having marked this as a 9900 plain, it has marked it as K. The result would be that sometimes 9900K come out that actually have something less performance than the 906EC.

The truth is that this statement does not give me much confidence. Both the micro of Krampak and that of Xevipiu have exactly the same performance per clock cycle, although it is true that the one of Xevipiu goes to a frequency 2.5% higher (I take this percentage as a variation similar to the measurement error).

Do you know what this is about renaming models? Is it something new or has it been going on for a while?

[Sylver]

@cobito said in Hardlimit test bench:

A few days ago, @krampak brought us an i7-9900K. The processor was already in the database and that's why it hasn't been published on the cover. The thing is that the CPUID of his micro is 906ED while the 9900K of @xevipiu has CPUID 906EC. I noticed this because the CPUID is taken as a reference along with the processor name to identify it within the database and the fact that there are two models exactly the same with different CPUIDs causes a small problem that I will have to solve (it's the first time it happens).

The thing is that when looking for it, it turns out that 906ED corresponds to an i7-9900 plain and looking a little more I found that sometimes Intel renames models, that is, instead of marking this as a 9900 plain, it marked it as K. The result would be that sometimes 9900K come out that actually have something less performance than 906EC.

The truth is that this statement does not give me much confidence. Both the micro of Krampak and that of Xevipiu have exactly the same performance per clock cycle, although it is true that Xevipiu's goes to a frequency 2.5% higher (I take this percentage as a variation similar to the measurement error).

Do you know what this is about renaming models? Is it something new or has it been going on for a while?

Little idea about it... What sounds most similar to me is the stepping, in previous micros it happened that depending on the stepping a same micro could perform a little more or a little less, directly translated into frequency and temperature (the "black foot" were the best). In fact, in some generations those with the "worst" stepping even presented incompatibilities with certain technologies or applications, such as multiGPU, etc.
I don't know if this has something to do or in essence will be similar, but in general we always find that there are no two micros exactly the same.

Greetings!

[krampak]

@cobito From what I could find, it seems to be due to revisions of the same (as @Sylver says the old stepping that we gave so much importance back then). In fact, BIOS updates are needed in some cases to have support for the new microcode because there is a direct relationship (I understand) between the stepping and the microcode they use.

906EA stepping U0, 906EC stepping P0 and 906ED stepping R0.

On this Intel page, you can see the microcode updates:

https://support.microsoft.com/en-us/help/4494452/kb4494452-intel-microcode-updates

You will see that the 906EC has been updated to 906AE (I don't know if the ED that I posted was in between).

[cobito]

@garfield brought us a few days ago an i7 from the U series last year. You have a brief analysis in this entry of the cover.

[cobito]

@Namiga brings us results in all modes of the Core i7-9750H, a Coffee Lake that has been on the market for about half a year. It is a micro laptop from the H series, that is, with a TDP of 45W.

Front page entry

[_Neptunno_]

@cobito it's my first time doing the Bench, I hope I do it well:
https://bm.hardlimit.com/result.php?bm=bf730e652198cbd6abed40a3fe6b4f251671

For now I passed it with an FX 8350 + 16GB DDR3 1866Mhz.

Greetings!!

[cobito]

@_Neptunno_ works perfectly.

Here you have a mini analysis of the processor. It's a Piledriver so it doesn't really stand out in anything. Maybe it offered a better performance/price ratio than Intel's options, but I don't know.

[cobito]

@Mystique has brought us a Ryzen 5 3600 of which you can see a brief review here.

[cobito]

@krampak brings us a very interesting Ice Lake SoC. You have a mini-analysis here.

[_Neptunno_]

Finally I passed the test to the Ryzen 5 2600X + 32GB DDR4 3000mhz + X470:
https://bm.hardlimit.com/result.php?bm=1c02791218ecb4925d29503ce8709aa11678

Greetings!!

[cobito]

@_Neptunno_ Here you have the datasheet. @rul3s already brought us some results this summer. It seems that his results are a bit better I suppose because his memories are faster.

[cobito]

@Namiga brings us an i5-9600KF, a 6-core Coffee Lake that ranks third in the overall single-thread ranking. Here you have a mini-analysis.

[_Neptunno_]

@cobito said in Hardlimit test bench:

@_Neptunno_ Here you have the datasheet. @rul3s already brought us some results this summer. It seems that his results are a bit better, I suppose because his memory is faster.

Well yes, and he has better hands than me

[cobito]

@hAyO brings us a Ryzen 5 3500U that has just turned one year old this month. You can find a mini-analysis here.

[cobito]

A few minutes ago, @krampak brought us an i5-9500T with a not negligible efficiency (performance/TDP ratio). Here is a mini analysis.

[cobito]

After nearly two and a half years without an update, version 1.3 of the program is now available. The changes are exclusively internal (nothing aesthetic). There are two important changes:

· The maximum number of threads increases from 32 to 2³²-1. Let's hope that, with the war of cores, this version lasts a couple of months, even if it's . As before, it will be allowed to run twice as many threads as detected, so if you have a processor with 16 or fewer execution threads, you won't notice the change.

· During debugging tests, it was detected that in certain configurations, the execution threads are launched very unsynchronized. This falsifies the results because at the beginning of test#1, not all threads have started executing, and at the end of test#4, executions start to finish when there are still tests in progress. In extreme cases, it was detected that the test bank even throws an error because there are several seconds of lag. This seems to be a change in behavior of Windows 10 compared to what it did two and a half years ago, although it has not been possible to reproduce it on all test machines. In any case, in this version, a synchronization mechanism has been implemented that launches the test bank on all threads exactly at the same time.

As usual, if you see anything strange, don't hesitate to comment on it.

The next changes will come from the Central. First, internal changes will be made because currently a C-written engine is used that has become a bit slow with the growth of the database, that is, the response speed of the page will be improved. Then new information, new rankings, different ways of presenting the data and a page in Spanish (in the style of the museum) will be included.

[Sylver]

Excellent work @cobito. I don't know how we can thank you for everything you create for the cause and for us. I really hope that the test bank gains relevance on the network and at least your work is rewarded because you really deserve it.

For the moment I only have the main PC available and a Q6600 that is already in the database, but if everything goes well, later I will return to my previous self, surrounded by gadgets and see if I have any curious ones that I can contribute.

Greetings!

[Clipper]

now it gives different values 28865 /119342 and before 27930 /118270 and I don't think it's because of the hard drive... before an ssd and now a mechanical one.
greetings

[cobito]

@Clipper The differences are 3.3 and 0.9% respectively. They are normal and depend on background processes. The largest difference you have found (in single-threaded) can occur, for example, because during execution, another process starts to consume and the processor lowers the frequency momentarily because it is using more than one core. That difference can occur, for example, by having the task manager open even though it seems to consume little or nothing.

The code of the benchmark itself has not changed. And of course, I have used the same compiler version.

Those who had the synchronization problem (I have seen that it is not common and so far it has only happened to me on Windows 10), will see that the results are now somewhat lower.