Pentium 4 Re-evaluated, Again (Again)

An unnamed correspondent writes: "It looks like Tom's Hardware Guide has been busy with the P4. This time a re-compiled version of the MPEG encoder (the same one they benchmarked with in the last article) shows the P4 doing really well. Also interesting is the performance boost that even the PIII and Athlon procs get from the Intel compiler. Take a look at the article here." Seems that as usual, benchmarks are what you make of them. The P4 apparently can perform much better than initial tests have shown. Tom Pabst makes some good (if fawning) points about the complexity and fairness of benchmarking in general, too.

Comments

Re:The real problem....

[ion]

The real problem is that the cpu makers doesnt give away a compiler for their cpu, or work with
free compilers to create good support for their cpu. Why arent these optimisations in gcc ??

If regular users can not get hold of binaries compiled with good compilers, or the good compilers to compile their own stuff, then their real life usage of the cpu will look worse than the one in the review. The reviews shouldnt be done with special equipment, that being hardware or software, or with the aid of engineers that knows one side only. It should be done with standart equipment so we, the normal users would know what to expect.

Intel, AMD, and other cpu makers, that being x86 or not, give away the compilers, and see your hardware shine, or help GCC getting good support for your CPU, which we, the normal users can benefit from.

ion++
ps: there might be other free compilers than GCC

Quake3 tests also have SSE2 code.

[Silvers]

nVidia has a press release saying the Detonator3 drivers are P4 and SSE2 optimized. That might account for the performance difference.

Urls:
http://www.nvidia.com/Home.nsf/nvidianews2.html
http://www.tomshardware.com/cpu/00q4/001120/p4-20. html

Re:The Pentium 4 Question

[Chris Johnson]

This is a very good point. _Too_ much of a disparity should be considered a red flag, a warning sign. Apparently the P4's performance is really brittle- if you pick just the right task to test it on it can scream, but hit it with something it doesn't like (something that beats on the excessively deep pipeline or doesn't logically break down into simple SSE stuff) and it bogs, it's an absolute pig.

Logically, then, we must all avoid attempting any tasks that the P4 doesn't like ;P

...ok, maybe not. How about some benches on tasks like POV-Ray scenes, SQL operations, kernel compiles? Some of these map more closely to the sort of tasks you'd get if (for instance) you were an EFX house and wrote your own software to do some heinous particle system rendering task. Those are the people who need _real_ CPU speed, and it's really questionable whether P4 is going to be any use to them at all. When you're doing that sort of stuff you have no time to fuss around with wizzy CISC operations- you're writing hopefully bugfree code and running it against a deadline to produce footage that is needed right away if not sooner, and you frankly don't care how Flask does since you aren't using it. You're running fairly general purpose code- a LOT of it- and live or die by your ability to (a) write it as needed and (b) run it. There's no room for "it's 70% as fast as an Alpha but if we spend another month optimising it for SSE we might be able to run it three times as fast, or it might go splat again if we double the number of scene elements or change a line!" no no no...

I wonder if this will be a GPL test case...

[EoRaptor]

FlaskMPEG (http://go.to/flaskmpeg) is a project written by Alberto Vigata and whose source code is available under the GPL http://www.citeweb.com/flaskmpeg/docs/gpl.html

(As an aside, Alberto has been extremely busy of late, and the project has gone a little stale, but it is by no means abandoned, and he has collaberated with several authors to forward the development of FlaskMPEG, though it is slow going)

Intel has taken this source code, produced a modified binary, and distributed that binary to a third party (Dr. Thomas Pabst). Now, the question is, where is the source code? They are obligated under the terms of the GPL to release it, and so far they havene't. Additionaly, they hint that they don't want it distributed, by asking Dr. Pabst not to make the recompiled version of FlaskMPEG available. Is this a violation of the GPL? Probably. Will Intel get away with it? I'd like to see them not, but they probably will.

I'm surprised no one commented on this before, Slasdot goers a usually more on the up than this.

P.S. The DiVX codec is *not* SSE/SEE2 or 3DNow! optimized, though it does have MMX optimizations. How do I know this for sure? Because DiVX is just a copy of the Microsoft MPEG4v3 codec that has been modified with an assembler/debugger to allow the playback of MPEG4v3 streams inside an AVI, and to stamp streams it creates with the FourCC code of DIV3 instead of MPG4. It wouldn't have been needed at all if Microsoft hadn't artificially restricted the codec from creating or playing back AVI files, instead tying it to the ASF format, and therefor to a Windows only platform. Can we say 'Embrace and Extend (just enough to break compatibility)'? I knew you could...

In other news

[smack_attack]

AMD was notably slower in New Mexico as well, in fact it was really too close to call.

Meahwhile, AMD officials were quick to point out that the tests had already proven the "will of the program", which showed AMD ahead by a large margin. Intel was smug as they responded "We will wait for the final benchmark, which will show that we are the faster x86".

Transmeta was unavailable for comment.