Slashdot Mirror
Dual Pentium III Xeon Review
Sander Sassen writes: "Intel has recently released its new line of Pentium III Xeon CPUs, based on their new .18 micron process. HardwareCentral takes a look at its performance, utilizing a dual CPU configuration on an Intel i840 platform with 256 MB of Rambus memory as a testbed. This Dual Pentium III Xeon review has all the details of their findings."
Anyone know how much RAM you can put into one of these? They tested the system with 256 MB, which is a spit in the ocean for high-end systems nowadays (well, I might be exaggerating a bit...). I think it might be possible to use more than 4GB physical mem by some page table magic, but the per-process limit might be restricted to 4GB... Wait, maybe not - anyone remember LIM EMS? (*) Although, that is very ugly indeed.
As I see it, this is what they have to solve, and solve it pretty quick, if they want to continue selling 32-bit processors. Today, there are lots of people running their programs on supercomputers, only because of the large memory, not because they need the processing power. It would be possible to save millions if the high-end PC class desktop systems could be fitted with, say, 24GB mem.
But the built-in EEPROM was cool, I wonder if you can trick it into using that for booting, a la Sun's OpenBoot prom...? One can always dream.
(*) To those who are too young to remember, EMS was an ugly hack by Lotus, Intel and Microsoft to be able to use more than 1 MB of memory on the 8086 / 80286.
As always, when looking at cache, you compare bang for buck. Adding cache costs money, lots of money sometimes. Some processor architectures get more mileage out of added cache than others.
For example, the G4 seems to love cache and screams faster and faster as you add it. Apple/Motorola have found the 1MB cache level to be their sweetspot, most bang for buck. On the other hand, the PIII is not as cache loving. Giving it another 0.75MB doesn't do it all that much good, so why waste the money? Their sweetspot seems to be 0.25MB.
To compare cache amounts, without taking the processor itself into account, is almost as dumb as comparing clock rates (Mhz).
What are you talking about???
.18u my rosy red arse! For those of you not in the know, the .18u measure is the smallest feature measure, or the Lambda of the chip. Every other dimension on the chip is a multiple of that number.
.18u chips are actually .20u or .21u.
But it doesn't have to be an integer multiple of that number, and often isn't, especially when dealing with the width of the gates for the buffer transistors, which are usually in round microns. Also, Lambda design rules often use 2*Lambda as the minimum feature size.
It is the distance across the gate of a transistor from source to drain. Now, when they bake the chips, that distance shortens by a few mirons.
And this is where I really started to worry about you. You are saying that the distance (0.18um) shortens by a few microns?!!!! That means we have found the transistor that occupies negative space! Patent that one!
What you are really saying here is that the transistors get smaller. So what the heck are you talking about here.....
Unfortunately, the marketing dept. got wind of this and took off with it. Now, they measure the shortest distance from source to drain right near the gate, because the further from the gate the measurement is taken, the wider the gap is. (Sort of a curve...) So in reality, those
What are you talking about? How can you measure the gap between the source and the drain "further from the gate?" The gate lies between the source and the drain, it is what controls the flow of carriers through the channel (or at least, is supposed to control it, but we won't get into the short channel effects right now). We are talking about self-aligned processes where the gate defines the source and drain seperation by acting as an implant mask! Where do the source and drain get farther apart, making transistors that have gate lengths bigger than the given 0.18um spec? In reality, if we cleaved a PIII from the line today, I would be willing to bet you would find most transistors have a gate length on the order of 0.15um....
It doesn't sound like much, but when you're talking about millions and millions of transistors, that's a lot of space. (But probably still no more than the head of a
pin.)
Hmmm, maybe you are talking about the polysilicon lines (local interconnects) between the transistors getting bigger as you go away from the transistor? Sadly, LI isn't my true bag, so I can't comment with authority, but I suspect you again are out in left field.
I think I see what you tried to talk about. You mentioned the "shortening" of a distance with "baking" of the chip. You must be talking about the diffusion of dopants during the annealing processes. That would be the source and drain doping that subdiffuses under the gate oxide, shortening the seperation between the source and drain, potentially leading to a punched through device, and affecting the Vt of the device. How you are going to relate this to minimum drawn gate length I have no idea. I find it odd that you didn't mention the article talking about the width vs. length of the transistor being the critical dimension, but given how odd I found the rest of your comments, I shouldn't be surprised.
From the article:
Has anyone considered that this could be used to store virii? It'd be a pain - but if manufacturers can use it to keep info about usage data, no doubt it's re-writable.
Just a tiny thought.
Whatever you do... don't read this.
Rumor has it that dual athlon boards will be coming out within the enxt few months.
There is a hitch though: Linux will no support them! Thats right, Linux will not support SMP Athlons today. FreeBSD will not either. The good news is at least NT will not have support.
I think you see the problem: nobody will support them, so they won't sell, so nobody will add support, so . . .
I hope that someone overcomes that problems (and I think the board manufactures are working on NT support before they release something) When it works the Athlons will do much better SMP then any Intel offering. Seems that AMD, Cyrix (Do they make processors anymore) and the like got mad at Intel's SMP scheme and created a better one. The K-5 and cryix chips supported it, but nobody made a board to support it. I don't know if Athlon uses the same older spec or a new (alpha compatable?) spec, but I do know the Athlons all support a SMP standard better then Intel's.
I suspect that a linux implimentation of Athlon SMP will happen when boards are avaiable. AFAIK AMD is not hiding the specs.
So while the test may have been somewhat entertaining it is completley useless. The benchmark isn't anything I recognise as an accurate simulation of a server environment and there are no real life tests. Show me a test comparing this to a Sun box running Oracle and 500GB of data and I might be interested.
Is it just me, or does Intel's new "use one die" for everything seem to have gotten them into a little trouble? I read the article, look for how exactly the new Xeon is different from a Coppermine PIII. Isn't the whole point of a Xeon the large full speed L2 cache? With the PIII having a 256K full speed cache, isn't a 256K Xeon, well, redundant? I do hope there are 2 meg integrated Xeons coming soon, because otherwise, you pay more for almost exactly the same processor.
A deep unwavering belief is a sure sign you're missing something...
Tom's Hardware Guide just had an article which convinced me to stick with SDRAM for quite some time to come. Maybe for highly memory intensive long processes RDRAM is worth it, but how many of us will fin that worthwhile?
The power of accurate observation is commonly called cynicism by those who have not got it. - G.B. Shaw
The reason Motorolla (and most RISC cpu's) need more cache is because code size is larger. The whole reason for CISC (x86 type) instructions is that they take up less memory. They do more work per instruction (this is another reason why MHz is a useless comparison between RISC and CISC). Since the code size is smaller, it stands to reason that they don't get as much benefit from a larger cache.
So, why doesn't Intel build larger caches and get just that much extra performance? Two reasons:
- it costs more
- large caches have more latency
It's the never ending battle in cache size to balance low latency with high hit rates. The more you increase one, the more you decrease the other. With full speed caches on x86, 256KB (with some set associativity) seems to be the sweetspot.
So, why use more cache on Xeon's? Applications that have many processes running and access lots of different areas of memory in a short time benefit the most from a high cache hit rate (bigger caches). This is exactly the type of application that servers run. In this case, the higher latency (slower) cache is worth having a higher hit rate.
Dan