On Dec 20, 2007 12:15 PM, Stefan Teleman <Stefan.Teleman at sun.com> wrote: > > > Shawn Walker wrote: > > >> On Pentium M class processors, cpuid with %eax set to 0 returns > >> 02H/80000004H, > >> which is identical for Pentium 4, Intel Xeon and Pentium M. For all > >> practical > >> purposes, these three processors are indistinguishable from each other. > >> > >> For Pentium 3, cpuid returns 03H. > >> > >> Therefore, Pentium M identifies itself as a Pentium 4 class processor, and > >> not > >> Pentium 3 (which does not return the Extented Function Information). > > > > Pentium M may be Pentium 4 class, but as I mentioned, has very > > different performance characteristics. > > > > The Pentium M is based on the Pentium 3 architecture and includes some > > tricks from the P4 as well. > > > > More here: > > http://arstechnica.com/articles/paedia/cpu/pentium-m.ars > > Yeah. > > How about relying on what the CPU itself says it is, rather than what some > online magazine thinks the CPU might be.
Stefan, Sorry, but that "online magazine" is a highly respected publication. The particular person who writes articles for reviewing hardware has academic credibility and frequently communicates with Intel directly. They also have direct access to many Intel materials, have performed many interviews with Intel associates, have often received Intel engineering samples, and finally, if you take the time to research this, you can confirm the facts independently. As many, many websites state, the Pentium M essentially coupled the execution core of a Pentium III with a Pentium 4 compatible bus interface. They also added improved instruction decoding/issuing front end, improved branch prediction, SSE2 support, and a much larger cache. Why are you so confrontational about something that is factually correct? You also didn't answer my questions about cache. I find it interesting that Sun Studio is the only compiler I've ever used that has you specify cache size values. gcc, MS Visual Studio, and even Intel's compiler have never had me do that to get good performance. In fact, I don't know that I can with them. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben
