Of course, this is with gcc 3.4.3. I'd rather not install 3.4.1 on this system only to rollback to 3.4.3 straight after.

I assume the kernel compile times you showed in the article were from "user" (or user + sys), rather than "real", as the latter is affected by other things happening on the system whereas the former gives the actual CPU time taken by the process.

The results are impressive to say the least. It's certainly extremely puzzling that your results with Dothan were so disparate. One would expect it to do very well indeed based on my results with 1.7GHz Banias + DDR266.

Development on the 3.4 gcc branch has only recently stabilised, and the pentium-m cflag was indeed quite buggy/broken in earlier releases, hence why I stated that gcc 3.4.1 is "pretty old". Not in the absolute sense, but rather in terms of the amount of development work that has gone into the 3.4 branch since.

Some quick benchmarks with gcc version 3.3.4 20040623:
System was P-M Banias 1.7GHz, 768MB DDR266, i855PM; on a Dell D600.
# time make
...
real 9m36.940s
user 8m40.395s
sys 0m39.643s

I didn't have gcc 3.4.3 available on my laptop to test, but gcc 3.3.4 clearly shows the expected performance and hence that there is nothing inherently wrong with the P-M architecture that makes it slow at compiling -- indeed, the 1.7GHz Banias P-M (DDR266, 400FSB) is slightly faster than my 3GHz Northwood P4 (dual DDR400, 800FSB).

I was also interested to see how much faster gcc 3.4.3 was compared to 3.3.4, and so decided to do a compile on my 3GHz P4 desktop machine (same kernel):
real 6m34.443s
user 5m52.910s
sys 0m33.019s

The GCC we used is the same GCC bundled with SUSE 9.1, our test platform. I don't think 6 months is too old for a processor architecture that has been available for close to 2 years. However, we will get a chance to revist these numbers in the very near future, and i will redo the tests with GCC 3.4.3 and GCC 3.4.1

What yozza says is true gcc 3.4.1 is old especially a pre release. As yozza said it has some bugs in it with respect to the pentiu_m march flag.I have been running gcc 3.4.3 for atleast 2 months and i definatly was not one of the first to use itReply

Yozza: I made some corrections. Saying GCC 3.4.1 is "pretty old" seems pretty hard for me to swallow, but the rest of what you say seems correct. I would be interested in seeing your P-M compile time benchmarks.

The march=pentium-m flag was pretty broken on earlier gcc 3.4 releases, and it seems that you're using quite an early "3.4.1 (prerelease)" version, which could explain a few things, especially your TSCP benchmarks, where the Pentium-M is the only one to have its performance _decrease_ with optimised (march=pentium-m) compiler flags. This clearly indicates some issues with pentium-m optimisations in your gcc revision (3.4.1 is pretty old these days).

The extremely slow kernel compile time is especially surprising though. I did some test just now on my 1.7GHz Banias P-M, and the kernel compile times do NOT appear to correspond with your results. So I guess something seems amiss with your system configuration.

There was certainly some pretty impressive performance in the integer-dependent tests such as the database one -- we already know that the P-M's fp performance isn't that great, which explains some of the more fp-dependent benchmark results. I for one was pretty impressed by its performance in the majority of the benchmarks and by its scaling possibilities, both wrt FSB/memory and core freqs. If only Intel would upgrade the platform to 800MHz FSB with dual channel DDR400; such a configuration would be appear to hold a lot of promise.

The argument that "Dothan is adherently a linear processor" doesn't hold water either (it should be "inherently" too), since the kernel compile uses one thread by default. Regardless, it should have been possible to test different CPU schedulers to determine how well Dothan deals with multi-tasking loads, particularly wrt compile times by comparing different "MAKEOPTS=-jX" settings. Behaviour under such loads is as dependent on the CPU scheduler as it is on the CPU itself anyway.

Hence, clearly, the comment "When we stack multiple jobs on the processing queue, Dothan spends a huge majority of its time swapping around" is flawed and incorrect. The implication that the CPU 'swaps around' somewhat like memory paging to disk is rather inaccurate to say the least.Reply

Hmm... maybe you're right... After all, it seemed that PowerLeap was dodging my questions about their P-M adaptor (and then tried to pimp the PL-AXP (basically a golden fingers card for Socket A) - if I wanted to unlock an AXP, I'd get a pencil ;-))...

Problems on the John the Ripper section:
DES: Where's the 755?
MD5: Where's the 400MHz FSB 765?
Blowfish: Where's the 533MHz FSB 765?

Also, for anyone who wants to know what the heatsink IS, x86-Secret reviewed this before the heatsink was available, and they used a MicroCool northbridge heatsink.

FWIW, I don't know why nobody's coupled this thing to an i865/875. It's definitely possible, as Shelton (0K L2 Banias) has been coupled to an i845, and Banias has been coupled to an E7501. And, the fact that Alviso is "i915GL" says a lot. Mobo makers should be able to simply rework the traces leading to the socket, and reuse their P4 board designs for a P-M board design. Or, if they're REALLY lazy, they could just make an adaptor - put the processor in it, and drop it in the socket.Reply

"Encode rate, more are better"? Some encoding rates can't be "more" than other encoding rates. They can be HIGHER, but not "more". I would suggest "Encoding rates, higher is better"

You know what you need? A grammar handbook. Nothing annoys me more than someone who can't conjugate "to be" correctly. I learn conjugations for other languages, the least you can do is learn conjugations for one verb in English. ThanksReply

Shouldn't that read more like "Rendering time in seconds, fewer is better" or "Rendering time, a shorter amount of time is better"? At least something remotely grammatical would be preferable. ThanksReply

Looks like the Dothan falls flattest when it's faced with multiple concurrent threads. Dual-core Dothan solutions might alleviate some of that problem, but, perhaps this is one of the reasons why Intel has been rather shy about pushing multi-core Pentium Ms for the desktop?Reply

It seemed to me that the extra performance 133mhz that the 533 bus provides is rather small. My suggestion is couple this with an 875 or 865 chipset @400mhz and let dual channel memory add the needed performance boost. Its probably the cheapest and most effective way to increase the performance of Pentium M.Reply

I believe that the price of the processor tested should have a more prominent position in the whole test. It's, after all, about the price/performance ratio for most of the consumers.

If you plan on testing GCC vs ICC then I recommend to visit http://www.coyotegulch.com (though the site is "temporarily unavailable"), where you can find comparisons between the compilers, compile settings and more.

The focus of the tests on the site is on scientific applications/algorythms which fit in cache, and is therefore more about how many micro-optimizations are not missed. Which explains why results can vary so much; and also why the ICC compiler, made by Intel for Intel processors, can be sometimes a lot faster than GCC, which does not share the intimate knowledge of the inner working of those processors and targets a zillion other architectures as well...Reply

I wish though you included pics of the fully assembled system. I would like to see that HSF, since it appears AOpen simply uses a 478 type heatsink bracket. But looking at the board at newegg.com, the Aopen board comes with the heatsink, and has DUAL Marvell Gbe, plus it has a SATA controller on it as well, and costs $14 less.Reply

If you want to see the clock speed dynamically adjusted just roll your mouse over the kpowersave daemon running in the tray (at least it works for me under SuSE 9.2). Even my little Via C3 800mhz system will scale from 399 to 800mhz depending on load. It may even work in 9.1 (the part I couldn't enable was the suspend options). Hell, SuSE even can make my Hitachi Desktar drive go quiet to performance mode right in the OS!Reply

This chip seems to be a god-send for the corporate IT directors needing machines for their monkeys to do Word and Excel documents on. As for me though, I don't think I could purchase a chip that has as spuratic performance levels as this. I do so many different things on my box, especially in content creation, that I much prefer the consistant performance of my current Athlon64 proc. across all applications.

Just a suggestion, I would love to see some Adobe benchmarks on these chips... After Effects render times, Premeire Render times, Photoshop performance, etc as these are all applications I use nearly daily. Thanks.Reply

When someone does a full set of benchmarks of the Pentium M for all categories across the board vs A64 and P4, then I'll seriously consider if this chip is worth its salt. Until then, I am unconvinced that it is anything special. If it is so good, then why hasn't Intel made any attempt to push it as a desktop chip?Reply

The Pentium M scales superlinearly with frequency in a few of the time vs. clock-speed benches (and I'm not talking about the 400->533 FSB improvement), which is pretty interesting. I wouldn't have expected a chip like this to get more efficient at _higher_ clocks.Reply

Well FSB533 is here, but 800 would be a more significant move with Dothan. A P-M with FSB800, even DDR400 let's say (rather than the DDR2 that should be supported by using a 915 northbridge), and higher clockspeeds - maybe about 2.4-2.6 Ghz - would be amazing.

Linux performance will of course depend on other factors such as those mentioned in the article, but the performance under Windows of even the FSB400 2.0 Dothan is awesome -- when overclocked to 2.4Ghz, it's able to keep up with, and at times beat, the latest P4 Prescott and EE's, and A64's, for tasks like gaming:

If Intel gave it a FSB and memory speed boost (ie: 533MHz or 800MHz FSB) and DDR533+, then Dothan could really be something.
With Intels talk of dual core processors, a dual core Dothan, with its low heat output, would be awesome (but costly with 2MB of cache).
2x30w = 60w = less than Prescott.

It looks promising, if only Intel would bring it to the affordable desktop :(Reply

Although the Dothan looks to be a superb chip you are certainly overstating its performance here, this is comment is WRT the Shake benchmarks and, effectively, the A64 3200 is twice as fast as the dothan. This would be like saying, for example, a R9800XT holds up well against an X800XT or an AXP2200+ holds up well against a A64 3800+ :-)

Also whilst the DDR400 does improve performance it can't help the Dothan where it is really far behind, the kernel compile benchmarks, for instance, it is still 3x slower than any of the other chips on the chart.

Dothan (or really its derivatives) have loads of potential to compete with the A64 on all fronts (Performance, power, heat, with Intels manufacturing, even cost) given enough effort by Intel (which I'm sure they are doing). I can hardly wait to see widespread adoption on the desktop and, frankly, to see the back of the P4. A desktop Celeron PM (1MB l2, lower FSB) could be the new overclocking king.Reply