Slashdot Mirror
Intel Yonah Performance Preview
illusoryphoenix writes "Anandtech has an interesting preview of the successor to Dothan (Pentium M's second generation), Yonah, with tests run on an engineering sample. It seems like latest Pentium M is still lagging in the floating point area, but has gained some ground overall. It's also interesting to note their comparisons to the Pentium D/Netburst based dual core."
Synopsis: Intel's mobile chip hangs with (and in some cases beats) AMD's top of the line desktop chip, while using less power and running cooler.
Er, the 2.0GHz Yonah in these tests is slower in nearly all cases than the Athlon 64 X2 3800+, which is the slowest CPU in AMD's lineup. The _top_ of AMD's line would be the Opteron Model 880. The best CPU they market for the desktop is the Athlon 64 X2 4800+, which has double the cache and runs at a 20% higher clock speed than the 3800+. So, Intel's upcoming chip /barely/ hangs with AMD's bottom of the line. Compared to AMD's current best, Yonah would be left standing in the dust. And Yonah hasn't even been released yet.
About the only good thing I can say about Yonah is it will run MacOS X.
that's total system power, not just the proc. That's going to include the chipset, disk, peripherals, USB devices, and the GPU.
This review was done with a desktop motherboard for the Pentium M...
This makes also Anand's comments w.r.t. the AMD/Intel consumptions disingenuous at best. It's hard to measure the CPU power, but if he wanted to compare the CPUs, he should have done his homework.
Based on the delta wattage (16W, including all other loads, e.g. memory access) and the fact that in a 65nm process the idle current is still less than 40% of the full-load, I'd say that yes, this is a very low-power CPU (to be branded as 25W maybe?), perfectly suitable for a notebook.
That they're peaceful?
(FYI: the Hebrew word Yoh' nah is transliterated as "Jonah" and translated as "dove" or "pidgeon". It, like the dove symbol, could also be used as a symbol of peace or serenity.)
From a different article :
"Pricing will stay level, too. The T1600 Yonah--which runs at 2.16GHz, comes with a 2MB cache and a 667MHz bus--"
so it seems theve upped it a bit, exactly the same jump from 400 to 533 for the dothan.
Technically the statement isn't true. What they're alluding to is the smaller the chip the more per wafer means more # of chips [same % of failures]. What they missed though is the more features [e.g. transistors] the more likely some are not aligned or otherwise created properly. That creates "worst case" chips which operate slower than they should.
For instance, if you double the transistors but simulaneously half the size you make a huge gain in yield but lower the # of high end models. To truly lower the cost you need smaller chips with less features [features as in edges on your photomask]. This is why [among other things] you see such a huge markup from a 1.8Ghz part to 2.0Ghz even though it's only 200Mhz [and the part was originally designed for 2Ghz].
Tom
Someday, I'll have a real sig.
It takes resources to efficiently decode variable length opcodes [CISC no less] to RISC operations.
Look at the PPC, ARM and MIPS way of doing things. They have fixed length opcodes and as a result don't really have large decoders [they still have them but that's mostly to tell the core which pipeline and resources the opcode has].
If the x86 were a fixed length opcode ISA I'd say "sure why not" but it isn't. As a result they have to dedicate scan engines and the such. For instance, the AMD64 reads a 16 byte window which [I've heard] it appends to a sliding maximum of 8 bytes it has already and then decodes upto three opcodes.
What happens when you have opcodes that cross the boundary? You get stalls.
In the ARM world all opcodes are aligned on 32-bits [the lower two bits of the pc register are not available]. So if an ARM reads in 16 bytes it KNOWS it has 4 instructions [or 8 if it's in thumb mode]. It doesn't have to have a "scan" engine to find the opcode boundaries nor have to worry about verification on boundaries [e.g. if an opcode spills into the next window].
Decoding is a large enough problem though, look at the P4. They had to use a decode "trace" cache just to keep the core fed [and even then it fails]. The AMD processors have fairly complicated decode engines that can decode most x86 instructions three at a time at full clock speed. That can't be cheap.
A "dual mode" chip where you do x86 and RISCop would defeat the purpose since you still have the x86 decoders there. The only solution is to drop the ISA alltogether.
Tom
Someday, I'll have a real sig.
Socket A lasted very long. I bought a mobo on it when the socket came out in 2000, MSI K7T Pro based on Via KT133. And it would be possible to use even Athlon XP 3200+...only problem: it would work at half the FSB, so half the speed. But it would work...
"Unfortunatelly" 2 years later powersurge killed it, together with Duron 600, so as a replacement I ended with MSI K7T Turbo2. And this thing supports everything from Duron 600 to Athlon XP 2600+ (the one on 266 FSB). And of course latest Socket A mobos support everything from Duron 600 all the way up to 3200+ on 400 MHz FSB.
And BTW, Pentiums are much worse example than Socket A - 60/66 MHz models, later normal models and MMX models weren't exactly compatible...
One that hath name thou can not otter
The power draw figures given on the last page are for the *entire system*, not just the CPU.
This is dead wrong.
The WMT, NWD, PSC and CDM cores were developed in Oregon.
The banias/dothan/yonah/merom cores are done in Israel.
Intel's next generation Nehalem core is also developed in Oregon.
That is all.
-anonymous intel drone.
OS X is a 32-bit OS. It can run 64-bit applications, but there appears to be only one such app on the market: Mathematica.
Also, current PowerBooks, iBooks, and minis use the 32-bit PowerPC G4, so a 32-bit Yonah is no worse.
You are correct sir. You can identify which chips were made in Israel because they are named after Israeli cities (Banias, Dothan, Yonah, and Merom). I don't recall the P-4 cores internal name, but it was not a city in Israel.
Visualize Whirled Peas
It's for several reasons:
1. There is no real support for Windows x64, there's no virus protection and very few device drivers. Why go out of your way to support 1% of your users who would actually run a native 64-bit OS?
2. Intel's 64-bit extensions actually slow their chips down. That's right, they added 64-bit instructions to their microcode, but they still get broken down to the same old instructions on the i686 core that the old ones did, and the 64-bit ones take longer to digest. It was a move for buzzword compliance only.
Want to prove it? Get a pentium D830 machine, compile Gentoo on it, first a 32-bit install, then the AMD64 install. Compile both with the same options, but one with 32-bit instructions, and one with 64. The Intel 64-bit Linux will be slower than the 32-bit. The opposite is true with an AMD K8 chip, because the core was designed from step one to be 64-bit.
3. Intel doesn't forsee you needing (or being able to fit) over 4GB of RAM in a portable or business desktop for several years, after the lifetime of this chip revision. If you insist on a 64-bit Intel chip, you must be running a server, workstation, or other high-end rig, so fess-up and buy an appropriately-classed chip (the D830, EE, or Xeon).
4. They need to deliver this chip to market NOW, Intel's stronglest lead right now is with mobile platforms. These chips are in demand as-is; Apple and other vendors want them NOW, not in a few months with 64-bit extensions.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
More specifically,
OS X is mostly 32bit. 64bit libraries are available. You can run native 64bit integer math with the accelerate framework so you can do your fast, high-precision work on a G5.
The big problem is, the GUI parts of the OS (most notably) are still 32bit. GUI apps must be 32 bit. Apps like Mathematica run kind of like X-Window.. they have a GUI and a mathematical engine running in the background. It's kind of client/server. Wolfram has a 64bit engine, but not a 64bit GUI but you don't need the GUI to be 64bit native.
The problem is, other apps aren't logically de-coupled like this so it's difficult write these 32bit/64bit applications. The big issue, as I understand it, is that there needs to be a distinct separation of 32bit native and 64bit native code.. not just in spawned threads but in actual binaries that are compiled. In Mathematica, the front end is a separately compiled binary from the computation engine.
ffakr.
I'm not feeling witty so bite me