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:I wonder if this will be a GPL test case...

[Chalst]

The GPL requires that you be willing to give the source under a GPL
lincense to anyone who receives the binary. Tom would therefore be
entitled to the source. Unless you receive the binary, you would not.

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

Athlon vs. P4 test

[Fervent]

I found the Athlon vs. P4 test, using the recompiled ap, to be quite interesting. The cost performance ratio isn't nearly as great as I thought it would be. True, the P4 1.5 ghz performs better, but not a whole lot better than the Athlon 1.2 ghz. See the picture.

I'm not trying to knock Intel perse. My main machine is a P3 (Dell laptop, runs like a dream). But you have to wonder if the cost warrants, in this case, the extra 3 fps in compression.

Re:What this really tells us

[Greyfox]

Intel's made damn sure that a highly optimized compiler is available for the IA64 and if I recall correctly they've also put a bit of work into tweaking gcc/pgcc to make sure it optimizes pentium code very well.

This is a danger to AMD, which traditionally has had very little to do in this arena. A properly optimizing compiler can make a huge difference and they need every edge they can get to stay on top. Intel understands this weakness of AMD's and will exploit it.

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...

The real problem....

[Kris Warkentin]

is that we've got so many different CPU's and branches within types (how many x86 extensions are there now?) that compiler optimizations don't come close to keeping up. It's all well and good to have these fancy chips but if you don't have compilers to take advantage of the big registers and special opcodes, what good does it do? Linux is ported to lots of different architectures but doesn't necessarily take full advantage of them...take a look at linux distros for UltraSparc - they're still basically 32bit in userland. *sigh* Competition may be good for consumers but it's not so great for developers who have to support 10 million diverging platforms.

Pretty neat.

[dbarclay10]

First of all, I'd like to congratulate the author of Flask(the MPEG4 encoder used in the benchmark). You can't buy publicity like this, and I bet your app just got a whole lot better ;)

I also think we should take note of something. *THIS* is the promise of moving to a new architecture, beyond x86. A program compiled to be backwards-compatible right down to the 386 will NOT be able to use SSE2 instructions, nor any other fancy bells and whistles(like 3Dnow! and plain 'ol SSE). At least, as far as I can tell(I think pgcc can use more advanced instructions and still run on older CPUs).

In essence, Intel is moving away from x86, albeit slowly and painfully. SSE2 is obviously a good technology, but an incompatible one. Programs using SSE2 instructions will need those instructions available when they run, elsewise bad things happen. But what a gain!

If ever you get the chance to talk to anyone from Intel, say that you'd like to see more of this.

Dave

Barclay family motto:
Aut agere aut mori.
(Either action or death.)

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.