Intel Core i7 990X Extreme

[phoronix]

Phoronix: Intel Core i7 990X Extreme

For those willing to spend $999 USD on a new processor, Intel has a new Core i7 part out that is stunningly fast. The Core i7 990X is the $999 successor to the previously reviewed Core i7 970 that ups the core frequency to 3.46GHz and provides a 3.73GHz Turbo Boost frequency. This six-core CPU with Hyper Threading works wonderful with Linux.

http://www.phoronix.com/vr.php?view=15880

[popper]

yet again Michael if you didn't use such an antiquated x264 you would see a far greater speed improvement,not to mention get a far more accurate account of real speed of diffident grades of CPU today.

isn't it about time you made the effort and pulled a current x264 git and made a generic side be side comparison against this antiquated unmaintained v2010-11-22 x264 test, after all it's 2011 and faster AVX 3 operand paths assembly code exists there now.



for sure the i3 and i5 and i7 sandy bridge can do better than this today with a current x264 git
git clone git://git.videolan.org/x264.git

[Michael]

yet again Michael if you didn't use such an antiquated x264 you would see a far greater speed improvement,not to mention get a far more accurate account of real speed of diffident grades of CPU today.

isn't it about time you made the effort and pulled a current x264 git and made a generic side be side comparison against this antiquated unmaintained v2010-11-22 x264 test, after all it's 2011 and faster AVX 3 operand paths assembly code exists there now.

I have a lot of things on my TODO list... You know, you or anyone else interested are also able to provide test profile patches that update the x264 pull.

[sabriah]

Wow! The differences in the different benchmarks were indeed a lot greater than I had anticipated.

The different performances at OpenSSL encryption and 7-Zip were particularly interesting, definitely showing the differences and trade-offs in architectural designs.

Thanks!

[mtippett]

isn't it about time you made the effort and pulled a current x264 git and made a generic side be side comparison against this antiquated unmaintained v2010-11-22 x264 test, after all it's 2011 and faster AVX 3 operand paths assembly code exists there now.

It all depends on what you are comparing - or the variant part of the configuration under test. For these tests, Michael is comparing hardware against a set of pre-existing tests. The x264 test for the most part doesn't really matter too much, it's about how the hardware performs against other systems with the same test.

You can switch to the OPC view in http://openbenchmarking.org/opc/1103264-IV-1103164IV67 and see where they stack. if x264 is updated, it will invalidate those results for other systems and hence you won't be able to see where the performance stacks up against the other results in openbenchmarking.org.

Of course, the "antiquated version" of x264 will be similar to the one that is in most of the active distributions, so of course the relative x264 performance that Michael has reported on is realistic.

Reading your comments, you seem to be looking at a 2 dimensional comparison. You want to see how the variants of hardware work against different versions of x264. There are a lot of times where the headline ("Now supporting AVX") and the reality don't match. But you'll have to bench it to determine.

for sure the i3 and i5 and i7 sandy bridge can do better than this today with a current x264 git
git clone git://git.videolan.org/x264.git

If you feel strongly, why don't you pull down the 20101122 snapshot and the 20110405 snapshot and do some local benchmarking to ensure that this is correct?

PTS3 + Openbenchmarking.org give you all the tools that you need to show clear differences between the older and new versions.

I'd also expect that Michael would accept a patch if one was created.

Matthew

[devius]

How the hell can the i7-970 beat the 990X in C-Ray when all the other tests are the other way around (as would be expected)?? There has to be a problem in that test.

[deanjo]

It all depends on what you are comparing - or the variant part of the configuration under test. For these tests, Michael is comparing hardware against a set of pre-existing tests. The x264 test for the most part doesn't really matter too much, it's about how the hardware performs against other systems with the same test.

I have to respectfully disagree Matthew. The test should have been ran with an updated version to show the gains to be had when optimized for the tested hardware. It is the only true indicator of real performance as it takes advantage of the hardware capabilities. This is also why PTS recompiles the source upon detecting of another system. Tom's hardware did this same type of test where they compiled it on one machine and then swapped the drive from machine to machine without any recompiling. The results were a complete sham and easily spotted when they had Core II's pounding Phenoms in openSSL for example where if it was simply recompiled it would have shown a much different result. Hate to bring a vehicle comparison in here but you wouldn't do a head to head between a Ferrari and a Cavalier using 87 octane gas and say "this is the real performance of the Ferrari".

It is when you bench distro vs distro then keeping the same version is important but even then since almost everyone uses the prepackaged libraries that is what should be tested in a distro vs distro comparison. Not compiled from source.

Of course, the "antiquated version" of x264 will be similar to the one that is in most of the active distributions, so of course the relative x264 performance that Michael has reported on is realistic.

I have to disagree here as well since most distros use a very up to date version of x264 and is a very common update on all distro. In openSUSE for example there is usually a new svn snapshot that is used every month on Packman.

[deanjo]

This is how the tests should be done depending on what you are benchmarking.

Distro vs Distro -----> each distro prepackaged packages only

Hardware vs Hardware ----> Same distro, latest optimized code of library.

Package optimization ----> Pre-packaged vs self compiled again with latest version of the library (Multiple systems would be preferable here as well as they may have different optimizations based on things like CPU)

[disi]

I have a laptop with i7-2820QM, that's probably the equivalent to 980 as mobile version. It feels much slower than my desktop running the AMD Phenom II 965 X4 B.E.

The laptop has 16GB RAM 1333MHz that's double than the desktop (and the crappy Asus Formula III detects of my 1600MHz only 1066 anyway).
The SSD in the laptop is the Intel X25-M 120GB rather than the slower Imation M-Class 64GB in the desktop.
The graphics card is Nvidia 460M in the laptop rather than the ATI HD4770 in the desktop (I already hate the nvidia binary driver).

So the question is, why are mobile processors sooo much slower than desktop processors? The laptop has 2.3GHz to 3.4GHz with Turbo. My desktop has just 3.4GHz for each core.

Anyway, everybody and every single benchmark promised me the Intel core would outperform my ~3 year old AMD processor in everything -.-