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.

The Test
Comments Locked


View All Comments

  • Lynx516 - Monday, December 27, 2004 - link

    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 it
  • KristopherKubicki - Monday, December 27, 2004 - link

    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.

  • Yozza - Sunday, December 26, 2004 - link

    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.
  • larson0699 - Sunday, December 26, 2004 - link

    "...The only additional offering that the 855GME feature provides is a 64-bit PCI-X (not to be confused with PCI-Express) bus..."

    PCI-X is a "feature" of the 6300ESB ("Hance Rapids") southbridge, NOT the 855GME northbridge.

    Other makers used the standard ICH5 southbridge, hence no PCI-X slots.

    Such a system would be awesome for a mini RAID server. An adapter from 3Ware would be the perfect utilization of the PCI-X slot provided. Ahh...
  • vaystrem - Sunday, December 26, 2004 - link

    Why not Gentoo?

    You could do two boxes - compile the entire OS optomized for the Pentium M with latest GCC revision and do the exact same for the Athlon 64 Box.

    That would be a lot more interesting comparison and useful than doing these benchmarks on top of Suse whose default optomizations are certainly hurting the PentiumM.

  • bhtooefr - Saturday, December 25, 2004 - link

    BTW, I mean that maybe Intel shut them down...
  • bhtooefr - Saturday, December 25, 2004 - link

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

    Here's the chat:
  • sprockkets - Saturday, December 25, 2004 - link

    Oh well, I just looked at SuSE 9.1 again and 9.2 has the ability with kpowersave to select easily the profiles it will use to run, and will say what processor speed it currently is throttling to.
  • ElFenix - Saturday, December 25, 2004 - link

    i'd like to point out that 'heat sink' is actually two words. thanks.
  • KristopherKubicki - Saturday, December 25, 2004 - link

    bhtooefr: I am pretty sure intel wont let them do that.


Log in

Don't have an account? Sign up now