Re:Mathematics not universal?
on
The Golden Ratio
·
· Score: 4, Insightful
To those who would say "The sky is blue, and that's an absolute truth, whether I want it to be or not"... How do you know what "Blue" is?
It's quotes like these that make me think postmodernism is based on pure stupidity, rather than any rational thinking system.
Blue, obviously, is radiation in the wavelength of around 475 nm. It is measureable. When you look up at the sky, if light is primarily coming in at wavelengths around 475nm, the sky is blue.
On the other hand, if it is sunrise or sunset, or the end of the world or something, and the wavelength is much longer -- around 650 nm -- the sky is red.
If you are colorblind, it doesn't change the fact that the sky is, indeed, blue. And, even with colorblindness, you can measure the color of the sky using scientific instruments.
So, wake up, and enjoy the reality that is the universe.
Sir, no offense, but your first problem is that believing your 8M card is fine.
I bet next you are going to tell me that my NeXTStation and VT125 terminal aren't fine, either!
I'd really like to have a dumb terminal that folded up like the palm keyboards. 80x25 character screen, with a serial port and embedded 9600 baud modem or so. With really great battery life. I don't want a SuperDuperNotebook, I just want something with enough characters to see what is going on and a low power connection. Running on AA batteries.
SOI has a much different design methodology. If you are Intel and have a really great design flow for non-SOI, it may not be as simple as "just go to SOI."
Also, for complete systems, SOI has a problem in that memory density tends to be much lower... so your caches have to be smaller if they are on-chip.
Must be getting late, I seemingly can't markup my text correctly. Trying again:
Woohoo. I still remember when this site was called Chips and Dips. I remember the cheering and stomping of feet when the first paper magazine ran an article on Linux.
I still remember getting xanim to work so I could watch the Fry's ad that mentioned they were selling Red Hat. It was believed to be the first television ad mentioning Linux.
It's nice to see other old-timer slashdot users. Sub-5-digit uid's are like perls (sic) in a sea of gotse.cx oysters.
Woohoo. I still remember when this site was called Chips and Dips. I remember the cheering and stomping of feet when the first paper magazine ran an article on Linux. It was believed to be the first television ad mentioning Linux.
I still remember getting xanim to work so I could watch the Fry's ad that mentioned they were selling Red Hat.
It's nice to see other old-timer slashdot users. Sub-5-digit uid's are like perls (sic) in a sea of gotse.cx oysters.
Either Jackson is a clueless idiot when it comes to the books, or he is a slimy snake deliberately changing the story into some weird incarnation that, in his ego, he thinks is better.
This quote is going into my sigfile, unless you object.
Are you aware that Itanium is not based on the x86 architecture?
Re:You still need framers and drywallers for a hom
on
The Substance of Style
·
· Score: 1
But that house was built in the rain and cold by framers and drywallers who use simple, ugly tools like hammers, drills and saws.
How dare you call hammers, drills and saws simple and ugly, you insensitive clod!
(clutching my Bosch, Porter Cable, and Milwaukee power tools)
Seriously, though, many geeks I know really enjoy construction. I know I do. It's very nice to have quality tools and be able to build stuff. I think that this is one of the marks of a real engineer -- we like to create. Not just things that look nice -- though it is better to create something that looks nice -- but to create things that are useful.
I'm wondering if I should send a cease & desist order for verisign infringing on my web page (for instance) moobokmeow.com. If you go to either mobokmeow.com or moobockmeow.com , it delivers you to a verisign page. Surely this is infringing on the good name of moobokmeow.com!
Any lawyers out there want to send the C&D for me?
As I said, Apple's published extended-precision libraries that use Altivec. You can indeed use altivec for double precision operations, you just have to use multiple passes.
So, how exactly is this implemented? I'm very curious how they can do 64-bit floating point efficiently without 64-bit floating point instructions.
Please give me a link or something to how it's done, "multiple passes" makes no sense (to me).
There has got to be some sort of random apple troll comment generator.
Just follow these easy steps:
One: Baseless flame against everyone who disagrees with you:
Mostly just more idiots who can't understand that a good vendor is important; that their own time is important; that ease of use is even more important now than it ever has been before. Luckily, these same idiots spend all their time setting up sendmail over their 14.4 modem.
Two: Copy random specs from Apple's web page:
A fast memory pipe (1GHz) - Good heat management (9 fans but it's quieter than its predecessor) - Damn good FP performance
Three: Straight-out lies and made up stuff:
To get comparable FP performance on intel, you have to use the -fviolate-ieee flag on gcc, think about that [...] Proven apple reliability
Four: more flaming everyone else:
Again, the idiots I mentioned above wouldn't have a clue about this stuff.
Five: Claim to be superior:
We've gotta simulate airflow over wings, heat propogation over materials, and other stufff this CS major doesn't understand. [...] All kinds of CPU to crunch.
That's all it takes!
Sigh.
I haven't done real system administration for quite a while, but it's still blatantly obvious that you've never really had to deal with the administration of a compute cluster.
Apple doesn't have a proven reliability record. At least, not in the enterprise server arena. Sun Enterprise Servers do. HP does. Apple? No.
How can you seriously consider something like this without ECC memory? Do you really think that running 1100 copies of MacOSX on 1100 hard drives is a reasonable way to run a compute cluster? Do you have any idea how unreliable that would be? Do you really believe that Apple's Rondezvous will get everything setup perfectly for Infiniband?
I see. You really do. How unfortunate. If you really are from VT, you represent it poorly.
Doubtful. Altivec can only do single-precision floating point. It's pretty good at it, it can do operations 4 wide, but only single precision. Linpack needs double precision (at least, for the benchmark).
The dual floating point units on the G5 will help, but it's nothing extraordinary. P4s and Athlons both have multiple floating point units. P4's are relatively orthogonal, Athlons less so. However, SSE2 allows for vectorized double precision operations. It is likely that for the linpack benchmark, best-in-class P4 or Athlon architecture-based machines would outperform best-in-class G5 machines.
Altivec is extremely powerful. However it is only useful for applications that don't require their floating point to be double precision. SSE2 is less powerful, but allows for double precision SIMD processing.
That's the theory anyways. If dynamic compilation is so great, why aren't there any decent dynamic recompilers?
There aren't for x86. x86 is a difficult architecture to recompile in place. But for PA-RISC, check out Dynamo.
It is true that performance gains are usually not huge for same-architecture recompilation, which limits what you can do to not-very complex things. But many times you can get profile-based, global-optimization compiler performance without compiling your application using profile or global optimization.
Hint: try doing precise exceptions.
Precise exceptios is a function of the architecture, not of the translator or translated code. The hard part is expecting a debugger to work. If you reorder stuff your state will be
inconsistent with the real program at different points, and so your debugger won't be compatable with the old code.
What about self-modifying code (oh yes, it's out there - esp. in java and other managed run time apps).
These are usually tricky for dynamic recompilation. Though Java is one of the examples where dynamic recompilation is extremely effective. JIT performance is actually pretty good.
Also, why doesn't Transmeta get performance that is comparable to a similarly powered out of order machine like Banias?
I think this might be subverted support. Current Transmeta chips are very substantially smaller and at least a generaton back in process. And it certainly doesn't make the case that VLIW
Why does IA64 suck? Couldn't a dynamic recompiler help it out?
IA64 is a relatively poor performer for a variety of reasons, but if you take a bit of time and have a really great compiler, you can get your performance out of it. That being said, VLIW architectures are harder to dynamically recompile because many times they have parallel semantics which are harder to brake up and mess with.
There's too much overhead with a software based dynamic recompiler.
Well, it depends on what you do. You want to embed GCC and run it with -O4? Yeah, that's too much overhead. You want to align blocks and do a little bit of optimization over block boundaries? That's much more reasonable. And it's also the kind of optimization that you will get more benefit from, because the compiler is going to do a pretty good job scheduling straight code.
Things like instruction scheduling change far too quickly for dynamic software methods to be effective.
Instruction scheduling isn't so bad. You know the latencies for instrucitons, you can schedule them. Compilers usually do a pretty good job of scheduling in straight code.
What compilers can't do is optimize something like this:
double angle = PI/4;
for (i = 0; i < info.len; i++) {
info.arr[i] *= sin(angle);
}
Assuming sin() is in some library somewhere, the compiler can't optimize that constant away. What if it were "double sin(double x) {static int i=0; return ++i;}"? The dynamic translator can see the bigger picture, and has the potential to take the computation out of the loop.
Using a trace cache, the hardware can "dynamically recompile" code for you at much reduced latency.
It can keep the translated copy. It can even basic block reorder. But it can't do the somewhat-complex things that a translator can do.
I think that you expect too much from your architecture. But if you are thinking that given infinite resources, both an out-of-order machine and a VLIW will get similar performance, you're probably close to correct. But I think you are missing a big point -- everything i
Interestingly enough, my calculations show that 4096x4096 is pretty close to the point of diminishing returns -- it's the point at which you can't see individual pixels if you're far enough away to see the whole screen. Any further increase in resolution is only usefull if you're only going to use half the display at a time.
You're assuming that seeing the pixels is a good thing!
Think of it like this: You know that you can tell the difference between 300 and 600dpi on your printer. Wouldn't it be nice to have 300 or 600dpi on your monitor, too?
VLIWs that have code generated dynamically can many times outperform the code on the OOO machine because it has profile information and can do block rescheduling, function inlining, etc. Of course, you can get the same thing by dynamically recompiling the code on the OOO machine (like HP's Dynamo).
Really? Interesting. I would figure it could never be as fast as native x86, it's all still emulation.
"Native x86" really doesn't exist. Since the AMD K5 and Intel Pentium Pro, x86 instructions are translated into smaller, RISC-like instructions inside the processor.
Instead of doing this translation in hardware, Transmeta does this in software, and it enables a lot of optimization while (at the same time) vastly reducing the amount of hardware resources required to do wide, out-of-order execution.
They get varied results -- some things go much, much faster on the Transmeta, but it's very bad at doing other things (especially things like self-modifying code).
The internal architecture is also very geared towards translation and running translated code.
There are features that allow it to run a bunch of
code in a translation that is fast, but not safe. If there is a problem with this unsafe translation (memory exception or something) the execution can be rewinded (rewound?) into a known-good state and a slower translation or interpretation can be used.
Transmeta has released some good papers on this whole thing. If you're interested in this kind of thing, you might want to also check out HP's Dynamo and Intel's DAISY.
Though I do believe it is much easier to write readable, maintainable Python code than it is Perl code. I certainly find that I can understand my Python six months later. Perl is typically a different story.
Fortunately, Python supports open and close braces to mark beginning and end of blocks. Just prefix them with a hash and use proper indentation. For instance:
def the_count(): #{
for i in range(0,10): #{
print "%d, %d, Ah, Ah, Ah!" % (i,i)
#}
#}
Tadaa! Curly braces. The code is now readable.
PS. Sorry for the odd indentation, I haven't posted code under slashdot for a while...
I mean, you don't even know the difference between a 64 bit CPU and a 32 bit CPU, but here's a clue: the pentium is a 32 bit CPU.
I assure you, I know all about computer architecture. I get the impression you don't.
The Pentium is a 8-, 16-, 32-, 64-, and 80-bit architecture. There are operations that work on all of those bit lengths. Some of them (like 80) are only used on the FPU. But the general registers and the main integer paths are 32- bit, as is the pointer size, so we call it a "32 bit architecture." 32 bits feels "at home" on x86 more than other bit lengths.
Other desktop 64-bit architectures include Alpha, MIPS, UltraSPARC, Itanium, PA-RISC, and (recently) x86-64 (AMD64). These all have operations that can be done on 64 bits at a time much more easily. 64 bit numbers feel more at home on these machines.
But who really cares about bit length? 64 bits is no advantage at all, unless it makes your application faster. There is NO REASON why 64 bit datapaths are inherently better than 32-bit ones. It is only when you use 64-bit entities often, or need to address >4G of RAM, that 64 bit datapaths help. In the same way that it's only if you need to access >32k of RAM or use 32-bit entities that it helps to have a 32-bit datapath over a 16-bit one. There are difficulties with increasing your native data size -- including wider busses and more logic necessary to calculate things. That typically makes your critical path longer and so makes attainable frequency lower. You also have to move more information on and off chip... that makes your bandwith less effective.
They do ship Itaniums. They also ship Opterons. They're not priced very well for most home users (yet). And certainly, don't get me wrong -- I think that the PPC 970 is a nice architecture. But it's nothing revolutionary. It probably performs well on many applications, and probably performs not so well on many others. You kind of expect that given a similar process and transistor count between two processors. But it bothers me when all the Apple guys(?) start getting annoying, repeating things that simply aren't true.
You can get multiprocessor Pentium systems. Intel Pentium processors that can be placed in multiprocessor configurations are (to my knowledge), the Pentium, the Pentium Pro, the Pentium II, Pentium III, and Xeon with PIII and P4 architectures. A Xeon is either a P3 or P4. They come in both varieties. I have used computers in all of the above configurations.
I have not used a dual P4 non-Xeon.
However, the post said "You can't have a dual pentium" which is obviously false.
Of course you can encode MPEG4 in real time. On lots of different kinds of architectures... do you even know what MPEG4 is?
MPEG4 is a framework where you can combine different elements of different things -- sounds, text, video, still images, whatever -- into a single scene. In the "video" arena, there are several codecs you can choose from, at different bit rates, at different qualities, and at different sizes. Many of these combinations can be encoded on-the-fly by a moderately fast microprocessor or DSP.
Anyway, if you look at real performance numbers for the CPUs, I believe that you'll find that the 2Ghz G5 is faster than (say) a comparably-configured 3Ghz P4 on some things. The P4 is probably faster at others. For just about everything, they probably have similar performance. With a similar transistor count and silicon process, you expect reasonable architectures to come out with similar performance.
But can you get a dual processor Pentium? Of course the answer is "yes". Not only that, you can get 4x and 8x (and possibly more) Pentium and Xeon systems. You can also get 1x, 2x, and 4x, etc Opteron systems with a Hypertransport bus.
But obviously you didn't even investigate that... you just think that since Steve hinted at it, it must be true. You probably also think that this is the first CPU family to have a 64-bit datapath.
How unfortunate.
The only true thing in your post is that, to my knowledge, no desktop PC system has a 1Ghz/64 bit bus to their chip. You can get an 800Mhz 64bit bus on the P4. The Opteron has its northbridge memory controller on chip, running at full frequency... so that would be the equivelant of an 1.8Ghz system bus (in some ways).
Please, investigate matters before you post. Or you just look like a fool. And not a fool in the good way. And you end up frustrating people like me. I'm embarrased for both of us.
Apple likes to blame everyone except Apple for their problems. Motorola would have developed a new processor for Apple if Apple would have coughed up the dollars for a new pipeline design. Instead, Apple blames Mot for their speed problems while Apple haggles with IBM over how much to pay for a new chip design.
But what do you expect from Apple? Hardly the most honest company out there... Oh, sorry, I forgot, there are lots of people on slashdot these days who believe their 800Mhz G4 can beat any supercomputer. The G4 is fast, but not faster than, say, your E15000. And, sad to say, not as fast as what AMD or Intel have to offer. Sorry to burst your bubble.
Slashdot Mirror
Blue, obviously, is radiation in the wavelength of around 475 nm. It is measureable. When you look up at the sky, if light is primarily coming in at wavelengths around 475nm, the sky is blue.
On the other hand, if it is sunrise or sunset, or the end of the world or something, and the wavelength is much longer -- around 650 nm -- the sky is red.
If you are colorblind, it doesn't change the fact that the sky is, indeed, blue. And, even with colorblindness, you can measure the color of the sky using scientific instruments.
So, wake up, and enjoy the reality that is the universe.
According to here at least.
The x87 stack is unchanged, but you shouldn't be using that, anyway. The SSE/SSE2 instruction set is better. Yay, flat register file.
I bet next you are going to tell me that my NeXTStation and VT125 terminal aren't fine, either!
I'd really like to have a dumb terminal that folded up like the palm keyboards. 80x25 character screen, with a serial port and embedded 9600 baud modem or so. With really great battery life. I don't want a SuperDuperNotebook, I just want something with enough characters to see what is going on and a low power connection. Running on AA batteries.
Also, for complete systems, SOI has a problem in that memory density tends to be much lower... so your caches have to be smaller if they are on-chip.
It's nice to see other old-timer slashdot users. Sub-5-digit uid's are like perls (sic) in a sea of gotse.cx oysters.
It's nice to see other old-timer slashdot users. Sub-5-digit uid's are like perls (sic) in a sea of gotse.cx oysters.
This quote is going into my sigfile, unless you object.
Are you aware that Itanium is not based on the x86 architecture?
(clutching my Bosch, Porter Cable, and Milwaukee power tools)
Seriously, though, many geeks I know really enjoy construction. I know I do. It's very nice to have quality tools and be able to build stuff. I think that this is one of the marks of a real engineer -- we like to create. Not just things that look nice -- though it is better to create something that looks nice -- but to create things that are useful.
Any lawyers out there want to send the C&D for me?
So, how exactly is this implemented? I'm very curious how they can do 64-bit floating point efficiently without 64-bit floating point instructions.
Please give me a link or something to how it's done, "multiple passes" makes no sense (to me).
Just follow these easy steps:
One: Baseless flame against everyone who disagrees with you:
Two: Copy random specs from Apple's web page:
Three: Straight-out lies and made up stuff:
Four: more flaming everyone else:
Five: Claim to be superior:
That's all it takes!
Sigh.
I haven't done real system administration for quite a while, but it's still blatantly obvious that you've never really had to deal with the administration of a compute cluster.
Apple doesn't have a proven reliability record. At least, not in the enterprise server arena. Sun Enterprise Servers do. HP does. Apple? No.
How can you seriously consider something like this without ECC memory? Do you really think that running 1100 copies of MacOSX on 1100 hard drives is a reasonable way to run a compute cluster? Do you have any idea how unreliable that would be? Do you really believe that Apple's Rondezvous will get everything setup perfectly for Infiniband?
I see. You really do. How unfortunate. If you really are from VT, you represent it poorly.
Go look up the altivec instruction set and tell me which instructions work on packed double-precision values.
You can do double precision on PPC, but you don't get anything from the vector unit. Only the FPUs.
The dual floating point units on the G5 will help, but it's nothing extraordinary. P4s and Athlons both have multiple floating point units. P4's are relatively orthogonal, Athlons less so. However, SSE2 allows for vectorized double precision operations. It is likely that for the linpack benchmark, best-in-class P4 or Athlon architecture-based machines would outperform best-in-class G5 machines.
Altivec is extremely powerful. However it is only useful for applications that don't require their floating point to be double precision. SSE2 is less powerful, but allows for double precision SIMD processing.
There aren't for x86. x86 is a difficult architecture to recompile in place. But for PA-RISC, check out Dynamo.
It is true that performance gains are usually not huge for same-architecture recompilation, which limits what you can do to not-very complex things. But many times you can get profile-based, global-optimization compiler performance without compiling your application using profile or global optimization.
Precise exceptios is a function of the architecture, not of the translator or translated code. The hard part is expecting a debugger to work. If you reorder stuff your state will be inconsistent with the real program at different points, and so your debugger won't be compatable with the old code.
These are usually tricky for dynamic recompilation. Though Java is one of the examples where dynamic recompilation is extremely effective. JIT performance is actually pretty good.
I think this might be subverted support. Current Transmeta chips are very substantially smaller and at least a generaton back in process. And it certainly doesn't make the case that VLIW
IA64 is a relatively poor performer for a variety of reasons, but if you take a bit of time and have a really great compiler, you can get your performance out of it. That being said, VLIW architectures are harder to dynamically recompile because many times they have parallel semantics which are harder to brake up and mess with.
Well, it depends on what you do. You want to embed GCC and run it with -O4? Yeah, that's too much overhead. You want to align blocks and do a little bit of optimization over block boundaries? That's much more reasonable. And it's also the kind of optimization that you will get more benefit from, because the compiler is going to do a pretty good job scheduling straight code.
Instruction scheduling isn't so bad. You know the latencies for instrucitons, you can schedule them. Compilers usually do a pretty good job of scheduling in straight code.
What compilers can't do is optimize something like this:
double angle = PI/4;
for (i = 0; i < info.len; i++) {
}
Assuming sin() is in some library somewhere, the compiler can't optimize that constant away. What if it were "double sin(double x) {static int i=0; return ++i;}"? The dynamic translator can see the bigger picture, and has the potential to take the computation out of the loop.
It can keep the translated copy. It can even basic block reorder. But it can't do the somewhat-complex things that a translator can do.
I think that you expect too much from your architecture. But if you are thinking that given infinite resources, both an out-of-order machine and a VLIW will get similar performance, you're probably close to correct. But I think you are missing a big point -- everything i
Think of it like this: You know that you can tell the difference between 300 and 600dpi on your printer. Wouldn't it be nice to have 300 or 600dpi on your monitor, too?
VLIWs that have code generated dynamically can many times outperform the code on the OOO machine because it has profile information and can do block rescheduling, function inlining, etc. Of course, you can get the same thing by dynamically recompiling the code on the OOO machine (like HP's Dynamo).
Instead of doing this translation in hardware, Transmeta does this in software, and it enables a lot of optimization while (at the same time) vastly reducing the amount of hardware resources required to do wide, out-of-order execution.
They get varied results -- some things go much, much faster on the Transmeta, but it's very bad at doing other things (especially things like self-modifying code).
The internal architecture is also very geared towards translation and running translated code. There are features that allow it to run a bunch of code in a translation that is fast, but not safe. If there is a problem with this unsafe translation (memory exception or something) the execution can be rewinded (rewound?) into a known-good state and a slower translation or interpretation can be used.
Transmeta has released some good papers on this whole thing. If you're interested in this kind of thing, you might want to also check out HP's Dynamo and Intel's DAISY.
Yay, clever computer architecture!
4.15. Is it possible to write obfuscated one-liners in Python?
And, yes it is.
Though I do believe it is much easier to write readable, maintainable Python code than it is Perl code. I certainly find that I can understand my Python six months later. Perl is typically a different story.
def the_count(): #{
#}Tadaa! Curly braces. The code is now readable.
PS. Sorry for the odd indentation, I haven't posted code under slashdot for a while...
I assure you, I know all about computer architecture. I get the impression you don't.
The Pentium is a 8-, 16-, 32-, 64-, and 80-bit architecture. There are operations that work on all of those bit lengths. Some of them (like 80) are only used on the FPU. But the general registers and the main integer paths are 32- bit, as is the pointer size, so we call it a "32 bit architecture." 32 bits feels "at home" on x86 more than other bit lengths.
Other desktop 64-bit architectures include Alpha, MIPS, UltraSPARC, Itanium, PA-RISC, and (recently) x86-64 (AMD64). These all have operations that can be done on 64 bits at a time much more easily. 64 bit numbers feel more at home on these machines.
But who really cares about bit length? 64 bits is no advantage at all, unless it makes your application faster. There is NO REASON why 64 bit datapaths are inherently better than 32-bit ones. It is only when you use 64-bit entities often, or need to address >4G of RAM, that 64 bit datapaths help. In the same way that it's only if you need to access >32k of RAM or use 32-bit entities that it helps to have a 32-bit datapath over a 16-bit one. There are difficulties with increasing your native data size -- including wider busses and more logic necessary to calculate things. That typically makes your critical path longer and so makes attainable frequency lower. You also have to move more information on and off chip... that makes your bandwith less effective.
They do ship Itaniums. They also ship Opterons. They're not priced very well for most home users (yet). And certainly, don't get me wrong -- I think that the PPC 970 is a nice architecture. But it's nothing revolutionary. It probably performs well on many applications, and probably performs not so well on many others. You kind of expect that given a similar process and transistor count between two processors. But it bothers me when all the Apple guys(?) start getting annoying, repeating things that simply aren't true.
Can't believe my parent was "informative".
You can get multiprocessor Pentium systems. Intel Pentium processors that can be placed in multiprocessor configurations are (to my knowledge), the Pentium, the Pentium Pro, the Pentium II, Pentium III, and Xeon with PIII and P4 architectures. A Xeon is either a P3 or P4. They come in both varieties. I have used computers in all of the above configurations.
I have not used a dual P4 non-Xeon.
However, the post said "You can't have a dual pentium" which is obviously false.
Of course you can encode MPEG4 in real time. On lots of different kinds of architectures... do you even know what MPEG4 is?
MPEG4 is a framework where you can combine different elements of different things -- sounds, text, video, still images, whatever -- into a single scene. In the "video" arena, there are several codecs you can choose from, at different bit rates, at different qualities, and at different sizes. Many of these combinations can be encoded on-the-fly by a moderately fast microprocessor or DSP.
Anyway, if you look at real performance numbers for the CPUs, I believe that you'll find that the 2Ghz G5 is faster than (say) a comparably-configured 3Ghz P4 on some things. The P4 is probably faster at others. For just about everything, they probably have similar performance. With a similar transistor count and silicon process, you expect reasonable architectures to come out with similar performance.
But can you get a dual processor Pentium? Of course the answer is "yes". Not only that, you can get 4x and 8x (and possibly more) Pentium and Xeon systems. You can also get 1x, 2x, and 4x, etc Opteron systems with a Hypertransport bus.
But obviously you didn't even investigate that... you just think that since Steve hinted at it, it must be true. You probably also think that this is the first CPU family to have a 64-bit datapath. How unfortunate.
The only true thing in your post is that, to my knowledge, no desktop PC system has a 1Ghz/64 bit bus to their chip. You can get an 800Mhz 64bit bus on the P4. The Opteron has its northbridge memory controller on chip, running at full frequency... so that would be the equivelant of an 1.8Ghz system bus (in some ways).
Please, investigate matters before you post. Or you just look like a fool. And not a fool in the good way. And you end up frustrating people like me. I'm embarrased for both of us.
PowerQuiccIII/MPC8560 supports not only DDR memory, but two Ghz ethernet controllers and a RapidIO controller.
Check Out the Specs
Apple likes to blame everyone except Apple for their problems. Motorola would have developed a new processor for Apple if Apple would have coughed up the dollars for a new pipeline design. Instead, Apple blames Mot for their speed problems while Apple haggles with IBM over how much to pay for a new chip design.
But what do you expect from Apple? Hardly the most honest company out there... Oh, sorry, I forgot, there are lots of people on slashdot these days who believe their 800Mhz G4 can beat any supercomputer. The G4 is fast, but not faster than, say, your E15000. And, sad to say, not as fast as what AMD or Intel have to offer. Sorry to burst your bubble.
And, of course, Motorola sells to bigger embedded customers like cisco.