Introduction

Dothan is something that both perplexes and intrigues us at the same time. Not quite a Pentium 3, not quite a Pentium 4, and not quite something that is entirely different either. Meanwhile, the NetBurst architecture has come under serious strain over the last few years, particularly since Intel's Prescott launch. Is Intel still capable of killer products? And more importantly, do they still dominate on Linux?

As many who follow our Windows reviews know, Pentium M on the desktop is something a few years in the making. Even when the original 130nm Banias processor showed up in 2003, reviewers and customers alike were astonished with the technology. Intel received even more praise when their 90nm Dothan chips of the same product line showed up - utilizing less than 30W during peak operation and less than 5W on idle. Most of these advancements were due to Intel's controversial strategy to rethink the P6 architecture and refining a particularly interesting technology called Enhanced Speed Step. Enhanced Speed Step, also known as EIST, gives the operating system the ability to dynamically clock the processor. Typically, Windows will dedicate the full 100% of the Dothan's clock during intensive operation, but throttle the processor as far down as 10% of its capable speed when the computer is just idling. Thus, Pentium M has achieved incredible status among overclockers and HTPC enthusiasts - on Windows. Today, we will briefly explore the versatility of Pentium M on the Linux desktop. Lessons learned should also apply to the notebook market as well.

That being said, there are already a few fundamental flaws with the Pentium M architecture on Linux, the largest of these being compiler optimizations. While Opteron/Athlon 64 and Pentium M share substantial optimizations from every corner of the OSS universe, Pentium M receives very little regular attention. Dothan/Banias are slightly cursed, since most Linux OSes are built on the - mtune=i686 flag, which specifically tunes compilation to the P6 core (Pentium Pro), from which the Pentium M is derived. Why is that a curse and not a blessing? Although Dothan and Banias certainly share some key elements with the P6 architecture, they are far from it. Pentium M's Micro Ops Fusion, local branch prediction and general optimizations across integer division and register access are completely ignored by the compiler, even when setting - march=pentium-m, since most compilers (particularly anything before GCC 3.4.2) tend to just categorize Pentium M as a P6 processor with a higher clock.

Of course, the Intel C compiler, ICC, behaves very differently, but unfortunately, isn't very free either. We have a few tests today that include the non-commercial ICC as well and we see how they stack up against GCC 3.4.1. So, if it doesn't bother you that the majority of Linux sees your new Pentium M as a glorified Pentium Pro, without further ado, let's check out how it actually performs against other processors that we have looked at in the past.

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