Comparing The Power/Performance Of A NetBurst Celeron & Pentium 4 To Broadwell's Core i7 5775C

[phoronix]

Phoronix: Comparing The Power/Performance Of A NetBurst Celeron & Pentium 4 To Broadwell's Core i7 5775C

With my Intel Core i7 5775C Linux review having gone out earlier this week, out of curiosity one of the other follow-up tests I wanted to run was comparing the performance and efficiency to an old Pentium 4 and Celeron Socket 478 CPU from the NetBurst era.

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

[s_j_newbury]

Michael, as I commented last time, what's the point of benchmarking a NetBurst CPU using -march=i686 -mtune=generic? Modern GCC does emphatically not optimize for NetBurst with a generic x86 target! -march=native would probably give a huge performance improvement. I remember back in the day how badly Pentium3 optimized code ran on the Pentium4, the Pentium3 was usually faster even with the CPU clock disparity!

[schmidtbag]

Michael, as I commented last time, what's the point of benchmarking a NetBurst CPU using -march=i686 -mtune=generic? Modern GCC does emphatically not optimize for NetBurst with a generic x86 target! -march=native would probably give a huge performance improvement. I remember back in the day how badly Pentium3 optimized code ran on the Pentium4, the Pentium3 was usually faster even with the CPU clock disparity!

I'm sure the results would still be so black and white that any optimizations wouldn't really make a difference. It's not like anyone here is expecting the P4 to still be considered a worth-while product.

To me, one of the nice thing about tests like this is how, whether optimized or not, they're a good way to show that people holding onto these old machines are wasting time and money.

[Gusar]

A big difference in performance comes from simply having more cores to throw at the problem. That's why single-threaded tests would be nice (x264 can be told how many threads to use), to see how much performance comes just from having a newer architecture. Bonus points for another additional test that also disables instruction sets NetBurst doesn't have (SSE3, AVX, ...) - x264 can do that too, by using "--asm mmx2,sse2,sse2fast". That's just playing around though, but a single-threaded test would be of interest I think.

off-topic rant: Man, I *really* hate this forum's completely stupid "Paste, Add Table" right-click menu instead of doing something sane like, you know, presenting the browser's menu!

[user82]

When stuff actually developed in the right direction.
Do it again in 10-15 years and everything single-threaded will see a laughable boost compared to this, but it can run at 1Watt, which is useless for Desktop.

[Michael]

Michael, as I commented last time, what's the point of benchmarking a NetBurst CPU using -march=i686 -mtune=generic? Modern GCC does emphatically not optimize for NetBurst with a generic x86 target! -march=native would probably give a huge performance improvement. I remember back in the day how badly Pentium3 optimized code ran on the Pentium4, the Pentium3 was usually faster even with the CPU clock disparity!

It was just done at the defaults at the time, so that's how the testing remained today with being the reproducibility. Besides for most out there that's how the performance is/was aside from the source distributions or those rebuilding all their packages. Even if the P4 performance were still to double, as schmidtbag pointed out, it wouldn't gain much ground against the i7-5775C and the findings of this testing. For the march=native optimizations on x86_64 with the Broadwell system its performance too would have went up.

[AJenbo]

I would like to se a x86 vs x86_64 on old hardware, somthing like P4 or Core 2 Duo.

[Michael]

I would like to se a x86 vs x86_64 on old hardware, somthing like P4 or Core 2 Duo.

I've been running such comparisons routinely for years, going back a ways I think I recall some Core 2 Duo or Quad tests.

[jakubo]

no offense but I do agree with the others, that this test - a multicore with hardware optimisations against a crusty old piece of ... well you know... a single core. Some sort of gentoo setup with native CPU optimisation and reduced core count could have told something about IPC, efficiency, handling of context switches or whatever. even quantitatively to some degree... in this case you can only say: look its faster! as expected. (hooray!)
I mean seriously, there will be exciting tests ahead, fiji, new Mesa capabilities, maybe some compiler tests - i dont recall seeing any in quite a while. will HSA affect the kernel scheduler by the way? maybe this is stupid but i really have no clue. It would only sound natural to me... Or simply take a day off. clean your head. focus on what is really important. Really no offense but reading this article was like... "Oh look, hes got quite some time to spare"
otoh if you wanted clicks... you certainly got them

[Gusar]

no offense but I do agree with the others, that this test - a multicore with hardware optimisations against a crusty old piece of ... well you know... a single core.

Well, I think the test as done already has merit. It does show how far we've come, especially in terms of power efficiency (schmidtbag makes a nice point about that). And most distros do not provide per-cpu optimized binaries, but generic ones. Not to mention that x264 (and probably flac too) has hand-written assembly for all the hot paths, so compiler flags won't make much difference. So I have no problems with the test as such, it's already interesting. I just think using a single thread would provide a nice addition.