What's Next in CPU Land after Itanium?

"I work for a major research organization. Of late a lot of the normal big computer companies have been visiting and preaching the gospel of Itanium. My question to them, and to the assembled masses here at Slashdot is what happens next when Itanium is real? My world view is that Itanium based systems will become commodity products very quickly after good silicon is available in reasonable volume. At that point, why should one spend $8-10k for that hardware from the likes of HP, Compaq, Dell and others when one can build it for $2k (or even less)? In other words, has Intel finally done in most of their customers by obliterating all the other CPU choices (except IBM Power4 [& friends G4, et al] and AMD Hammer) and turned the remainder of the marketplace into raw commodity goods? Lest you defend the other CPUs... Sparc is dead, Sun doesn't have the money (more than US$1B we'll guess) to do another round. PA-RISC is done, as HP has given away the architecture group. MIPS lacks funding (and perhaps even the idea people at this point). Alpha is gone too (also because of the heavy investment problem no doubt). Most other CPUs don't have an installed base that makes any difference, especially in the high end computing world. So what's next? I don't like the single track future that Intel has just because it is a single track!"

Comments

compilers

[avandesande]

Itaniums will become commodities when people figure out how to write compilers for them. That will be in about 10 years.

Re:compilers

[jgerman]

Not likely, it would take a couple of weeks max for the first compilers to appear. Wish I could afford one, I'd love to hack away on a compiler for a new machine.

Re:compilers

[shitfit77]

You seem to miss the point on this a little bit. Although there will be compilers available, there is an extreme difference between a compiler and a good compiler. A compiler works, a good compile is able to utilize an architecture to its fullest (or at least close).

Re:compilers

[spencerogden]

first compilers != useful compilers

Re:compilers

[jmv]

Not likely, it would take a couple of weeks max for the first compilers to appear.

Sure, but the problem is how long before there are good compilers? That's one of the main problems with architectures like Itanium.

Re:compilers

[avandesande]

And at +3. Now where is the turd report?

Re:compilers

[orz]

Compilers were available for Itaniums long before Itaniums were available. What the poster was refering to was the lack of decent optimizing compilers for Itanium ; there are none, because the Itaniums instruction set is REALLY hard to write optimizing compilers for.

Re:compilers

[jgerman]

First compilers are the MOST useful compilers since they are the ones that will be used to create the later ones.

Re:compilers

[jgerman]

I didn't miss the point at all. First of all I don't see the word good anywhere in the original post. And B. it won't take anywhere near ten years for good optimizing compilers to appear, a year at most.

Re:compilers

[bmajik]

You overestimate the brilliance of compiler writers.

LIW and VLIW were tried before. They flopped, because compilers were dumb then. Compilers stayed dumb until midway through the RISC era. Now RISC and CISC are the same, compilers are reasonably bright, and intel is trying its own hacky LIW thing. The compilers are smart enough for a generation 1 LIW design to work, but there may or may not be any indication that they'll be smart. And as each successive subarchitecture of IA64 happens, the compiler will need to change or the chip will need to handle previous generation instructions. Intel is not true LIW in this regard - you should be able to run unmodified IA64-1 bins on IA64-2 chips.

So, some brains are still in the IA-64 chip, meaning the compiler wont have to be _as_ smart, but they'll still need to be smart, and you'll still need a new compiler for each IA64 implementation to get max performance.

Re:compilers

[Zathrus]

Not likely, it would take a couple of weeks max for the first compilers to appear

You obviously know nothing about Itanium, EPIC, VLIW, or pretty much anything else on this topic.

The issue isn't whether or not there's a compiler available. The issue is how GOOD the compiler is. In the case of a Very Large Instruction Word (VLIW) CPU like the Itanium, the compiler is the bottleneck for system performance. Why? Because the premise of these CPUs is that while they have a low clockspeed (750-800 MHz for Itanium), they execute many instructions per cycle - 10 or more. So while "slower", they get more done per cycle, resulting in a faster overall execution. It's up to the compiler to properly structure the executable machine code to take maximum advantage of this layout and keep all execution units of the CPU busy at all times, as well as reduce disseparate memory accesses and so forth.

The intial compilers that are released with these machines do it, but not as well as they could. In fact, compiler writers are still trying to grasp the issues with pipelining on modern CPUs and their much lower number of execution units, and this is without utilizing special instructions that explicitly do non-conflicting operations at once. We're still years away from writing fully optimized compilers for contemporary CPUs. And while there's been a great deal of work done on VLIW already (prior to Itanium), there's even more yet to be done. A decade for a "good" compiler is probably optimistic.

You may be wondering, what's the point anyway? If VLIW is so damn hard, why bother? Just ramp up that clock speed and get more CPU power! Well, that's nice, but it doesn't work in reality. We're starting to bump up against physical limitations in CPU speeds. Electrons are not magical particles that travel instantaeously. They are limited to slightly under the speed of light, which means roughly 1 cm per nanosecond. This doesn't seem to be a big deal until you realize that a 2.0 GHz CPU means each clock cycle is 0.5 nanoseconds. So if you have to fetch an instruction or data from main memory, and that memory is a mere 5 cm away, under optimal conditions you've just sat around for 10 clock cycles waiting on that memory to be fetched. This is ignoring the fact that there's propogation delays, latch delays, and other things. So go ahead, pump that CPU up to 10 GHz and waste even more clock cycles waiting on data. That or redesign the entire thing, expect the compiler to do the work and properly feed you data and instructions such that you can do 10x as much in the same amount of time, and all with no wasted CPU instructions.

That's the theory at least.

Reality is that not only does the compiler have to properly organize the machine code, it also has to have some idea of what the code is doing to do so. Compile the code w/ profiling, run the code against a "realistic" data set, then recompile it again feeding it the profile data. Many compilers can do this now, but it's rarely done. Because it's hard to guess a "realistic" data set, it's hard to acquire the same, how you expect the code to be used and how it actually is used are rarely the same, and there's more development time involved in all of this. So most companies don't bother. And despite what I said above, 2.0 GHz still hasn't reached the point where the CPU is sitting on it's ass more than it's doing work. Until we start approaching that point there's little incentive to put in the R&D time necessary to switch to a new CPU archictecture.

And, of course, on top of all of the above is the issue that Joe Sixpack will invariably see 2 GHz as faster than 750 MHz no matter what. Have fun with that one.

Re:compilers

[HuguesT]

Itanium compilers have been around for quite a while already. The gcc back end for Itanium has reasonable integer performance for example (and very poor floating point performance).

If you run RedHat on Itanium you can pick up your optimizing compiler on Intel's site right now:

http://www.intel.com/software/products/compilers/c 50/linux/

However current Itanium performance with either of these compilers is not very good. It's hard to say
whether it is because of the poor hardware implementation or of the lack of optimization in the compiler.
Probably both.

Re:compilers

[Anonymous Coward]

Electrons hardly travel at the speed of light, as you would know if you had taken physics classes.

Re:compilers

[roybadami]

You overestimate the brilliance of compiler writers.

Possibly, but the reverse mistake has been made in the past.

In the early days of superscalar chips, the general consensus was that it would take years to build compilers that would do the instruction scheduling well enough to even approach the potential of the new RISC chips such as PA-RISC and RS/6000.

Sun bet a whole lot on this in terms of the first SuperSPARC chips -- and pretty much lost.

The whole point of the SuperSPARC architecture was to make things easy for the compiler writers -- it was designed about being as flexible as possible in terms of combining instuctions, and did a limited form of instruction reordering on the fly -- which noone else bothered with in those days.

Net result -- by the time their more complex chip reached market, the compiler writers at HP and IBM had solved the instuction scheduling problem and in that year the SuperSPARC had lost the lead it was supposed to have had.

It's a really hard call to make, and not one you'd want to make, unless you're a betting man (or woman).

Re:compilers

[Anonymous Coward]

Intel already offers Compilers for the 64-bit Itanium processor, both C++ and Fortran for Linux and Windows. http://www.intel.com/software/products/

Re:compilers

[Anonymous Coward]

You make some good points, but please, take a physics class or read a physics book. Electrons travel no where near the speed of light. Not even close. The real problem is gate speed and idle/on current in the transistors. Multiply that by what millions of them? This is why when Intel etal find a process to make the channel widths thinner they cheer and throw parties.

Re:compilers

[Alan Partridge]

err... I think electron drift speed is a few milimetres per second - not quite the speed of light. Do you also think that when someone shouts at you across a field that air shoots out of their mouth at 700Mph? You might want to contemplate a Newton's cradle at some point and see if you can learn something from it.

Re:compilers

[RollingThunder]

I can code what I can because I stand on the compilers of giants?

Re:compilers

[Anonymous Coward]

In the case of data retrieval (not logical operations) the information travels in the form of EM waves which do travel at the speed of light.

Re:compilers

[Anonymous Coward]

This is exactly why 'virtual machines' (VM) or 'Just In Time' (JIT) compilers will eventually replace the current series of compile to asm compilers. The theory behind Java's version of "hotspot" is to locate these bottlenecks at runtime when real data is being used, optimize the flow, and dramatically increase the throughput. Microsoft will do the same with their .NET framework. Unfortunately, it will be awhile before the marketing hubbub becomes reality, and the JVM has quite a ways to go before it can truely deliver on its promises. Atleast they have the right idea.
VMs will hopefully be placed in microcode sitting just above the processors so that every programming language will equally benefit - not necessarily for that specific purpose, but as a way to market their version of the latest and greatist chip. A whole new industry of real-time, performance-enhancing, virtual machines will spring up offering to improve the performance of specific chipsets. The future looks bright... :-)

Re:compilers

[Anonymous Coward]

the propogation of an EM wave in PCB media is approximately .5 C .. that is, 1/2 the speed of light in a vacum. The speed is a function of the dielectric constant of the material and its configuration. If any of you were actually good EE students (not just high school dropouts who think sysadminning or programming is a real job), then you'd all know this.

Re:compilers

[Paelon]

And, of course, on top of all of the above is the issue that Joe Sixpack will invariably see 2 GHz as faster than 750 MHz no matter what. Have fun with that one.

Seems like AMD may have let Intel off the hook with this one by starting to label CPU's irrespective of clock speed.

I wouldn't be suprised to see an Intel IT-2500 that's clocked at 750Mhz.

Re:compilers

[Ozx]

Glad to see my CPU is constructed out of PCB media...

Re:compilers

[maraist]

So basically you're saying that computers are magical radio-wave transcievers? Funny, I thought computers were based on capacitively switched [Bi]CMOS transistors. This means the "logical operation" travels at the speed of the capacitor charge / discharge times. After the ramp-up, ramp-down time (further delayed by theinnefficiencies of junctions), then the signal travels at the drift velocity of the electrons trapped within the conduction-band; significantly slower than a stream of free-flowing electrons, much less a single electron going full-tilt.

In fact, when electrons start going close to the speed of light within a silicon, there's typically an avalanching effect (utilized in zenor diodes). Channel break-down can easily occur under such situations (caused by relatively high voltages).

To my understanding, the single biggest speedup in the past several years was the introduction bipolar transistors into the CMOS frame-work. Bipolar are very fast (non-capacitively switched), have high current, high amplification, but are power-hogs and require difficult geometries to manufacture. My understanding of BiCMOS is that FET's are used everywhere, but when a FET needs to be charged quickly (or generally requires high current output), a bipolar device is attached on the output as an amplifier. You get the best of both worlds (with the possible exception of the geometry limitations).

Wiring obviously was an issue because new copper based CPUs can run cooler and faster.

I only have an undergraduate understanding of the processes, but the simple point is that there are paracitics all throughout the architecture, and we're discovering efficincies everyday which provide percentage increases in overall performance. Thus it's not the speed, but the sophistication of the design.

There's lots of work going into light-based computing, but I don't think this will ever win out because they're plagued with even bigger interconnect problems and thus paracitics.

-Michael

Re:compilers

[maraist]

I thought that this was the crueso. They don't exactly offer performance boosts as a selling point.

If you have a target CPU, and a target OS, then you can make highly optimized compilations.. Just look at Quake. They've always optimized their code for the intel line (P2, P3 being best lately). A VM can't make several types of optimizations.. Once you're down to assembly, things like load-order are important (and x86 is horrible at dissassembly-based optimizations; no hints, and few registers).

For consumers, most only purchase on evolutionary leaps in performance; thus 50% increase or more (going from 486-66 -> P100 -> P2-300 -> p4 2,000). Theoretical gains of 5-20% based on timing isn't impressive to this realm. And for server-class software, they're going to demand hard-compiled and optimized code, which a VM could never achieve.

-Michael

Re:compilers

[Anonymous Coward]

You're looking at the propagation of electrons through the logic devices, not the interconnects. In the case of interconnects EM waves are excited by the AC source, and these waves carry the signal. The final result isn't the speed of light due to the RC characteristics of the interconnect, but it is derived from it.

Re:compilers

[CustomDesigned]

VLIW is a good argument for dynamic compilation such as used by Smalltalk and Java (HotSpot) and AS400. I see a future where most programming is done on a virtual machine. This insulates the code from changes to the CPU. One problem with VLIW is that tiny variations in functional units, etc, tend to require recompilation.

Re:compilers

[ipfwadm]

First compilers are the MOST useful compilers since they are the ones that will be used to create the later ones.

Yeah, once. And then you use the later (better?) one to build itself.

Re:compilers

[Anonymous Coward]

I can confirm that current compiler technology on the Itanium is pretty sad. I had occasion to benchmark on one of them a while back, and the results are quite pathetic.. C++ compiled for the Itanium could be out-performed by the same C++ code compiled for IA32, running on a similar clock speed processor. You could get good results on the Itanium by going to assembler. And as for Itanium Java performance ..forget it. It's pathetic (c. 30% slower than an equivalent clock IA32). Talking to tool vendors,the Java VM performance isn't even a priority for anyone until they sort out how to build an Itanium C++ compiler (obviously, since they write the VMs in C/C++).

Re:compilers

[Anonymous Coward]

Just a small comment about VLIW in relation to RISC and CISC.

The reason why VLIW has gotten new attention as a microarchitecture is that it promises the ability to easier scale the processor clock frequency when the issue width (i.e. the number of instructions issued per cycle) increases.

If you look at modern superscalar processors (RISC or internal RISC engines like PPro->P4 and Athon) that does OOO-issue, they contain several HW-resources that scale terribly with the issue order. For example register file ports, reorder buffers. This impedes the ability to scale the frequency while maintaining or simultaneously increasing the issue width.

So, VLIW actually does away with all dynamic speculation, ordering, dependency HW, and moves this scheduling stuff to SW. Doing this opens up the ability to scale issue width while (more easily) maintain the ability to scale the frequency. So, VLIWs are actually supposed to be clocked _faster_ than other CPUs, not slower. Compare this to the RSIC "speed demons" vs the CISC "brainacs" debate from the old days.

But: The big problem now is doing the scheduling in SW. The compiler as you rightfully point out, will have a hard time doing a good scheduling. The compiler for example does not have access dynamic, data related dependencies.

Writing a compiler for a VLIW is easy. Writing a good compiler is still a research thingy. Look at the Trimaran project for more info: http://www.trimaran.org/.

/Joachim - CPU designer at large.

Re:compilers

[blair1q]

Itanium has been around for nearly two years now.

The compilers aren't completely done, and they'll never be perfect (cf. any compiler for x86; the bug lists are shocking), but they're good enough for a high-end server chip where the integration engineers know how to talk to the compiler vendor to get bugfixes turned in time for the next rollout compilation.

--Blair

Re:compilers

[Anonymous Coward]

This is absurd and more than a little insulting.

I've worked on 3 VLIW compilers, including the Intel reference compiler for IA64 and the fact is, the compilers are pretty impressive pieces of technology. For a public domain instance, take a look at the SGI IA64 compiler.

The fact is, there just isn't that much instruction level parallelism available from conventional languages. Also, the whole modulo scheduling space is only slightly more versatile (ignoring the effect of predication) than vectorization.

Architectures that lack operand dependency locking
(i.e. VLIW) cannot ever be object code compatible
between versions, unless the cycle time of all operations remains relatively the same. So much for VLIW.

My guess is new high speed architectures will be derived from
existing low power, low die size, high speed, non-orthoganal (split register file, split memory)
architectures.

Yeah, it sounds silly but once someone figures out that you can run N dsp type processors on one memory, either symmetric (parallel or vector) or asymmetric (thread/process level parallel) or any shape between...and still have one cycle to memory (using cache and prefetch) and short pipes
AND fit 50 processors and a 2 meg cache on a die 1/10th the size of ia64 AND have full backward binary compatability...

Take a real close look at IA64, you'll see band-aid on top of band-aid trying to make this monolithic giant perform well. Check out the register save operation, the list goes on and on.

Anyway, innovation will occur where it can, not spew blindly from the bungholes of morons like B Rau and friends. He was spewing that, "the compiler technology is why we failed." crap as far back as 1987 when Cydrome failed.

The real reason Cydrome failed?

Ask Bob about his fascinating memory design.
Ask Wei Yen about the 8-way 68020 "general purpose" machine.

Ask Bob again about his refusal to consider doing chip level design, when he knew that weitek had just produced a floating point chip that outperformed the cydrome floating point unit.

Half the reason that IA64 is such a massive pile of shit is the unemployable morons HP unleashed on the Intel design effort. (The other half is the Intel morons, but thats another story).

Hell with this shit, I'm off to the tub!

Re:compilers

[Lurks]

It's certainly an interesting challenge to write a compiler for this sort of architecture but 'people' have been on the case of writing compilers for exotic architectures for years.

My company produces a compiler for the vector units in the PS2, that's an oddball VLIW CPU. That said, I'm not certain that we'd rush to the IA-64 platform however, Intel obviously have their own compiler and unless this has serious performance issues, there just isn't the market for an IA64-enabled VectorC.

We'd rather strive to develop the fastest x86-64 compiler instead, which is a platform where more mainstream development looks likely to happen in the short to medium terms.

Re:compilers

[MicroBerto]

Hehehehe

Re:compilers

[firewood]

So basically you're saying that computers are magical radio-wave
transcievers? Funny, I thought computers were based on capacitively
switched [Bi]CMOS transistors. This means the "logical operation"
travels at the speed of the capacitor charge / discharge times.

You are a little out of date. In the good old days (maybe a
decade or two ago), the interconnect time was small in relationship to
the gate switching times. So wire delay could basically be ignored in
most digital IC designs, only gate delays were important. Now though,
chips are so big in relationship to the clock rate that the speed of
propogation of light inside a dielectric limits a signal to only
traveling a fraction of the way across a chip within one clock cycle.
The wires are also so narrow that they have high R which makes the RC
times noticable between non-adjacent gates. The gates themselves can
still usually switch in a fraction of a clock cycle. This means modern
digital IC designs must usually be partitioned. Any signal that goes
between rather than within small logic blocks must be designed as if
the wire delay is the important factor and the gate delays are
relatively free.

Re:compilers

[Anonymous Coward]

hey come back here and tell us more:-)
I'm enjoying the compiler guy rant..being
a would be one myself (still in grad school)

What's Next?IBM not INTEL or AMD

[Anonymous Coward]

It is all on IBM, they will pick up the slack and the power5 will destroy IA64 once and for all.

Single track

[Anonymous Coward]

There are many reasons to hate the direction that CPUs are going in the future (x86), there being a single track is the least of our problems.

If the Pentium is any guide, the next chip will likely be called Itanium Pro followed by Itanium II.

Re:Single track

[grammar nazi]

The itanium already has not-an-instruction bits attached to each operation. Perhaps, they need not-a-thread bits for processes and not-a-bug bits for features.

What's after Itanium? That's easy

[wrinkledshirt]

"Anadium"

That's probably only funny to chem majors.

Okay, maybe not even chem majors.

Re:What's after Itanium? That's easy

[Anonymous Coward]

You said nad. a-NAD-ium. huhuh.

Re:What's after Itanium? That's easy

[freeweed]

"Adamantium"

There, we'll make it funny only to comic book fans :)

Re:What's after Itanium? That's easy

[Jonny Ringo]

Actually I couldn't believe it passed the Willennium

Nano-technology

[masterkool]

Nano technology is sweeping the R&D community, everthing from carbon nanotubes to 20 nanometer wire to atomic CPU's are in thought at the moment. These ideas are not constrained however to just computing, but that is a large part of the proposed market.

Re:Nano-technology

[masterkool]

I forgot to mention the serious reasearch into chemical computing that was derived from recent brain research. And to clarify, atomic CPU's use the motion of a few atoms to convey complex mesages from place to place. This would mean that an entire computer (provided ram, accelerators and all the other stuff gets smaller too) could fit in your pocket if not smaller. These would not be PDA's but full home computers. Some of the other uses for nano-technology are super strong archetecture, protein mapping, nano-bots for medical purpouses........

Re:Nano-technology

[Com2Kid]

Hmm, full home computers?

A mid 1980's home computer could EASILY be reduced to fit down to the size of my pocket.

Actualy size in itself is not the problem. The bleeming screen is.

Until we get some direct to retina or direct to optic nerve display technology, the size of a computer is always going to be limited by what the smallest display the user will stand for is.

Well that and keyboard sizes.

So you should also add direct mental input to your list of features that are needed.

Quite frankly, if you give a modern day computer manufacturing facility the technologies that I have outlined above, and in a decent sized package, a computer could EASILY be made that fits in the palm of your hand.

Hell, lets see now. Use a modified form of Sony's memory stick technology, they have gotten in packed down quite dense now days, so you really do not need such a large package if you are just going to store 4 or 8 megs of data.

The CPU should be no problem. Since this is a business computer we are dealing with here, no FPUs are needed, and 66mhz or so should be enough to run a highly optimized operating system along with some standard business applications.

Hmm, actualy, have you seen those MP3 players that they sell in the stores now days? Yah, those ones, the ones that are about the size of two of my thumbs next to each other. (or to put it in references that mean something, heh, about an inch tall by a bit less then an inch wide)

That is what we can do now days.

It is just the friggen display technology that is holding us back.

Everything else until then (new display technologies coming out) is just a stop gap measure designed to keep the technology sector alive.

Why else do you think that the latest office applications require 500mhz+ to run? Seriously? (this is MS Office of course, bleh. POS. . . . )

Just wondering, not a troll.

[AltGrendel]

How is Intel doing this different from M$ trying to clamping down in the OS arena? Just curious.

Re:Just wondering, not a troll.

[putzin]

It's different because they haven't signed exclusive deals and used marketing to force other competitors out of the fray. Essentially, they will have priced the competitors out of the building. I'm not saying they aren't a monopoly, but realistically, it's harder to argue they did it illegally or unjustly.

However, I still think that there will be room for others. AMD will probably succeed doing what they do best, outpace Intel in quality and lower the price by ~10%. This has been successfull (I hope it continues, I own stock) and will probably continue. And I doubt Sun is out. There maybe changes coming, but I figure McNealy would sell his baby prior to using Intel chips. As for the others, they fell and never recovered. You can't charge super high premiums when your competition is charging super low premiums. A lot of corps assumed you could and get away with it and look what happend.

The future is unwritten, so any sort of prediction is just fantasy for the most part. Step back to 95 and tell me who predicted 2000 or 2001? Reality is far more interesting than any professional opinion from the Gartner group et. al.

Re:Just wondering, not a troll.

[jgarry]

Step back to 95 and tell me who predicted 2000 or 2001

As a matter of fact, I did. Some predictions were way off (like the one about IBM being worth 0 - I only said that as a long shot for a Nick Peterly(sp?) article. Others were right on.

I said "There will be a big shakeout over the next couple of years. Concentrate more on the concepts and general techniques across tools, as the tools are in a rapid change phase. "[1996]

And:"We can prognosticate that the bill is going to try to merge NT & 95, as a marketing ploy if nothing else. So this means there will be a lot of different configurations, interoperability will be key. Anyone who can juggle databases with webservers will have quite an advantage (disclaimer: I am a database person, to me flat web pages are a fad. Database webservers, as boring and "data processing" as that sounds, are where the real value lie.). "[1996]

"There will be 3 ISP's, evolved from phone or Cable companies. I wish I knew which 3." [1996]

As far as complaining about alpha architecture going away, they do have a road map to the itanium. So what?

We are approaching the end of Moore's law for silicon, but that doesn't mean the law is invalidated - it just means plenty of work in the new types of computer (as others have posted), and perhaps some new concepts in parallelism and non-binary logic.

jg
--

Re:Just wondering, not a troll.

[the eric conspiracy]

We are approaching the end of Moore's law for silicon

Based on what? We have seen plenty of reports of technologies that are in real development that will keep Moore's 'Law' valid for at least another 10 years.

Re:Just wondering, not a troll.

[putzin]

So I'm confused. There are more than 3 ISP's (AOL didn't evolve from a Cable company, they bought one). The Alpha is essentially dead, or not too far from it (This isn't a prediction, but personal feeling on the subject). We are approaching the end of Moore's law... is so broad that it is true by def. We were approaching it the day he laid it down. And what does a big shakeout mean? By big shakeout do you mean industry downturn, consolidation, what? The statement is so broad that you could apply it easily to any blip in the industry. I'll give you the NT and 95 prediction. Still fairly broad, but mostly true.

Anyway, are you stating that you made correct predictions and backing that argument up with those posted here? Or are you holding to my arguemnt that most (if not all) predictions 5-6 years ago couldn't hold water? If you are using these predictions as evidence, then you should be working for Miss Cleo.

Re:Just wondering, not a troll.

[rif42]

> It's different because they haven't signed
> exclusive deals and used marketing to force
> other competitors out of the fray.

Well this is exactly what has been happening behind the scene. Throughout most of the 1990ties Intel have been able to heavy hand PC industry. With 90% control of PC processor market and having the lion share of the chipset market.

Technology wise Intel is very strong and has over the decades made lots of investment to crank up computer power. They made a lot of important early inventions like first DRAM, first microprocessor, first EPROM... first FDIV bug (he-hø! OK lets leave out the last one).

All that said Intel has also been a rootless marketing machine, which has spared no means to crush or block competitors in the market. In earlier times Intel on several occasions asked the court to block a competitor from releasing a chip by claiming patent violations or similar. They knew they would not be able to win the case, but by blocking the competitor they would be able to keep a certain market segment for themselves for another half year or so = big money.

By mid 1990ties Intel had managed to introduce its Intel Inside to such an extend that people only knew one component of their PC: the Pentium chip. They had the fastest processors and completely controller the top and mid market where all the money was, leaving AMD and Cyrix to fight in the "value for money" market where only pennies could be gained. Because they had a virtual processor monopoly, they could easily force the market to take their chipsets as well.

When AMD introduced the Athlon processor AMD had real difficulties getting the Taiwan producers to make motherboard for the Athlon. ASUS shipped their first Athlon motherboards in white boxes, they were afraid to show Intel that they supported AMD.

Around the same time Intel was setting up the deal with RAMBUS the future of RAM technology. Had
it been for the tremendous success of Athlon Intel would have been able to force-feed you with RAMBUS chips. We have all lots to thank AMD for.

If you want to learn how Intel got to the position where they are today, I will advice you to read "Inside Intel" by Tim Jackson. You will then see how much this Intel AMD battle has been a personal battle between Andy Grove and Jerry Sanders. A great read.

See e.g.

- RIF

I don't think we need to worry just yet

[Indras]

Think for a minute how long we've been using 32-bit processors. If (and when) 64-bit becomes mainstream, I imagine it will be around for a LONG time, as it becomes standardized and slowly takes over a majority of the market. Also, we'll have the other contenders butting in with equivalent and cheaper options, like Cyrix (tried) and AMD (did).

Just because Intel will pave the way for mainstream 64-bit processors using the Itanium doesn't mean it will monopolize the market until it comes out with a 128-bit processor. No matter what, it will probably be years from now before we have to worry.

Re:I don't think we need to worry just yet

[SoftwareJanitor]

The only problem with AMD's 64 bit line is that it isn't going to be compatible with the Itanium. That is both good and bad. Good in that it is an alternative, bad in that it is going to cause a lot of confusion.

I think a lot of people are too overconfident that Itanium is going to be successful, let alone quickly. It is going to require a lot of changes to software in order to take advantage of it because it isn't just a 64 bit x86, it is a whole new architecture, one more closely related to HP PA-RISC than x86. It also may not do a very good job of running existing 32 bit code, which could slow down its acceptance, particularly in desktop systems. The last time Intel made a big push (with the i432) to create a whole new non-x86 processor family, it was less than successful. Although to be fair, the i432 was a radically different proposition and the Itanium with its more proven PA-RISC roots looks a lot more sound.

AMD's Hammer architecture, on the other hand, is more conservative, being a x86 family processor extended to 64 bit. It should require less modifications to existing software to take advantage of it, although an argument could be made that it won't have as much advantage to take having more legacy issues with the aging x86 architecture. It also may perform a lot better on existing 32 bit code than Itanium. And if AMD's track history holds true, it will probably be significantly less expensive than the Itanium.

A lot of whether it is Intel or AMD that paves the way for 64 bit mainstream CPUs will probably have to do with which of them is the first one that offers a price attractive product that runs existing 32 bit software well while being marketable as a 64 bit chip. Unfortunately for AMD, the marketable part is, as always going to be tough. While AMD has been hugely successful in "white box" sales where customers can choose their CPU, they've had a much more difficult time penetrating the big name PC markets, particularly in higher end systems. This despite the fact that in many cases an Athlon or Duron would offer a better performance than a PIII or P4 at a better price.

Re:I don't think we need to worry just yet

[Anonymous Coward]

You know what I think is weird... The 8 bit processor was king, then we kinda hop, skipped, and jumped straight into the 32 bit world where we stagnated.

I don't know much about the 386, but I am thinking it was basically an 8 bit processor with some extenstions - kinda like the 65816 (which was a bastardized 8/16/24 bit processor).

Now it seems we're having a hard time taking even one step - it the technology going to slow for a while now?

Re:I don't think we need to worry just yet

[thogard]

Your almost right. Just skip the 128 bit cpus.
No application I run now needs 64 bits and none of them will run faster if they are compiled for 64 bits. The reasons for goig from 16 bits to 32 bits were quite strong--addressing was a real bitch. With the exception of a few small problem sets, we don't have that problem today. Moving around 64 bits when 32 will do results in the CPU doing more busy work and that results in less performance. A few things (almost always crypto or 2d graphics) could use a few nice 8192 bit registers but so far those aren't going into modern CPUs so I'm stuck using cryptocards.

Re:I don't think we need to worry just yet

[megabeck42]

Actually, no. The 8088/8086 are really 16 bit processors. They both had a 20 bit address bus, and had 16 bit wide registers. 8088 had an 8 bit data bus; 8086 had a 16 bit data bus. The 80286 added a primitive mmu to get the 286 protected mode and had a 24 bit address bus and 16 bit data bus. The 80386 had a 32 bit address bus, with the same old 16 bit data bus. The 386 also sported 32 bit registers and had a real mmu. The 16 bit registers, ax, bc, etc. were extended to 32 bits eax, ebx. The 16 bit commands still operated on the lower 16 bits of the registers. (register size is specified in the instruction prefix.) The 80486 had the full 32/32 compliment. (That's why you needed simms in pairs on 486's.) The 8086 to the 286 was a stumble, the 386 was definately an improvement.

However, realistically - the x86 line should have stopped around the time of the 386, 486, or perhaps the first pentiums.

The itanium is pretty disgusting. Seriously stupid flaws, for example: there is no integer division - you HAVE to use the FPU for all divisions, including transferring values to and from floating point registers.

I personally hold that Alphas are, architecturally, the king of 64 bit chips. Unfortunately, they don't have the money behind them that x86 does - I think a lot of the industry laments that. As the Pentium IV proves, with enough money you can make anything fast and cheap. Imagine what we could have done with the Alpha.

Re:I don't think we need to worry just yet

[Anonymous Coward]

Are you kidding me???

I work in the development group for a large isp/nsp/whatever you want to call it. We get people everyday who are clamouring to throw 64gb of ram in a machine only to find out that it can only be addressed in 4gb chunks.

64bit addressing is badly overdue. I think it'll be a while before we need 128bit, but people who say things like that are often wrong :-)

--john

Re:I don't think we need to worry just yet

[Anonymous Coward]

no !, the 386 has a 32bit address and 32 bit data
bus, not 16 bit

Re:I don't think we need to worry just yet

[megabeck42]

Sorry, the DX had a 32 bit data bus, the SX had a 16 bit data bus.

Re:I don't think we need to worry just yet

[stripes]

Think for a minute how long we've been using 32-bit processors. If (and when) 64-bit becomes mainstream, I imagine it will be around for a LONG time, as it becomes standardized and slowly takes over a majority of the market. Also, we'll have the other contenders butting in with equivalent and cheaper options, like Cyrix (tried) and AMD (did).

Not really. A good rule of thumb is the address space increases about a bit a year. Partly because the amount of memory goes up (as price goes down) so anyone looking at size/speed trade offs, or even size ease of coding trade offs go more towards size.

I'm typing this on a laptop with 1Gbyte of RAM. In two years it'll be 4G (well whatever laptop I have then). While you can address more then 4G with only 32 bits, plus some hackery it is just a big pain.

If this trend continues to be true we have about 32 years of 64 bit address space to look forward to...

...of corse that discounts the use of anything like a capability based OS which needs much much larger address spaces (I think the AS/400 has a 256 bit address space).

Re:I don't think we need to worry just yet

[stripes]

I think a lot of people are too overconfident that Itanium is going to be successful, let alone quickly. It is going to require a lot of changes to software in order to take advantage of it because it isn't just a 64 bit x86, it is a whole new architecture, one more closely related to HP PA-RISC than x86.

It isn't really any closer to the HP-PA then it is to the x86 (unless you count "only" having 16 times as many GP registers rather then 64 times as many...).

[...] The last time Intel made a big push (with the i432) to create a whole new non-x86 processor family, it was less than successful.

Intel has done a lot of non-x86 CPUs since the i432 (and "less than successful" is an understatement). They did the i960 which while I didn't like was a real winner in the embedded (esp. military) market. They also did the i960 which I did like and was only modestly successful, I think mostly because they end of lifed it so fast (it was doing fairly well in the market until they EOLed it). They are also doing ARMs, but they didn't design the ISA there.

Re:I don't think we need to worry just yet

[Anonymous Coward]

386sx was 16bit data bus, 386dx was 32.

486dx was a 386+387 on one chip. So was the 486sx, but the 387 was disabled. Oh, and not all 486s need paired SIMMs, but the pentiums did.

Re:I don't think we need to worry just yet

[SoftwareJanitor]

It isn't really any closer to the HP-PA then it is to the x86 (unless you count "only" having 16 times as many GP registers rather then 64 times as many...).

I dunno, the Itanium looks more like a HP-PA relative than part of the x86 family to me... But I mainly say that from the standpoint that HP's PA people were involved in the design as well, and the Itanium looks like it has a fair amount of influence from the PA. The x86 compatibility in the Itanium looks like more of an add-on than it being a part of the x86 family.

Intel has done a lot of non-x86 CPUs since the i432 (and "less than successful" is an understatement).

I don't know of any that were in the general purpose CPU market that were successful though.

They did the i960 which while I didn't like was a real winner in the embedded (esp. military) market. They also did the i960 which I did like and was only modestly successful, I think mostly because they end of lifed it so fast (it was doing fairly well in the market until they EOLed it).

The i960 was more targeted towards the embedded controller market, or at least that is where it had most of its success. I don't know of any general purpose computer that used it as its primary CPU.

They are also doing ARMs, but they didn't design the ISA there.

Well, as they didn't design the ARM, I don't really count it. The ARM has been used in some general purpose desktops and servers, but especially in the US has had limited commercial success outside of niche markets like handhelds.

Re:I don't think we need to worry just yet

[stripes]

But I mainly say that from the standpoint that HP's PA people were involved in the design as well, and the Itanium looks like it has a fair amount of influence from the PA.

It doesn't seem to be any more like an HP-PA then anything else. Actually I would say it is more like a Multiflow then anything else. Ok, I mean yes it is a three register ISA like the HP-PA (but also like most other modern CPUs!), but almost none of the HP-PA addressing modes, and very few of the HP-PA quirks (the bit mangling instructions may have been from there, but I'm not sure, and they are a pretty small part of the IA64 anyway).

I don't know of any that were in the general purpose CPU market that were successful though.

OK, I didn't realize that you were concerned with how they were marketed rather then designed. The i860 was in a modestly successful Unix machine in Japan, and a woefully under successful one in the USA (same box, the OkiData 8500 and one or two other models). It had better SPECfp numbers then most of the other Unix boxes at the time too (I think it predated the Alpha, but can't remember, it didn't beat the RS/6000, but it beat the DECStation and was way way way faster then the SPARCs of the era). Hmmmm, come to think of it maybe it was (a little) after the Alpha, it was slower then the Alpha.

The data books definitely read like it was intended to be a GP CPU. Mine are packed so I can't say for sure if they used the phrase "General Purpose CPU" or not though.

The i960 was more targeted towards the embedded controller market, or at least that is where it had most of its success. I don't know of any general purpose computer that used it as its primary CPU

Me neither, they could have though, some of them had MMUs, but none of the fast ones did. Closest to being in a GP computer was being the controller on the I2O bus (and I think it might have made a decent PDA CPU though, but the StrongARM makes a better one, as does the CPU32+ both for different reasons).

Re:I don't think we need to worry just yet

[Anonymous Coward]

A few i960's get used in engine control modules and PostScript RIP engines in printers. I thought a couple of image processing boards used them as well, but this was a few years ago.

If I were into graphics hardware, where things have come in 10 years would be even more amazing than 8MHz 16-bits to 2000Mhz 32-bits. What used to require something like an SGI Onyx can be essentially done real-time on a NVidia board now.

Er, is this whole article a troll?

[davecb]

or perhaps a market research person trying to select evidence for a really cool tempest-in-a-teapot? But wait, that's a kind of troll itself...

Required disclaimer: I'm biased toward a well-known non-intel chipset (;-))

Next?

[jgerman]

In a word, quantum. Or maybe that's two words, actually it might only be a word when you're looking directly at it.

Re:Next?

[rhost89]

Or mabey when your NOT looking directly at it, or better yet, how about when your doing both at the same time :)

Re:Next?

[jgerman]

Yep and we'll have be careful not to jostle the keyboard, otherwise we won't be able to find the home keys.

Re:Next?

[emmons]

Not really. Quantum computers aren't very good at adding, subtracting or a lot of other things that most programmers find come in handy from time to time these days. Boolean logic will still be prevalent for a VERY long time to come. It may not happen on silicon for that long, however.

There's a lot of information in this thread: http://slashdot.org/article.pl?sid=02/02/10/001620 4&mode=thread,
specifically, this post: http://slashdot.org/comments.pl?sid=27736&cid=2980 985.

Competition

[Jaborandy]

I believe in competition. I believe that when the cips are cheap, HP and other system manufacturers will sell reasonably priced systems. I believe that AMD will offer a competitive chip... eventually. I believe that there will always be choices.

--Sandy

PS - I agree with another poster that compilers for Itanium are way too complicated, by design. It sucks that there isn't a good compiler yet.

Windows XPi of course

[dominic7]

I can see it now, All Servers running on Intel Chips running Windows Operating Systems. Unless AMD overcomes their "hobbiest" or second choice image the industry will eventually begin to stagnate.

Re:Windows XPi of course

[tillemetry]

Begin?

Re:Windows XPi of course

[ericsante]

amd was late and underpowered in the multicpu arena. they still are behind, NO Xeon competor. but the latest round of AMD MP cpu's really rock.

Now if HP and Compaq would "invest" and build a solid motherboard/box amd would begin to see a brighter future.

Untill then we are "STUCK" with intel.

Logically, it should be Anadium

[PD]

Itanium is Titanium without the T, so Anadium is Vanadium without the V.

I can't wait until they get to Hassium. They could name their chip Assium!

Re:Logically, it should be Anadium

[Anonymous Coward]

I can't wait until they get to Hassium. They could name their chip Assium!

Why thanks for clearing up that joke, I never would have got it if you hadn't explained it!

You must be an American. TV is killing your braincells.

Re:Logically, it should be Anadium

[Anonymous Coward]

Itanium is Titanium without the T, so Anadium is Vanadium without the V.

I can't wait until they get to Hassium. They could name their chip Assium!

...and the chip
will be a piece of sh*t

Re:Logically, it should be Anadium

[brettper]

I can't wait until they get to Hassium. They could name their chip Assium!

Or they could stick with Hassium - Half-Assium...

McKinley and Jackson

[spt]

McKinley is the 64-bit that Intel will sell for real.

Jackson is 32-bit which has simultaneous multithreading.

Links aplenty which simple google search

Itanium vs. Hammer vs. All Others.

[Talonius]

AMD's newest chip is supposedly fairly remarkable (don't have specifics, see Tom's Hardware's search engine). What about the Crusoe? VIA's purchase of (I believe) the M3? I wouldn't look at companies that are currently in the business only - I would tend to look at companies that might move into the business, either via investment, startup, or outright purchase.

I'm not too worried about Itaniums, and I don't see them becoming prevalent for quite a while. While the Pentium II, III, and IV moved through the marketplace fairly rapidly they all offered compatibility at some level. If I recall correctly 32 bit programs that are not rewritten for 64 bit run SLOWER on the Itanium than they do the equivalent Pentium line.

In essence consider this: it's like a brand new operating system attempting to break into the monopoly that Microsoft has. (Parallels drawn out of necessity.) While it may be better, faster, superior in every way it doesn't have 20+ years of legacy code behind it - and that will end up being what drags it down.

Only time will tell. Remember the Pentium Pros..

Talonius

Re:Itanium vs. Hammer vs. All Others.

[Skirwan]

If I recall correctly 32 bit programs that are not rewritten for 64 bit run SLOWER on the Itanium than they do the equivalent Pentium line.

When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

Until Intel gets the Itanium cost down to the point where they run 32-bit code at equivalent speed to a Pentium at the same cost, Itanium probably isn't ready for the consumer market.

--
Damn the Emperor!

Re:Itanium vs. Hammer vs. All Others.

[Cheeko]

The key here is that Itanium isn't going after the 32 bit market. Intel plans to keep producing its 32 bit chips at least for the time being, the Itanium is purely a move at the high end server market. So while yes, 32 bit apps will run slower, Intel probably doesn't care, as all the customers they are trying to sell to are already on 64 bit, Sparc, Alpha, Power4, what have you.

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

While that's a valid point, it also bears pointing out that Pentium IV is at 2200 MHz whereas Itanium is at 800MHz -- about 1/3rd the clock speed. That ratio is going to remain for awhile too -- McKinley will come out at 1000 MHz, while Pentium IV continues its mad march toward 3000MHz and beyond. You acknowledge this fact implicitly with your next statement (re: Itanium not viable until approx same speed at approx same cost), but I felt it'd be interesting to point out just how large a gap there is.

These ratios spell doom for hardware-level emulation of the Pentium on the Itanium. Unless Intel has some serious magic, having a 100% cycle-for-cycle perfect emulation of the Pentium III or even Pentium IV on the Itanium die will never run better than 1/3rd the speed of the real thing, since the fundamental clock rate is so far off. The only real way to get close is to do a software-level translation and get a boost from scheduling for the native hardware.

It's interesting to note, BTW, that HP's Dynamo project does a software translation of PA-8000 code targeting (guess what) a PA-8000 CPU, and rather than slowing things down, it actually gets 20% speedups! Ars Technica also did a piece on this. Perhaps that's why HP doesn't have hardware-level translation from PA-RISC to Itanium on the die like Intel does -- they (HP) are in a better position to just translate the PA-RISC code to IA-64 when needed. (Also, in the UNIX world, it's just simply less necessary.)

--Joe

Re:Itanium vs. Hammer vs. All Others.

[Myxorg]

PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer)

Actually the break even point wasn't reached until about 100 Mhz or so, not sure. But I do remember when the first ppc came out they were definatly slower than the old 040's. Still don't know how Apple pulled that one off (selling new computers that were essentially slower than previous models)

Re:Itanium vs. Hammer vs. All Others.

[Locutus]

> Only time will tell. Remember the Pentium Pros

the ONLY reason the Pentium Pro didn't catch on was because Microsoft released a 16bit OS and told everyone it was a 32bit one ( Windows 95 ).

SCO Unix, OS/2, and to some degree Windows NT ran quite a bit faster on the 32bit optimized PPro when compared with the same clocked Pentium.

Because of Microsofts great PR, even Intel was caught off guard and scrambled out a hack called MMX to give the appearance of progress in the CPU market. While the MMX based Pentiums were getting press/air time, Intel was hacking at the Pentium Pro core to get it to run THE 16bit OS (Windows) faster. That was the Pentium II.

IBM did some speed tests of OS/2 on the PPro and in some cases they saw a 100% speed increase on the 32bit optimized PPro.

This reminds me of the 7degrees from Kevin Bacon reference. It seems that many failures in the computer industry are only about 3degrees from Microsoft. And never is the failure do to competition but more likely, marketing and market control. IMHO.

The PPro was a darn good CPU. It finally took 32bit-ness seriously though about 10 years after the 32bit i86386 was released. As much as I like the simplicity of RISC, Intel will never get the Titanicium off the ground and AMD/Hammer will force Intel to follow their lead with an extension to the i86 instruction set into 64bit land.
IMHO.

LoB

Re:Itanium vs. Hammer vs. All Others.

[Ryan Amos]

Well, eventually, that will happen, without a doubt. Moore's law pretty much assures it, in fact. The big question mark is whether or not the Itanium can match the price/performance of the Pentium like before someone else does. Seeing as Itanium is currently running at clock speeds around 800 mhz when it would need about 1600 to be equivalent to a P4, even Intel's not betting on this (hence the Yamhill) and they're seemingly relegating the Itanium to high-end servers (to take over where the Suns and Alphas left off) which seems to be where they're best suited. At least for now, it looks like the x86-64 (Hammer/Yamhill) is the platform of the future, and Itanium will be just another expensive non-consumer platform.

The luxury Apple had in this situation was control of the operating system, which Intel doesn't have. Ironically, Apple will also be moving to a 64-bit architecture within the year (conservative rumors say Q3/Q4 2002.) The transition is supposed to go very smoothly, as developers are being told to prepare their programs with the 64-bit OS X libs and OS X-64-bit is being developed in concurrence with the 32 bit version. FAT binaries helped immenseley in the 68k-PPC transition, and probably will again for the G4-G5 transition.

Though honestly, if Microsoft gets what they want with the entire .NET plan (not the framework, the entire plan) then architecture will become largely irrelevant. In any case, I doubt that many people will need frequent execution of their old 32-bit apps much more than 2 years after any sort of major switch happens. It happened with Mac OS, and it'll happen with Windows. Linux is irrelevant here, as most Linux software can be easily patched and recompiled.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

mm. dM8
YMMMb. dMM8
YMMMMb dMMM'
`YMMMb dMMMP
`YMMM MMM'
"MbdMP
.dMMMMMM.P
dMM MMMMMM
8MMMMMMMMMMI
YMMMMMMMMM
"MMMMMMP
MxM .mmm
W"W """

Re:Itanium vs. Hammer vs. All Others.

[boopus]

While 800/2200MHz is a large difference, you fail to mention something that everyone here should know by now, that clock speed does not equal performance.

Clock speed does not equal performance. This is a fact of life, especialy with 20 stage pipelines and the like. AMD and Apply have been trying to teach this to the world, and on the surface most geeks understand, but they don't beleive it in their hearts.

Now, I'm not saying that the PIV won't be faster than Itanium for a good while here, and I honestly have no idea if it will be or not. We just need to stop using Mhz as our comparisons unless we're comparing the same chip.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

I thought pentium pros became pentium 2?

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

Once upon a time, in a galaxy long, long, ago, i spent a whole lot of money to buy a pentium pro when it was the top o the line. i figured my investment was good because even though it ran slower now, it would run faster later, and i wouldnt have to upgrade again. Of course, by the time anything took advantage of the pro, the pentium 2 was out and running twice as fast. it was the same as the itanium is now -- great in a a professional sector with industrial grade software to use it, but ts crap for us. dont worry about intel running away with the show on this one -- by the time everyday stuff could be helped by an itanium, there will be something faster and more suited to use outside a corporate mainframe.

Re:Itanium vs. Hammer vs. All Others.

[sean23007]

While it may be better, faster, superior in every way it doesn't have 20+ years of legacy code behind it

If you are drawing a comparison between Windows and the Unices, you may find it interesting that Unix came before Windows and thus has more legacy code than Windows does. The reason for Windows' success is not all their old, crappy code, but because of their excellent marketing department and their vision of what the consumer wants.

Re:Itanium vs. Hammer vs. All Others.

[PurpleFloyd]

While clockspeed!=performance, the point of the previous poster is that even if you emulate x86 on the hardware level (very difficult and expensive) on an 800 MHz chip, despite all its powerful 64-bit features, you will really only get the equivalent of an 800 MHz Pentium 3 or Athlon. Although clockspeed is definetely not the only factor in performane, it plays a good part. Thus, while an Itanium at 800 MHz may easily beat a Pentium 4 9.12 terahertz processor when both are running native applications, emulation is going to be slow and cumbersome almost no matter what. The only real "solution" I could see to get around the slow x86 emulation would be to put a seperate, higher clocked x86 chip outside the Itanium (oldschool math-coprocessor style) and sync the two processors somehow (now that would be a chipset designer's hell!) While the Itanium's native code will be very fast, emulation is by nature slow.

Re:Itanium vs. Hammer vs. All Others.

[Chris Burke]

Um... Who would ever do a cycle-for-cycle perfect emulation of anything, when the point is just to mimic the -functionality-? It'd be stupid. Computer architechts are the only ones who need that accuracy -- every one else settles for just functional correctness.

Will IA-64 processors ever be able to -functionally- run 32-bit code at a speed comparable to a Pentium?

The answer is: Only if Intel stops developing their 32 bit chips. Then, sometime in the future, an IA-64 chip will run 32-bit code as well as -todays- P4.

But here's the problem: The moment Intel does that (stop developing 32 bit chips) they hand the desktop market to AMD. AMD is already positioning itself as a way to get 64-bit code capabilities without needing to sacrifice 32 bit performance. In that period between when there are no new Intel 32-bit chips and when Itanium gets fast enough to catch up there will be one option -- AMD. So obviously Intel isn't going to do that.

Their other option is to switch everyone over to IA-64, even the consumer market... But there really isn't any incentive for anyone to do so. Unlike the 16->32 bit transition, 32->64 really holds no benefit for the average consumer. 640K may not be enough for everyone, but 4GB will be enough for the consumer until the issue has already been decided.

Re:Itanium vs. Hammer vs. All Others.

[swb]

I thought that '040 was all-around competitive with PPC until much later in the Apple product cycle, primarily due to the dependence on 68k code in the OS.

This was from a work-and-feel mindset. Once everything was all PPC based, '040 ceased to be competitive, but it wasn't until far too late in the product cycle.

I always thought Apple would have been in a better place if they had focused a lot more on making MacOS available in 100% PPC version at the time they released PPC machines.

If using a PPC had actually been much faster than an '040, PPC would have had more momentum, especially as the clocks ramped up. As it was, it didn't seem like you got ahead with PPC until way later in the game.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

I believe the G5 is planned to start out at 1 ghz.

Re:Itanium vs. Hammer vs. All Others.

[lscoughlin]

Not so not so not so.

Yes unix came first. Yes unix developed a very interested and loyal developer base. It is a fraction of the size of the windows developer base. A small fraction.

In the years between windows 3.1 and windows 98 more code was written for win32 then i think has ever existed for unix.

There are many, many reasons for this, but the largest one is because the movement reinforce itself. I know many of you are hooked in varous incarnations of VI and EMACS and what have you, but none of them are comparible tools to Visual Studio.

And this is a trend that has been going on for a while. Borland and other companies like Spinner+ and gupta made windows development cake. And since windows was on the desktop it was peoples first introduction to computers and people who might of wanted to make something would make it for... windows...

Tool addiction is what keeps a large number of developres tied to Microsoft. Regressing from visual studio to emacs is a painful wrenching experience. Regressing to vi is simply intollerable.

Put more support into Active sate, KDE Studio, gIDE (which seems to have disappeared) and the like. Buy kylix. That's the root to acceptence. Make things real people can develop with.

-Tilde

Re:Itanium vs. Hammer vs. All Others.

[Phroggy]

FAT binaries helped immenseley in the 68k-PPC transition, and probably will again for the G4-G5 transition.

From what I understand, FAT binaries shouldn't be necessary, since the PowerPC instruction set is already completely 64-bit clean (it was designed that way from the beginning, and IBM has made 64-bit versions such as the 620 already). So, the same binary executable should work just fine on either a G4 or a G5.

It's entirely possible that I don't know what I'm talking about; feel free to correct me.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

Actually the original PPC 601 started at 80Mhz (I know I still have it running as my mail server) and it was only sold for a few month before the 100Mhz came about and achieved parity

Re:Itanium vs. Hammer vs. All Others.

[roybadami]

No because that assumes that both CPUs can do the same amount of work in one clock cycle -- which is not true.

Whilst it seems inevitable that the Itanium will not be able to emulate the Pentium IV at full speed in the short (and probably mid) term, ther is absolutely no reason to assume that an 800MHz Itanium emulation of a Pentium IV can't beat the performace of a 800MHz Pentium IV with a well-written emulator.

Because the Itanium has the potential to do more work in one clock cycle.

Attempting to compare different architecures of CPU MHz for MHz has always been and always will be meaningless.

Re:Itanium vs. Hammer vs. All Others.

[roybadami]

Partly, IIRC, because they did a trick where although the 68xxx app itself ran emulated, when it made a call into the MacOS toolbox, that ran as native PPC.

Ie effectively they could link emulated apps against native libraries.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

How did Apple pull it off? Simple. There are legions of Mac fanatics out there that will always purchase Steve Jobs's latest toys, no matter what the cost or performance deltas are. Jobs knows this, and these kind of people are the only thing that's kept Apple afloat these last few years.

Sure, the iMac made a nice bump in sales, but that's now tapered off. The Cube was a flop. This latest gig with the integrated flat panel should fail as well for the same reason the Cube failed -- too much dough, not enough go.

I gave up on Apple a long time ago when they killed off the clone market. I paid good money for my Mac clone and it was an awesome box for the money. But after that fiasco, I went PC, and I've never regretted my decision.

Re:Itanium vs. Hammer vs. All Others.

[Alan Partridge]

that's definitely FYI, and the PPCs were only (very slightly) slower running legacy code, for performance applications like Photoshop the native code was available very quickly.

Re:Itanium vs. Hammer vs. All Others.

[Have Blue]

They had a PPC version of Photoshop from day 1.

Re:Itanium vs. Hammer vs. All Others.

[benwaggoner]

It's was really the promise of native software. There weren't a lot of software available when the PowerPC first came out, but everyone knew that it was coming, so if you were going to buy a Mac you wanted to be using for more than a year or so, you bought PowerPC, and waited for the apps to come. There was a PowerPC plug in for PhotoShop 2.5 out very eaerly, and Pathways into Darkness (Bungie's pre-Marathon shooter).

Still, a lot of people bought '04 systems for a while. PowerPC really won when the PCI PowerMacs came out, which were 120 MHz minimum, did more per cycle, and had a much better 68K emulator. At that point, a PowerPC was many times faster than the fastest 68040 machine ever build, and no one looked back.

For the first few years of PowerPC, Mac users had the unusual experience of having their systems get FASTER with every OS and application update.

Also, the 40 MHz 040 chips were actually 80 MHz internally with a 40 MHz bus. Kind of like a 486DX2-80.

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

As much as I'd like to think AMD could force Intel to do anything, AMD is much too small.

AMD doesn't have the FABs to make enough CPUs for the market even if they wanted to!

And IIRC they are only allowed to farm out a fraction of their CPU production due to licensing agreements with Intel. So until AMD gets more fabs they can only get about 30% of the market and if they could get more all AMD can do is raise the price of their CPUs.

If AMD had more of the market Intel may not have bothered with SSE when 3DNow! was everybit as good (or better!). Intel will probably make their own x86-64 that is slightly different from AMD's just because they can.

Re:Itanium vs. Hammer vs. All Others.

[norwoodites]

The PowerMac 6100 was a 60MHz PPC, the PowerMac 7100 was a 66MHz, and PM8100 was 80Mhz; then the 100 came and everything got a bust, and then 110Mhz.

Those days were great because the PPC was still faster than a Pentium.

Re:Itanium vs. Hammer vs. All Others.

[discstickers]

Yup, the rumor is that 32bit code will run at full speed. And 64bit code is only a recompile away.

Re:Itanium vs. Hammer vs. All Others.

[binaryDigit]

Keep in mind that Apple switched two disparate cpu families and that all the emulation was done in software. Itanic was designed to emulate the x86 in hardware! So while it is interesting to compare, we're talking two fundamentally different situations here. The key point in your last statement is the part about the "consumer market". Obviously Intel is focusing soley on server/advanced workstation market since they can recoup costs by initially charging more (a lot more) and you have a smaller set of apps to rebuild in 64bit. With the P4 chugging along, I don't think that they are killing themselves trying to get Itanic on every desktop right yet. PLUS, if anyone remembers, the 386 was actually _slower_ than the equivlent clock speed 286 for running 16bit real mode code. You just couldn't buy any 286's mainstream above 12Mhz when the 386 came out at 16Mhz, so the clock bump masked the slight decrease in performance (the price you pay for doing things "right"). It wasn't until you could buy 16 and 20Mhz 286's (by then no one cared) that this fact became evident.

Re:Itanium vs. Hammer vs. All Others.

[homer_ca]

"the ONLY reason the Pentium Pro didn't catch on was because Microsoft released a 16bit OS and told everyone it"

I wouldn't say ONLY. There was also the slight problem of the double chip package (separate cache and cpu dies mounted on one substrate) being horrendously expensive to produce. Looks like Itanium will have thesame problem.

Re:Itanium vs. Hammer vs. All Others.

[Locutus]

The PentiumPro had a double chip package? I know the Pentium II was a double chip package and was also that dumb SLOT format but the PPro? From what I remember, Intel said the PPro was too expensive to make with the cache onboard so they HAD to change from a socket to the slot that accomodated the CPU and cache on a PCB.

IMO, Intel came up with the SLOT format to put a major dent in the clone chipset manufacturing that was going on. When Intel released the SLOT CPU, they only licensed it out to very very few companies. Intel motherboards ruled the day for quite some time back then.

All just more smoke and mirrors and no real progress. IMHO.

The Itanicium having the double chip package is most likely because preformance would suck without a huge cache. They needed it if anyone was to even LOOK at the chip. A huge cache onboard would kill the yeild/wafer count and made the chip even MORE expensive to make. IMHO.

LoB

Re:Itanium vs. Hammer vs. All Others.

[DavidRavenMoon]

But I do remember when the first ppc came out they were definatly slower than the old 040's.

This was because the Mac OS was running in 68k emulation... it was the OS that was slow on PPC

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

nice one Hef!

Re:Itanium vs. Hammer vs. All Others.

[ksheff]

gIDE (which seems to have disappeared) and the like. Buy kylix. That's the root to acceptence. Make things real people can develop with.

According to a recent GNotices, gIDE and Anjuta are going to be merged for Gnome 2. So if 'real people' can't develop with vi/Emacs, what do you call those that are productive with those tools? Personally, I can't stand GUI IDEs.

Re:Itanium vs. Hammer vs. All Others.

[sjames]

Regressing from visual studio to emacs is a painful wrenching experience. Regressing to vi is simply intollerable.

Actually, of the many IDEs, etc I much PREFER vi, make, etc over all of them. Screen is also helpful. The thing I most like about using X for development is.....more text windows!

As for Windows, I despise the API, and the big catchall event loop, and the 'wizards' with their exercise in obfuscated code generation. It seems a lot more intuitive to connect an event to a function (such as in GTK).

I do hope the various Linux IDE systems work out since some genuinly prefer that, but give vi etc. 1 month and see if it's not actually much more efficient.

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

Who would ever do a cycle-for-cycle perfect emulation of anything, when the point is just to mimic the -functionality-? It'd be stupid. Computer architechts are the only ones who need that accuracy -- every one else settles for just functional correctness.

Basically, what I was trying to say is "assume that you somehow map the x86 instructions onto the Itanium instruction set in hardware so that the total cycle count (ignoring memory system effects) for the translated instructions is no greater than the original code under any circumstance." In that scenario, you'd still be 1/3rd the speed of the flagship CPU. Now, things don't look *quite* so bad once you start throwing memory system effects in there, but for things that fit in the L1s, you're hosed.

It's unrealistic to think that the hardware translator will close that 3x gap.

--Joe

Re:Itanium vs. Hammer vs. All Others.

[homer_ca]

The PPro was more like 2 dies in one chip. The CPU and cache were mounted in one ceramic package which had to be tested together. If either one was bad the whole package was rejected. This process wasn't very efficient with chip yield, but it was probably still better than trying to get a CPU core and 512K cache on one die at .35 microns. The P2 had the CPU + SRAM cache chips on a PCB.

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

In short, I agree that MHz != performance. Before you dismiss my original post out-of-hand, though, my argument wasn't complete bunk.

Itanium's claim to fame is its notable lack of hardware rescheduling and related toys. It's an in-order machine in just about every way, and it relies on static scheduling at compile time to achieve good performance.

In contrast, x86 machines nowadays are highly out-of-order machines, and they rely heavily on register renaming and other hardware tricks to get decent performance. They spend an awful lot of transistors on just figuring out which instruction to execute next.

In all likelihood, these tricks are NOT implemented in the IA-32 -> IA-64 translation engine on the Itanium die. It just doesn't make sense. So, it's extremely likely that real IA-32 work-per-clock numbers for IA-32 code running on IA-64 are strictly less than or equal (with the emphasis on less-than) to the work-per-clock numbers for IA-32 code running on IA-32, especially for CPUs at the same clock rate.

If you agree with that assumption, then consider the best-case scenario where work-per-clock is EQUAL on both platforms. An 800MHz Itanium can therefore be no better than an 800MHz Pentium III.

Now consider the clock rate advantage that newer CPUs have. You'd have to be off by a factor of 3 on work-per-clock to not have a significant advantage with a 2200MHz part. That's all there is to it.

1.5GHz Athlons get ahead of 2.2GHz Pentium IVs because they get about 1.5x as much work done per clock. That's pretty significant (and says more about how the compilers *aren't* there for Pentium IV than anything else), but it's still a VERY far cry from 3x.

Basically, my point is that I understand that MHz != performance and that work per clock is very important. I was pointing out, though, that Itanium has TWO very steep hills to climb to run IA-32 code successfully: It's harder to get decent work-per-clock for IA-32 workloads running on IA-64, and IA-64 has a significantly lower clock rate than leading-edge IA-32. So, in the performance equation "work = work_per_clock * clock_rate", IA-64 comes up a stinker on both terms of the equation.

--Joe

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

The only real "solution" I could see to get around the slow x86 emulation would be to put a seperate, higher clocked x86 chip outside the Itanium (oldschool math-coprocessor style) and sync the two processors somehow (now that would be a chipset designer's hell!)

Shouldn't be too bad if both CPUs had the same bus protocol. If done right, it could look like SMP, even though it's asymmetric.

A different approach might be to give the IA-32 CPU a simpler bus that's not as aggressive on performance. That'd simplify system design, while still allowing x86 apps to run reasonably. Since the OS and graphics code are likely on the IA-64, the resulting system should still have decent performance, and could even have reasonably large performance benefits over a single IA-32 system. (That is to say, IA-32 code running on an IA-32+IA-64 combo machine should run about as good or better than IA-32 code running on an IA-32-only machine, even though in the combo machine, the IA-32 subsystem isn't nearly as optimized for performance as it is in the IA-32-only machine. The advantage comes in having the OS and graphics drivers running on the IA-64.)

At any rate, asymmetric multiprocessing isn't new. I program DSPs for a living. DSPs often end up on a board with many other DSPs and a completely different "host CPU" that drives them all. (That's what cellular base-stations look like under the hood.) If that isn't asymmetric multiprocessing, I don't know what is. :-)

--Joe

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

ther is absolutely no reason to assume that an 800MHz Itanium emulation of a Pentium IV can't beat the performace of a 800MHz Pentium IV with a well-written emulator.

I agree. But we're not talking about writing an emulator (which would seem to imply software-level recompilation of IA-32 code into IA-64 to reach the potential you describe). We're talking about the hardware-level instruction translation that Itanium has. Hardware-level instruction translators have much less opportunity to take advantage of the many resources of the native CPU.

Given that, the assumption that "work-per-clock" for IA-32 on IA-64 is comparable or worse than IA-32 on IA-32 seems more than reasonable.

--Joe

Re:Itanium vs. Hammer vs. All Others.

[PurpleFloyd]

From what I understand of software emulators, (not all that much, but hopefully enough ;-) you need an emulating processor that has anywhere from 2.5x to 10x the power of the emulated processor to get equal performance. While Intel probably has hired the best possible emulation talent, the differences between IA-32 and IA-64 mean that the processor will need to spend precious time decoding and translating instructions. Even if the emulator could magically translate instructions in zero time, it would almost certainly not be able to optimize the code to any degree, and as anyone who as optimized any assembly knows, you depend on all the little 'quirks' in an instruction set to squeeze the most performance possible out of the processor. Of course, Intel has had to include all the quirks of its older processors in the newer ones due to the fact that otherwise old code may not even work. One of the main aims of the IA-64 instruction set is to clear out that library of oddities. What that means, of course, is that all the old optimization techniques used by any halfway decent compiler are going down the toilet, and will probably cause a decrease in speed. You have probably experienced this phenomenon if you've ever played emulated console games -- a Pentium can be dog slow emulating a SNES, even though it has far more power than the SNES. Although emulation of IA-32 will probably one day be the standard, it is almost inconcieveable that it would be able to emulate something like a modern operating system.

Re:Itanium vs. Hammer vs. All Others.

[dannannan]

It seems that many failures in the computer industry are only about 3degrees from Microsoft.

Is there anything in the computer industry more than 3 degrees from Microsoft?

D

Re:Itanium vs. Hammer vs. All Others.

[Locutus]

Too bad they couldn't have tested them before glueing them together in the carrier.

Thanks for the explaination and I'll be sure to take one of my 2 180MHz PPro's apart when/if they fail. They've been running like clockwork for years in a SMP system running Linux ( so it's still OK to use ).

LoB

Re:Itanium vs. Hammer vs. All Others.

[Mr. Shiny And New]

The event-based programming model isn't impossible in Windows either; in fact it's how visual basic is done. It's implemented at a higher level than the message loop however. I think MFC also does event based programming but I'm not sure. The point is that with the correct toolkit you don't need to worry about the low-level design of the OS or API. Let the toolkit makers do it for you. Isn't X just a protocol for transmitting data from a 'server' to a 'client'?

Re:Itanium vs. Hammer vs. All Others.

[Anonymous Coward]

counterexample: athlon is a hardware-level instruction translator--32bit x86 pentium instruction set to riscops--which in the core effectively executes more x86 instructions per clock than a Pentium.

now, if intel can get ia-64 instructions with high levels of parallelism and few dependencies out of x86 instruction stream without making their chip even more gargantuan is doubtful...

-brian

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

athlon is a hardware-level instruction translator--32bit x86 pentium instruction set to riscops

By that argument, the original 8086, which was a microcoded machine, just translated x86 code to its internal microcode and then executed that. Therefore, the original 8086 (for which x86 is named) doesn't run its own code natively. I don't buy it. It's a dead argument.

Really, the primary difference is that Athlon spends all of its transistors focusing on running IA-32 code well, since that is its native programming interface. Itanium has its own native interface that it devotes its transistors to, IA-64, and its support for IA-32 is much, much weaker. Thus, we feel that Athlon's IA-32 not an emulation, and Itanium's is.

now, if intel can get ia-64 instructions with high levels of parallelism and few dependencies out of x86 instruction stream without making their chip even more gargantuan is doubtful...

They'd essentially have to put a simplified version of their compiler's back end on the die (a'la Transmeta and their code-morphing software) to get any kind of decent performance. They're much better off leaving that stuff to the OS or something.

--Joe

Re:Itanium vs. Hammer vs. All Others.

[sjames]

The event-based programming model isn't impossible in Windows either; in fact it's how visual basic is done.

Absolutely. GTK has an event loop as well, it's just internal to the library. The last time I saw MFC, you could see the event loop, and it auto-generated calls to methods from within the loop. The programmer was supposed to hunt down the method definitions and fill in everything between the comments with real code. Analysing someone elses code can turn into a real nightmare!

In general, event driven and procedural approaches can be mapped one to one. Should is another matter!

I much prefer (and some others don't!) GTK's approach. The last time I saw VB, it seemed to tie visual appearance and method calls too closely together (obfuscating the opportunity to assign a generic handler to multiple objects).

Recurring problem

[colmore]

This seems to be a recurring problem in a number of technology based industries. Once you get to a certain lever of high-tech, only the (very) big boys can even compete.

So here's the question: how do you keep competition alive when an initial investment costs in the billions of dollars. For any company less than Intel sized, a single bad product cycle spells complete doom. That's no kind of market to be in.

Also, wasn't this inevitable. There are a few Beowulf jokes being posted, but that's really what's going on. Increasingly high performance tasks (Google, render farms etc. etc. etc.) are using massive arrays of low-power CPUs. It costs a lot of money to develop big iron chips, and if people aren't buying them then there's no point in investing that much money.

What I'm worried about are the isolated markets that still require massively powerful, low processor number architectures. Not everything splits into nice Distributed.net packages.

Re:Recurring problem

[PoiBoy]

IBM seems to keep coming up with ways to keep the mainframe alive, so I'd imagine that they'll continue to develop processors for big iron. BTW, what kind of processors do the zSeries use, anyway?

Plus, don't forget IBM has a pretty long roadmap laid out for the G4, ..., G? and the Power series processors.

Re:Recurring problem

[Pravada]

IBM uses RISC Power4 procs I believe...They're really badass - two procs per chip, four chips in a "package" giving you eight processors on the surface area about the size of a dinner plate...like I said, badass.

Re:Recurring problem

[sxpert]

nope, 20 processors per package, 16 doing the calculations, and 4 doing the I/O

/me is an IBMer and has inside info

Re:Recurring problem

[Waffle Iron]

Speaking of badass mainframe processors, I was an intern at IBM in the mid 80's. The top-of-the-line mainframes used a central processor comprised of about 100 custom ECL chips mounted on a 4-inch-square 100-layer ceramic substrate.

The whole thing was cased in a shiny metal module. Each chip had its own sping-loaded heat slug that transferred heat to the cooling liquid sent through the module's plumbing. (100 ECL chips == major kilowattage)

They told me each CPU cost about $50,000. On a factory tour, I saw an entire pallette of these sitting on the floor, kind of like gold at Fort Knox.

These things may not perform like today's chips, but they gave meaning to the term "Big Iron"

Re:Recurring problem

[Pravada]

Hmmm...It's two procs on a die, right? I seem to remember when I was at IBM they showed it off, and there were only four dies on a package...has it changed, or am I getting senile?

Re:Recurring problem

[joib]

Yes, very true. As I see it, there are currently 3 high end cpu architectures with a future, sparc, ibm:s power and IA-64. Producing (and designing) these chips gets more expensive all the time, and the upcoming extreme ultraviolet lithography is again going to cost even more. So barring any big surprises, these 3 companies are those which I'd bet on to have the funds to play the game till the end of the current silicon technology. Hopefully whatever comes after silicon will have a cheaper entry-to-market so there can be lots of new innovative companies driving innovation and competition forward. And I think it might be very feasible. Look at all the nanotechnology startups, research on molecular transistors, self-assembling systems and of course quantum computing. Very interresting stuff, albeit it will probably be >10 years before anything like that gets out of the research labs.

Regarding supercomputing, you are quite correct in that there is little incentive to develop new vector supercomputers, taking into account increasing costs of design and fabbing the cpu:s. Cray:s upcoming SV2 seems to be an exception, though. Also keep in mind that most supercomputers, like the Cray T3E and the IBM SP, are just commodity cpu:s connected with a bad-ass proprietary interconnect. So essentially, they are just beowulf clusters with a superfast and low-latency interconnect. They are programmed through MPI, the same thing used for beowulf.

While there are few scientifically interesting applications which require essentially no communication between the nodes, like seti@home and distributed.net (if you want to do something scientifically useful with your spare cycles, check out folding@home), most get by with a quite modest amount of communication between the nodes.

What I personally see as interresting in the supercomputing area in the next few years is not the maximum flops of the DOE:s newest lets-simulate-nuclear-explosions-big-ass-fastest-s upercomputer-in-the-world-thingy, but that the increasing affordability of commodity clustering will allow projects with somewhat more down-to-earth budjets to run some really interresting simulations. Also commodity clustering is improving. Things like Infiniband and whatever they are called will probably offer higher bandwidth/lower latency than the current Myrinet / Gigabit ethernet stuff. Also the improved SMP scalability of Linux 2.4 will perhaps make it economically feasible to have, say, 4-cpu nodes in the cluster instead of the current practice of 1-cpu nodes. The downside of this is of course that applications must be able to take advantage of this, either through directly using a combination of MPI and threads/SHM/whatever or through using frameworks like Petsc or POOMA.

As a final note, remember that the tools (i.e. supercomputers) and the way we solve the problems at hand are not developed in a vacuum. The numerical methods that are developed today certainly place a greater emphasis on solving the problem via scaling through clustering than, say, 20 years ago when vector supercomputers where in the same price class as the parallell ones.

Re:Recurring problem

[roybadami]

Even for Intel, a single bad product cycle could spell doom.

At least enough doom for Intel to allow the prospect of serious competition... :)

According to Mr. Pearson...

[bobetov]

Quantum computing, 2007.

Bet on it. ;)

Re:According to Mr. Pearson...

[emmons]

LOL, unfortunately quantum computers aren't very good at adding, subtracting or a lot of other things that most programmers find useful from time to time these days. Binary systems will still be prevalent for a VERY long time to come. It just may not be on silicon for quite as long...

There's a lot of information in this thread,
specifically, this post.

SPARC is dead?

[bconway]

That's news to me. I could swear a friend of mine just jumped in on the UltraSPARC 4 project.

Re:SPARC is dead?

[Anonymous Coward]

news to me too, i'm on ultra 5

Re:SPARC is dead?

[Anonymous Coward]

Actually, I was just transferred to the UltraSPARC 4 project at Sun in Burlington, MA. I don't know of the official release date, though I've heard rumors of early 2003. I'm amazed at the quality of FUD in this "article" and that it actually made it to the front page of Slashdot.

Re:SPARC is dead?

[supabeast!]

Go take a look at Sun's sales numbers for 2001 and Q1 2002. Given that they have X86 machines ready to hit the market in June, the chances of Sun being able to convince already reluctant buyers that Sparc systems are still worth the money are rather low, especially now that big iron is being replaced with clusters of cheap systems. Sparc may not be dead, but Sparc's future as a commodity item is dim at best.

Re:SPARC is dead?

[elmegil]

When has SPARC ever been a commodity item? At least on the same level as the Intel processors? NEVER. When has that been necessary for SPARC to be a strong competitor in the marketplace? NEVER. Get over yourself. SPARC is not dead. It won't be dead until Sun itself is dead.

Re:SPARC is dead?

[froseph]

www.aceshardware.com posted a UltraSPARC roadmap a few days ago

Re:SPARC is dead?

[thogard]

The x86 boxes are a result of RAQ and most of the sun shops aren't interested in x86 stuff since they want solaris.

Re:SPARC is dead?

[Anonymous Coward]

Your friend will be looking for a job soon. I hope he knows x86 assembler. ;-)

Re:SPARC is dead?

[Anonymous Coward]

...and I'm working on the next generation of 6502 chip for Commodore - wait until you see it! Gorf never looked so good!

Re:SPARC is dead?

[HiredMan]

the chances of Sun being able to convince already reluctant buyers that Sparc systems are still worth the money are rather low, especially now that big iron is being replaced with clusters of cheap systems.

But this argument works against ALL servers and 'big iron' makers not just Sun. You could replace "Sun" with "Intel" and "Sparc" with "Itanium" and the argument remains the same.
What you're arguing here is not that Sparc is dead but that big iron is dead. And I think you're wrong.

=tkk

PS UltraSparc/// is stands up well against Itanium and probably even against McKinley. And who has the history, and client base, and code base and, and, and.... Sun does.

Re:SPARC is dead?

[rif42]

> When has SPARC ever been a commodity item?

There is a Sparc chip in my Brother 1070 PS laser printer. I guess you can call that one a commodity.

- RIF

Re:SPARC is dead?

[sysadmn]

I'm amazed at the quality of FUD in this "article" and that it actually made it to the front page of Slashdot.

You're new here, right? Welcome to Slashdot.

Re:SPARC is dead?

[Anonymous Coward]

well i'm on the ultra 6!

Re:SPARC is dead?

[Anonymous Coward]

this joke was funny 2 years ago.

Re:SPARC is dead?

[Anonymous Coward]

You will be unemployed by late 2002.

A poorly kept secret: you can make your SPARC machine faster by replacing it with an Athlon XP 2000+ for one quarter the cost!

Oracle on a 2 way Athlon machines kicks the butt of a 4 way Sun box.

Friends don't let friends use Sun hardware.

Re:SPARC is dead?

[Multics]

But this argument works against ALL servers and 'big iron' makers not just Sun.

That is the poster's point exactly. ALL big iron people will be irrelevant if Itanium based systems make it deep into the volume curve and hence are very inexpensive. I don't see how Sun will be able to keep up with the economies that Intel brings to the party. Obviously Compaq and HP thought similarly and that's why they're out of the CPU business.

So let's say that that happens... where will the marketplace go then?

-- Multics

Re:SPARC is dead?

[HiredMan]

That is the poster's point exactly. ALL big iron people will be irrelevant if Itanium based systems make it deep into the volume curve and hence are very inexpensive.

What?!? The IA-64 project IS big iron. The McKinley cpus will cost several hundred dollars a piece to produce and will cost several thousand each in boxes that are at least 5 figures - and I'm sure Intel's hoping for 6. They are not consumer chips.

I don't see how Sun will be able to keep up with the economies that Intel brings to the party.

Again - What?!? The P4 outperforms the Itanium. No seriously, you can buy a personal computer that outperforms it RIGHT NOW. Even if the McKinley then out-performs the current P4s the roadmap has McKinley's getting to only 1.6Ghz through 2003. The P4s that will be shipping then will again outstrip the McKinley (probably) before the second gen ships. Also the IA-64 does not run x86 code! (At least any speed you ever WANT to run your M$ Word on.) It runs IA-64 specially compiled code.

The IA-64 is NOT a consumer effort. This whole discussion is about "what's the next big iron processor" going to be? Big Iron has it's place and always will - a 32 processor Power4/UltraSparc3Cu server machine swings some serious frickin' power. The jobs that this machine can do will NOT be replaced by any desktop machine. At least not for a few years. ;)

=tkk

What's next?

[Anonymous Coward]

New funky commercials with Intel engineers break-dancing.

Re:What's next?

[AtariDatacenter]

No. Leonardo DeCaprio will sing the praises of the Itanic. "My monopoly will go on, and, on..."

Re:What's Next?

[mikera]

Or.... you can subdivide the 128-bit pointer into two 64-bit chinks. Use one as the primary pointer, like you say we don't need 128-bit addressing for a while yet. And then use the *second* 64-bit pointer to implement some memory management technique. Rather like the car and cdr parts of a cons cell in LISP, or something like that.

If you could implement garbage collection in the hardware, the performance of complex systems would rocket. Could also be a tremendous boon to things like functional programming languages.

128-bit chips might just be able to facilitate this. Don't knock it 'till you've tried it. I certainly look forward to having a play with one in 10-15 years time.

Re:I am confused

[spt]

I work for a major research organization blah blah blah

If I worked for a major "research" organisation which couldn't even find out simple stuff like the short term future of the microprocessor industry then I would want to remain anonymous too.

SPARC's death *greatly exagerated*

[AtariDatacenter]

Having recently participated in an NDA from Sun regarding the SPARC processor (and even with the knowledge I had walking into the meeting), SPARC is not dead or dying. In fact, I'd say that Sun squarely recognizes it as a strength. Their competition (HP for example), however, is wishing they didn't knife their baby.

As far as money to go another round, remember, Sun doesn't fab CPUs. What Sun does is design them, and they turn it over to Texas Instruments for production. And TI has their own reasons to keep up-to-date with the latest production technologies, so Sun doesn't eat that cost.

BTW: I really wish that I could talk about the SPARC presentation. I liked it a whole lot better than the NDA I attended with HP talking about their Itanic future.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

Sun's only survival will be as a legacy platform.

It costs lots of money (and time) to make a industry-leading microprocessor. SPARC chips are nowhere near cutting edge (just look at their SPEC numbers) They might have an impressive looking roadmap, but that is all.
Alpha's roadmap looked impressive before it was killed...

Re:SPARC's death *greatly exagerated*

[AtariDatacenter]

Just thought I'd add on a bit here. I just got through viewing the PDF presentation that is on Sun's website about the UltraSPARC. The online version is more of a marketing presentation. If you are a good large customer of Sun, you can probably request the NDA SPARC technical presentation.

The technical presentation has all the goodies you expect to hear when technical people are describing processors. I'm glad I got to see it.

Re:SPARC's death *greatly exagerated*

[AtariDatacenter]

Sun's strength isn't in the performance of its servers. You don't buy a Sun because you want the fastest thing out there. You buy it for the support, reliability, software base, and probably a number of other things. As long as Sun's processing performance is "on par" with competitors, it isn't going to be a liability.

When I talk with management about servers, they don't ask me which one has the fastest CPUs. They've got a "short list" of hardware vendors (IBM/Sun, then further down HP/NT).

Re:SPARC's death *greatly exagerated*

[schlach]

BTW: I really wish that I could talk about the SPARC presentation. I liked it a whole lot better than the NDA I attended with HP talking about their Itanic future.

Itanic. That's really funny.

• Itanic rituals and sacrifices
• Itan worshippers

then I ran out of ideas and had to search for 'satanic' on google

• Itanic Sysadmins
• The First Itanic Church
• The Itanic Verses
• Itanic Hampster Dance

...

(this post is obviously the set-up. now I just need someone to supply the punchline)

Re:SPARC's death *greatly exagerated*

[elmegil]

I like the fact that Itanic rhymes with Titanic.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

I bought a truckload of 10Ks last year and will never regret it.

Re:SPARC's death *greatly exagerated*

[dnhll]

One of Sun's problems is that they don't have a world class Fab. And high end logic is not TI's game, not like Intel or IBM. Granted speed isn't everything, but you start behind the 8 ball when your technology isn't as good.

Re:SPARC's death *greatly exagerated*

[elmegil]

Sun's never had a Fab, period. Just because Intel has the power of brute force (maximal transisters per square unit) doesn't mean their tech is superior. It's the architecture of the processor that makes it superior, not the bells & whistles at the Fab.

Re:SPARC's death *greatly exagerated*

[wysoft]

Sun doesn't have to worry about raw CPU power because their machines are not designed to write Word documents or play a game of Wolfenstein. Compare a Sun machine to almost any PC out there and it will smash the PC's memory and system bus bandwidth. For the kind of tasks that Sun machines usually accomplish, that is much more important when it comes to the throughput that people buy Sun machines for.

Hell, most PCs don't even have enough PCI bandwidth to fully saturate a gigabit ethernet connection unless you have a totally bare PCI bus or a system which provides each PCI slot with its own dedicated bus, as most Sun PCI systems do.

Let's not even compare the stability, scalability, and worksmanship of PC and Sun hardware. That would just be unfair to 99% of the "business" PC workstations and servers on the market.

Re:SPARC's death *greatly exagerated*

[dnhll]

Obviously architecture is important, but distance between trasistors equals time, and in the gigahertz range it starts to become a serious problem, more so than it has ever been. I don't think Sparc is dead yet, it is just very difficult to compete against Intel's resources. Sun's design has to be it that much better.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

Also add in that I've never seen an Intel based system with hot swap processors, or subdomaining of the system into multiple independant virtual units.

Sun still has a lot going for it.

Re:SPARC's death *greatly exagerated*

[Tony]

Sun's design has to be it that much better.

Oh, it is. It is.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

> Oh, it is. It is.

Then how come a lowly $2,000 dual athlon box can kick any $10,000 dual Sparc box from here to Afganistan? Give me a break. Everyone knows better.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

Well, that *is* the punchline.

Re:SPARC's death *greatly exagerated*

[wmaheriv]

He's referencing Titanic, not Satanic, as in, "Itanium will go down like the Titanic despite all hype to the contrary."

Remember that Titanic was a heavily-hyped technological marvel, and sank on its first voyage... Itanium shows every indication (thus far) of the same fate.

Re:SPARC's death *greatly exagerated*

[blang]

Only the newfangled French style rhyming.

Re:SPARC's death *greatly exagerated*

[rcs1000]

The problem with discussions of Intel vs every other chip maker is they ignore the extraordinary differences in scale between the players.

Let's compare: Sun is a company that produces operating systems (Solaris), computers, CPUs, motherboards, and a host of peripherals. (Plus it has to invent Java, J2EE, etc.) It's R&D budget was $2.0bn in 2001.

Intel is 95% CPUs. It spent $3.8bn on R&D in 2001.

Intel has the world's most productive fabs. It's capex budget is so huge, it can order the lithograohy companies and the like to build to order inside its factories. Result, it's yields are 25% better at start; and still 10-12% better after 6-9 months.

It is incredibly difficult for anyone to keep up with the Intel machine. I wish it weren't so; but it is.

*r

Re:SPARC's death *greatly exagerated*

[Scooby Snacks]

Agreed. It's simply amazing how well SPARC systems hold up under load (even older SPARCs) hold up under load. An x86 system with a load average of 50 or more is almost unusable, while a SPARC system at the same load average is still good. x86 systems start out with high performance but quickly drop off, but SPARC is more flat.

Re:SPARC's death *greatly exagerated*

[microbob]

Hehe, funny.

Well, you just run your business on that $2k AMD box and I'll run mine on a $10k SPARC.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

uh, yeah.. do you enjoy repeating your same exact responses over and over?

Re:SPARC's death *greatly exagerated*

[Paul Jakma]

indeed... and he'd be $8k better off than you.

heck, he can buy /2/ $2k AMD boxes and be redundant, and still be $6k better off than you.

presuming revenue is not so huge that $6k is a miniscule sum (reasonable assumption if his business uses only 2 AMD boxes, and yours uses only one SPARC), then he's /way/ ahead of you.

given these are the only 'facts' to hand, i know which one i'd invest in if i was a shareholder.

Re:SPARC's death *greatly exagerated*

[Anonymous Coward]

> Let's not even compare the stability, scalability, and worksmanship of PC and Sun hardware.

Don't get me started about Sun's "workmanship".
What a load of crap. The enterprise class boxes fail as much as a standard Dell box. No better, no worse.

Re:SPARC's death *greatly exagerated*

[h8sg8s]

Hmm, would that be the Intel *marketing* machine you refer to? Without even shipping a single Itanium Intel has scared many of their competitors out of the CPU architecture business. I'm wary of any company with that kind of clout and the willingness to abuse it. Thank you Sun and IBM for staying the course and giving us some choice. Those of you pining for an all-Intel world just need to glance over to Redmond for a wakeup call.

Re:SPARC's death *greatly exagerated*

[Bert64]

a Lot of this performance under load has to be attributed to solaris aswell, netbsd and linux on sparc, although superior under load than their x86 counterparts, cannot compare with solaris on the same hardware.

Re:SPARC's death *greatly exagerated*

[davecb]

Actually I disagree: if you want fast, you buy a multiprocessor from any of the Unix vendors who offer more than 4 CPUs (:-))

And yes, I'm biased

Re:SPARC's death *greatly exagerated*

[Tony]

By what measurement?

Most benchmarks on SPARC machines are done using gcc as the compiler. The Ultrasparc is a 64-bit machine; gcc does not compile 64-bit sparc binaries. (There is support, but it is still broken.) If you look at sheer IO, the sparc beats the livin' daylights out of *any* x86 machine. And if you compile using Sun's compiler, with full optimisation, there isn't an Athlon alive that'll out-perform a 950MHz ultrasparc in transactional data processing.

Or rendering, for that matter. There's a reason Pixar uses Sun machines for rendering.

Re:I am confused

[masterkool]

Hey. I have idea, don't worry about it.

So what CPU is IBM using?

[joe_n_bloe]

I could have sworn you missed one.

Re:So what CPU is IBM using?

[Anonymous Coward]

POWER!

Re:So what CPU is IBM using?

[Anonymous Coward]

The Power and PPC risc chips are the most technologically cpus on teh planet right now.

Re:So what CPU is IBM using?

[TheLink]

Mainframe or Unix or wearable pc or ...?

Itanium

[crumbz]

Given the tremendous capital requirements in building a state of the art fab along with the incredible amount of enginnering man-hours required to leap to the next level, I think we are seeing a situation similar to the one for airliners: Airbus or Boeing. They are the only two that matter because the cost of entry into the airliner market is so prohibitive. This does not necessarily apply to Microsoft and it's OS monopoly as the Linux community has illustrated. Mindshare and marketshare are not always linked.

I have hopes for Intel producing the worlds best microprocessors as that would benefit s all. Simply advocating a move to Itanium for marketing reasons or to meet revenue targets does a disservice to the computer industry.

Then again, they are in business to make $$$....

Cheap?

[wmaheriv]

Just what gives you the impression that Itaniums will be cheap, commodity items? Everything Intel has said about them seems in contradiction to this basic assumption, which lies at the core of your question.

Itaniums are targetted at the "big iron" market, where SPARC, Alpha and POWER chips currently reign. Intel has said that there will be several remaining iterations of their 32-bit chip lines, and after that, 64-bit chips will enter the mass market, but in a frob'd configuration (id est, not of the same calibre as their Itanium line).

Innovation in the CPU business

[eyefish]

This is what happens when you have a monopoly: One player who will eventually get lazy and stop innovation.

HOWEVER, things like the Java Virtual Machine (JVM), and most recently Microsoft's Common Language Runtime (CLR) should help us eventually write applications independent of the underlying architecture (I know you can do so with Java today, but Java does not drive PC sales like Microsoft's monopoly OS and Office suite currently do). Once we have a mass-market runtime environment between the CPU and the Applications, which CPU you have will not matter at all. That means that we'll have some competition back since now a company like AMD or Transmeta can trully create original products as opposed to products created to be compatible with the Intel instruction set. Of course on the other hand everyone will still be stuck running on Microsoft's CLR.

Re:Innovation in the CPU business

[GGardner]

Nice idea, but keep in mind that static compilers are extremely difficult to create for Itanium. Performance results I've seen show that while the theoretical maximum for IA-64 is pretty impressive, the actual results static compilers are generating are not so hot.

Now, try to write a dynamic, JIT compiler for Itanium, which is even hardware than a static compiler. I haven't seen any java or CLR performance numbers for IA-64, and suspect I know the reason why. :-)

Re:Innovation in the CPU business

[Courageous]

Virtual machines rely on things like delayed compiling that are fairly antithetical to the whole idea of Itanium, where they push enormous amounts of work previously handled by the CPU out to the compiler. Personally, I believe that VLIW for general purpose processors was a really bad idea that was disproven a good decade ago. Intel is in the middle of giant train wreck, and the market doesn't even know it yet.

Consider the downside of pushing the majority of your branch prediction to the compiler. For example, the compiler doesn't know about multiple processes and how they interact with eachother! This means that it's likely that Itanium boxes won't even serve transactions very well. This begs the question of what Itanium will be useful for. If it's not for the desktop, and it's not for transaction service, what the heck is it for? High end scientific computing? Competing for Alpha's market share is a big mistake, in my mind.

C//

Keep Waiting

[Anonymous Coward]

No need to get your panties in a twist over the Itanium yet.

a. There aren't any useful compilers out there (at least none that take advantage of its unique features).

b. They currently cost nearly US$3k for just one processor (just the plain ol' chip).

Until (a.) is dealt with, very few organizations are going to spring for the cost of these white elephants since existing 32-bit processors are an order of magnitude cheaper and run current applications faster. I suspect (b.) will continue to be a problem until there is a hint of competition in that niche. Maybe AMD's Hammer will do to the 64-bit market what the athlon has done to the P3/P4/Xeon market. We'll see.

Cheers,

AC

The newest chip will be called...

[RobL3]

The Unobtainium

It's release will follow the distribution pattern established by Transmeta.

Desktop processors to quickly be surpassed...

[Wulfstan]

...by mobile processors, I would say. To be honest, I think it's likely (if it isn't already the case) that processors in mobile networked devices will fast surpass desktop and server processors as objects of desire. Instead of one or two souped up power hungry beasts on your desk, you'll have 5-6 devices floating around (phone, pda, mp3 player + more) that will start to displace your desktop machine as what you spend most of your time and money on. PC processors will become an important minority concern in the world of mobility. I think that the ARM architecture is the likely future market leader by volume (if it isn't already!)

Re:Desktop processors to quickly be surpassed...

[Lennie]

Well, there are the only company in the Processor market still making money/provits (all have slipping provits or even losing money, except ARM) !

Different chips for differences

[oo7tushar]

I believe that we're going to see major competition in the future for different use chips. Sure, why spend 10k when you can spend 2k for a nice Itanium machine that does everything. Yet, do you really want to spend 2k on a machine when you cand spend 500 on a nice graphics chip that doesn't need the Itanium power.
So competition isn't dead, it's just beginning of competition and maybe Intel will move into a Monopolistic position and will have to "share" their architecture.

Re:imagine...

[Anonymous Coward]

..a Beowulf cluster of Natalie Portmans riding these things.

Itanium will be Hammered

[Brian Stretch]

The huge die size of the Itanium and its upcoming successor make the chip far more expensive than the Pentium series, so I would not expect Itanium machines for $2K. So far, the CPUs alone are several $thousand. I also haven't seen where its performence is that impressive. x86 code performence, since its emulated, is poor. Recompile or else. Intel has sold, what 500 Itanium CPUs?

The upcoming AMD Hammer series, OTOH, is supposed to be about 30% faster clock-to-clock than the current Athlon XP series (which is considerably faster clock-to-clock than the Intel P4) and start at 2GHz. Sun's recent announcement of Linux x86 platform support, with details to come midyear, suggests that they'll be moving to the Hammer (to ship Q4). Sun would certainly love to take a swipe at Intel, and Sun has made positive comments about AMD's x86-64 Hammer architecture.

Speculation: Intel gets Hammered in the second half of this year.

Re:Itanium will be Hammered

[Dave_bsr]

Speculation: Intel gets Hammered in the second half of this year.

Note to self: remember quote, and read AMD's whitepapers and documentation when i'm done with my CSE project tonight...

I'm new, i know, i'm learning architecture as a sophomore so this stuff is fun to me...

Re:Itanium will be Hammered

[screwtheNSA]

Again, many FORGET that Itanium is NOT a 32 bit processor, so no compilers geared solely for 32 bits will work properly with a CPU MADE for 64 bits! The whole chip architecture is ABOVE the x86 world as we buy it now, dump your thoughts of how clock speeds alone tell the "story" of how good or bad a CPU is.

Intel and Itanium WILL give the royal BOOT to REAL workstations, no doubt about it! Many have posted this very same "story" on the DIFFERENCES in x86 and 64 bit processors, but NOBODY SEES the truth.

Stop falling for the speel about clock cycles and how "badly" the Itanium works with current compilers, of course it's bad, it's NOT designed for x86 platforms!

Try shoving a 6-cylinder, 300+ horsepower Lycoming into an ultralight and make it fly level, good luck!

Itanium has too much "horsepower" over ANY x86 architecture in production now.

Re:Itanium will be Hammered

[sheldon]

The huge die size of the Itanium and its upcoming successor make the chip far more expensive than the Pentium...

This is a short term problem. I mean go back and look at the original Pentium 60 and where that went... Given time with the new architecture they will work on these issues and improve it. The original P60 was quite a heat generator compared to subsequent models.

I also haven't seen where its performence is that impressive.

Take a look at the floating point scores. The few benchmarks I have seen have it blowing away most of the competing RISC processors.

x86 code performence, since its emulated, is poor. Recompile or else.

The same was true when 64 bit RISC processors were first introduced. I remember getting our first DEC Alpha back in '94 and having to rewrite large pieces of our research apps to take advantage of it. Or look at the Mac when the PowerPC was introduced. The same will happen with the Intel world of applications. Given time, things will evolve and you won't look back.

The upcoming AMD Hammer series

Well we'll have to see. AMD might be able to cut themselves a nice niche in the desktop market. But Intel may eventually rule the servers where recompiling your code is not an issue if you can achieve greater performance.

Speculation: Intel gets Hammered in the second half of this year.

I wouldn't take that bet. My speculation, especially in light of your other comments with regards to Sun is that McNealy ends up on the Today show complaining about liquidity and having to sell the cottage in Aspen. Sun is between a rock and a hard place, yes they would love to take a swipe at both Intel and Microsoft. But by backing away from Sparc and Solaris and adopting Linux and AMD they do more harm to themselves than the Wintel monopoly.

On the other hand, by doing the "smart" thing, and focusing on Solaris and Sparc they also harm themselves. This is the Innovator's Dilemna that guy from Harvard wrote about and that's why I say rock and hard place. So we'll see how Sun plays this.

I still don't see AMD as a serious threat to Intel as they don't have the reputation for reliability to be widely adopted by business. Mitigating risk is nearly all about reputation.

Re:Itanium will be Hammered

[Anonymous Coward]

Er, theoretical horsepower does nobody any good if the design of the processor requires near-perfect compiler optimizations - and the current state-of-the-art compilers produce lousy code. (remember kid, we're talking 64-bit VLIW compilers - not x86/PPC/etc. compilers)

Re:Itanium will be Hammered

[Anonymous Coward]

x86 code performence, since its emulated, is poor. Recompile or else.

NOTE: Itanium is NOT emulating x86 code. It understands native x86 code just fine.

If any of the rumors of the G5 are true....

[Anonymous Coward]

and it is a 64bit chip that can also run 32 bit programs for backward compatibility...then I think Itanium will have a run for the money. Especially since IBM released their Power4 which (too my knowledge) is the first to have 2 processor cores on one die...something DEC was planning for the Alpha. It would be nice to see the G5 have something along the lines of the Power4 for sub $5,000 price. Of course now that Intel owns all the DEC stuff they gleen the good stuff from DEC technology and graft it on to their own. I am hoping that the Apple / PPC Linux world will be able to get the rest of the world to move away from x86. But...I also hoped the Alpha would survive. Who knows maybe even stuff from Starbridge Systems might be the next best thing....

Re:I am confused

[cullenfluffyjennings]

This is the best response so far.

NVidia?

[bobetov]

These guys have pretty much aced everything they've done to date, and they're slowly but surely moving up the chipset food chain with their integrated motherboard work. I'm curious to see if they'll get involved in the race.

Oh yeah, and I'm not affiliated with/sleeping with/invested in NVidia or any of it's affiliate's, subsidiaries, secretaries... blah blah blah

Re:NVidia?

[Anonymous Coward]

NVidia are actually backing out of the integrated market to some extent note that the current n-force chipset is now -graphics, with no comfirmations on when if ever they'll offer another n-force with onboard graphics or if the n-force will continue in the longer term.

Just...

[JonWan]

name it P-51 and use the 'nickname' Mustang.

Re:Just...

[leuk_he]

Or name it 486-Pro

Everthing was better then.....

Motivation for Improvement?

[txtger]

As far as I can see it, we're in for some big problems if Intel doesn't see some competition. History has told us that Intel likes to stick with architecture designs for a long time (how long have we been x86?), and likes to refuse to make up for advances in technology/speed (little endian?). So, I see it as fairly scary to have Intel running the show completely. The golden handcuff (the marketer's favorite statement, "Yeah, your old software will work with it!"), if applied when Intel has a monopoly, means a computing industry at a standstill until some sort of competition arises.

Re:Motivation for Improvement?

[javiercero]

"... to make up for advances in technology/speed (little endian?)" Errr, do you even know what you are talking about? Little/Big endian has no effect in the performance of the system, it is just how the processor sees the memory (i.e. Most Significant Byte to the left or right of the memory word). But I guess not knowing much about the subject did not stopped you from making a statement... eh? As much as I hate intel, they have some of the best fab process out there, this means that they do care about advances in the technology, in fact most of the industry is usually playing catch up.

Re:Motivation for Improvement?

[txtger]

"Little/Big endian has no effect in the performance of the system." Note the problems this has brought up. And that's just a tiny part of it. And about the idea that the rest of the industry is playing catch-up. SPARC's have led the way in making new things happen on chips. And they have a process that makes more sense and isn't trying to keep things working back to the 386. That was my point. Sorry if I looked like good flamebait to you or whatever you felt like. I wasn't looking for someone with a big ego, I was simply saying that Intel tends to be more about keeping the suits happy than making new cool chips.

No, no, and no.

[hotsauce]

No, Itanium will not become commodity as soon as you foresee because compilers and software do not exist to make good use of it (some argue nothing can make good use of it [derogatory]).

No, Intel has not killed the competition. AMD is alive and well. The PowerPC family is on the verge of The Next Big Thing (G5). And the reports of Sparc's demise have been greatly exaggerated.

No, other vendors are not irrelevant. Hitachi makes killer chips for big iron, and looks set to increase that trend. If anything, the CPU market is looking less and less like a monopoly than before.

Re:No, no, and no.

[Anonymous Coward]

The G5 is an embedded chip, not a desktop/server powerhouse.

Hitachi's chips are great for embedded things like vacumes or the Dreamcast, but they aren't competing against Intel...

*cough* PoerPC *cough*

[S-prime]

Now that the G4 has finally gotten past the 1GHz mark, and Apple has a brand spanking new Unix based OS running on it(and if you don't like it you can run others), this opens a whole new choice for the researcher looking for a new platform.

Re:*cough* PoerPC *cough*

[mojo-raisin]

We can always count on you Mac fanboys to forget that an Athlon kicks the Shit out of a G$ for 1/2 the cost.

Apples will forever be the domain of those who don't care much for performance.

Re:*cough* PoerPC *cough*

[TeknoHog]

I'm drooling for an open-design PPC system. Something as generic and clonable as the current x86 family, but using G4 or better, and modern interrupts, interfaces etc. Current machines from Apple have nothing to do with this idea - but one of these from Merlancia is on my wishlist.

Re:*cough* PoerPC *cough*

[DebianDog]

Wow, your a moron!

Re:*cough* PoerPC *cough*

[tonywong]

You mean like this?
RC5 Processor Comparison
Processor MHz CPU's Key Rate
PowerPC G4 1000 2 21,129,654
DEC Alpha 21264 725 8 11,536,680
AMD Athlon Thunderbird 1533 2 10,807,034
Intel Pentium 3 1333 2 7,559,280
Intel Xeon 1000 2 5,835,597
Intel Pentium 4 1800 2 4,870,420
Sun UltraSparc III 750 2 2,977,968
Sun UltraSparc II 450 2 1,458,333

I was going to mod you down to a troll, but I'd rather post a comment which illustrates how infantile your statement is.

Of course there is software that will, as you put it, "kick the shit out of a G$" but always remember that software drives the hardware, and if you buy a mac for gaming then you're and idiot. But if you want top notch performance for photoshop, commotion, maya and some rc-5 cracking, a PowerMac is where it's at, not to mention colorsync and the GUI.

Re:*cough* PoerPC *cough*

[Anonymous Coward]

Wow, your a moron!

HA, HA, HA!

Re:*cough* PoerPC *cough*

[Datafage]

So you pick RC5, which is notorious for being happen on the G4. Wow, that's a valid general metric. Let's talk SPEC now:

SPECint SPECfp
Athlon 800 35.0 26.1
G4 450 21.4 20.4

Ok, so the CPUs are lower MHz than the current ones, but I wasn't interested in searching that long, and they're both of the modern generation. Doesn't look so good now does it?

Re:*cough* PoerPC *cough*

[Anonymous Coward]

Oh yeah, let's use SPEC, a notorious metric in and of itself. While we're at it, let's just start doing consumer-oriented metrics like document scroll speed in MS Word and frame rates in Quake.

Please, you're almost a troll here. Discounting string FP rates, the G# line is almost comparable to x86 at a 1/2x MHz rate.

Re:*cough* PoerPC *cough*

[Datafage]

What metric would YOU present as unbiased? I'm really curious here. Please present some evidence that the G4 is as fast as a double speed Athlon in some generic benchmark. Don't even mention Photoshop.

Re:*cough* PoerPC *cough*

[Anonymous Coward]

i'll second on that... it's just so incredible how big volumes push the prices down, making everything else seem bloody expensive. it's really a shame that designs like CHRP and PREP never really went far because of internal discrepancies between apple and motorola (and/or ibm)... and after all, powerpc was originally designed cost in mind. the chips are much cheaper to design than any x86 chips (don't need any complicated x86->uop translations, don't need dual fp units to cough up decent fp performance) not to mention that with smaller transistor count, you use less silicon, thus increasing the wafer yields.

powerpc ought to have killed x86 (on the consumer desktop arena) by this time, as my friend prognosed back in 1990. however, the force of micro$oft is strong. and apple made the mistake of not allowing clones. if linux would have existed (in a market-significant sense) earlier (say, earlier than win95) then tables could have been turned and some vendors might have started producing and shipping CHRP based designs based on powerpc chips, decent interrupt handling (openPIC) and modern bootstrapping (openfirmware).

Intel CPUs will be killed by Microsoft's CLR

[eyefish]

It is my opinion that once Microsoft makes its Common Language Runtime a forced deFacto standard, and once they manage to implement it on other CPU architectures, they'll essentially have a hardware-independent Windows platform. Once that happens Microsoft will have sole leverage on the PC business. That means that Intel will NOT be needed at all for running future versions of Windows-compatible programs. Who knows, maybe this could spell a revival on new and innnovative CPU architectures, since they all will now be able to run the CLR. Side note: We *could* do this today with Java, but sadly Sun doesn't have the leverage Microsoft's monopoly does on the PC business.

Re:Intel CPUs will be killed by Microsoft's CLR

[javiercero]

They already tried that. Guess what? NT was supposed to be multiplatform! And geez do you see any of the non-X86 versions out there? Nope....

In fact, NT was developed on MIPS. And M$ is in no way interested in having the CLR running on non windows based platforms. CLR is not designed to make code machine-independent, but rather location-independent. M$ still wants you to be using Windows, it just wants to have a tighter grip on you no matter where you go.

Why would anyone even think about adopting .NET is beyond me.

Re:Intel CPUs will be killed by Microsoft's CLR

[tomhudson]

first fule of computing: runtimes suck, performance-wise.

M$ CRL is not going to be any better than today's scripting languages in terms of speed, so it'll never displace compiled C/C++ code.

So it will still make a difference which cpu your code is running on, and how well the compiler generates code.

Re:Intel CPUs will be killed by Microsoft's CLR

[Itrebax]

Has bloat ever stopped MS in the past? That's why we make faster computers, to run more demanding apps.

What will drive Itanium price down?

[sphealey]

First, you are assuming that Itanium will succeed and drive all other choices from the market. At the moment, this is far from clear, and even Intel is said to be hedging their bets with a P4 follow-on.

Second, what will drive the price of the Itanium down? Historically, Intel have announced that their latest superchip is "targeted at servers, not desktops" about a week before releasing a flood of them into the desktop marketplace (usually the ones that didn't pass spec at the higher speed level), thus driving down the price of the server chips to where no one else could compete. What will be the driver this time? Businesses aren't buying desktops, and when they do start buying again it will be pure commodity: there is zero appeal for Itanium on a business desktop. And treble for home desktops.

Which leaves high-end servers. I don't think that any datacentre manager worth his pay is going to pull out $100,000 HP N-Class boxes in favor of $2,000 Intel clones. There's a bit more that goes into a server than the CPU.

sPh

Re:What will drive Itanium price down?

[ElectricRook]

I don't think that any datacentre manager worth his pay is going to pull out $100,000 HP N-Class boxes in favor of $2,000 Intel clones.
So are you saying that you could move more people with one Cadillac than 50 Yugo's.

Re:What will drive Itanium price down?

[sphealey]

So are you saying that you could move more people with one Cadillac than 50 Yugo's

Excellent analogy. Yugos were cheap, and it appeared that they could replace more expensive cars. Then they started coming apart on the highway at speed, leading to a less than 100% chance of arriving at one's destination alive, much less on time, if using a Yugo. So they disappeared from the market in favor of more expensive, but more reliable and serviceable, cars.

sPh

Commodity

[Anonymous Coward]

When the cpu becomes a commodity then it becomes less important. It will be come nothing more than any other part of the computer - a transitor, a screw, a power supply. It will be how different folks put it together that will make the difference. Also the CPU will lose the capitial C and specialized chipset will take over - already we see graphics, encryption , and low power chipset. Specialized chipset will be driving the niche markets and the number of niche markets will only grow.

but isn't this what is next?

[simpl3x]

while i am certainly not an engineer, the idea of designing software to divide problems correctly for distributed processing is exactly where the future lies. processing power is a commodity at all levels but the top end. efficient use of resources, as well as useful programs for these platforms would be much more valuable than greater horsepower for most people... that and a t1.

Re:*cough* PowerPC *cough*

[joe_n_bloe]

Also featuring stinking fast floating point.

Dead? I doubt it.

[BlackStar]

SPARC dead? I'm not sure where you come across that idea. Having listened to a few talks down at JavaOne and chatted briefly with Marc Tremblay (head chip dude down there, father of MAJC and one designer of SPARC) they've already got design down on the next two levels of SPARC as the IV is experimental, and the V is the next production level as I understand it. MAJC seems to be the experimental platform they are using for smaller implementations and alternative ideas to be tried, based on some of Tremblay's theories.

I may be off base on some of the details, but Sun has a unified approach from top to bottom, from tools to silicon for the systems they plan to deliver. I doubt it will just throw in the towel. Ultimately, Sun ships iron, and they lead the market in their segment.

I don't see the basis for your assertion, and where you pulled 1B out of for cost I also don't know.

Alpha is AMD now, as that's where a good chunk of the people went. MIPS is still kicking, with the 14000 so far, but I won't speak to the future of that chip line. There's a lot of chip heads on this site with much better info than I on many of the lines.

One decent, although dated summary is here

Please tell me there's more information you're basing this on than consumer workstation marketshare....

64bit code

[geekoid]

before everybody starts saying (too late, i'm sure) there is no 64bit software to support this chip, I'd like to point them to here.

Re:64bit code

[lkaos]

Bah! Bah!

You should of pointed them here.

It was first after all.

More importantly...

[Kerne]

A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?

Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu. :P

Using a 20 year old peripheral port on last weeks multi-gig cpu is like sucking a McDonalds shake through a coffee stirrer!

Re:More importantly...

[iomud]

Agreed. We're disproportionaly favoring cpu when the real gains would be seen in high speed interconnects especially with storage devices. Most of my cpu's time is spent waiting for instructions and even when sent could stand to recieve them both faster and in greater numbers.

Re:More importantly...

[boopus]

Yes, In one of my CS classes we were told the statistic(which was probably made up, and i've since forgotten) about how long it takes to read the entire contents of the hard drive. If current trends keep up, it'll soon take us weeks to just read everything we can store on one hard drive. Anyone have "hard" figures?

Re:More importantly...

[Drongo14]

Not to mention that bloody cascaded 8259 interrupt controller system. Sheesh, with all the stuff attached to my PC nowadays and 11 out of 15 IRQs already allocated without any PCI or AGP slots filled and USB I'm seriously questioning the sanity of the design.

Re:More importantly...

[Bishop]

The real kicker is that the 8259 is long gone, but modern chipsets emulate cascaded 8259s. The other joke is the A20 address line. All because of two decade old legacy software.

Re:More importantly...

[smagoun]

Sure. It's not hard to find a drive that will sustain 30MB/second reads. That's 1GB every 33 seconds. A 100GB drive will take 3300 seconds to read; there are 3600 seconds in an hour. So you're looking at about an hour, not weeks. Keep in mind that as capacity goes up, so does information density. That correlates to higher read speeds (more data passes over the read head per time unit), so the total time to read the drive will remain an hour or two, not days/weeks/etc.

4 years ago..

[Marx_Mrvelous]

I would never have thought that AMD couldm possibl be successful. I was wrong then. I'm hoping/thinking that some other company will come up with a competing idea, get their foot in the foot, and surprise the world.

Re:4 years ago..

[Anonymous Coward]

How the fuck is this a troll. Man did the average IQ of the internet go down over the last few years.

Re:4 years ago..

[Anonymous Coward]

So these moderators are against added competition, better products, and cheaper prices? How is this a troll? I'm still buying AMD.

NVidia, the next player

[Animats]

My own guess for the desktop is that NVidia will put a CPU core, probably from AMD, in the next generation of their nForce part. That puts CPU, graphics, networking, sound, disk control, and the motherboard logic on a single chip. Their current nForce part already has all of that but the CPU.

If you look at the transistor counts, NVidia's graphic chips already are more complicated than most CPU parts. This is quite do-able.

Re:NVidia, the next player

[Anonymous Coward]

A few things...
1. Remember the MediaGX? CPU/Video/Sound/etc on a chip.
2. So you have a 8 million transistor chip (CPU), and a 7 million transistor (graphics) and 2 million transistors (sound, disc, etc.) on one chip. That's 17 Million transistors- that's gonna be a huge fucking die size. Whatever you save by selling an all in one system you eat by the cost of the huge @#$#ing die, higher failure rate, heat issues, etc. A big expensive chip is not condusive to low-end markets.
3. The NForce isn't a single chip, it's a set of chips. Yeah, they could put a CPU as part of the package, but why would mobo makers put a surfacemount cpu on a board that would obsolete inventory every 6 months? Why not put a socket on and let the distributors and retailers worry about what CPU to ship with it?

And the question was about _architectures_, not packaging a X86 or X86-64 in a new form factor.

Re:NVidia, the next player

[Deflatamouse!]

FYI, nForce comes in 2 chips........

Re:NVidia, the next player

[maraist]

if you look at the transistor counts, NVidia's graphic chips already are more complicated than most CPU parts. This is quite do-able.

There's more to [CG]PU complexity than transistor count. Look at the 512Mbit memory cells that run for only a couple dollars a chip.

The trick is inter-related logic complexity. To my understanding the existing GPUs have no issues with backward compatability (so much of the x86 overhead is avoided), the core itself is pipelined and modular, so the complexity is spread out across the whole chip (independent teams can work on their own components with little concern for sistern components, whereas every ounce of performance is being squeezed out of x86's which require complete coordination). Further, graphics acceleration is simply the application of graphical algorithms into silicon. While I'm not quite sure which algorithms there are, the possibilities are endless. Imagine a fast-fourier transform implemented as a SIMD floating point instruction. You create an array of floating point logic units, and interconnect them. The floating point unit is pretty much a common-off-the-shelf design, so the only real logic you apply is the interconnectivity.

I'm not saying that GPU's are easy to design, I'm just saying that hardware filters are designed this way all the time, and I would'nt be surprised if a large percentage of the nVida chips weren't stock logic modules.

-Michael

Re:NVidia, the next player

[Hektor_Troy]

"2. So you have a 8 million transistor chip (CPU), and a 7 million transistor (graphics) and 2 million transistors (sound, disc, etc.) on one chip. That's 17 Million transistors- that's gonna be a huge fucking die size. Whatever you save by selling an all in one system you eat by the cost of the huge @#$#ing die, higher failure rate, heat issues, etc. A big expensive chip is not condusive to low-end markets. "

The AthlonXP has 37.5 million transistors and has a die size of 128 mm^2, the Geforce4 has 63(!) million transistors (don't know the die size of that one), but hey - just because I spent 3 minutes checking the facts at the manufacturers websites doesn't mean that I'm right - I'm sure that that 8 million transistor chip is correct along with the 7 million tranistor GPU is correct as well, I just don't know what cpu and gpu you are refering to. Of course the two forementioned chips get quite hot, but hey - they still work, and die shrinks tend to solve some of the heat issues (I think).

"3. The NForce isn't a single chip, it's a set of chips. Yeah, they could put a CPU as part of the package, but why would mobo makers put a surfacemount cpu on a board that would obsolete inventory every 6 months? Why not put a socket on and let the distributors and retailers worry about what CPU to ship with it?"

The Hammer is supposed to contain the northbridge on die, so you could probably do the same for the southbridge as well (put it in/on a socketable chip) giving you the option of upgrading that as well.

Re:NVidia, the next player

[kubrick]

My own guess for the desktop is that NVidia will put a CPU core, probably from AMD, in the next generation of their nForce part. That puts CPU, graphics, networking, sound, disk control, and the motherboard logic on a single chip. Their current nForce part already has all of that but the CPU.


Sounds like if Commodore could have just kept up hardware R&D, the Amiga would have been in with a good chance in today's market...

Sure, build your own...

[twoflower]

Sure, build your own box for $2k instead of buying one for three times that much -- if you don't mind being fired.

You don't pay $6k or $8k for a server just because there's high markup on the parts. A lot of it is due to tighter tolerances required for high-availability or high-reliability equipment. There's greater consideration for issues of heat, RF, power consumption and stability -- and then there's the built-in redundancy for many components (power supplies, fans, etc).

It's not as simple as you think.

Twoflower

Re:Sure, build your own...

[Chundra]

Yeah. Tell that to google.

Re:Sure, build your own...

[Cirrocco]

Ja. Why not? Some people have the ability to take these things into consideration, others don't. Okay, most people don't bother to build the servers at work, I'll give you that. *I* wouldn't, anyway. But if I *OWNED* the company and it was only one or two of them? It might be a different story. Of course, I probably wouldn't bother with an Itanium in that case anyway. But it doesn't mean that I would necessarily be UNABLE to do it competently.

Re:Sure, build your own...

[Anonymous Coward]

Yeah, and have google tell you about how they have, on a regular basis, machines that literally combust into flames.

Re:Sure, build your own...

[maunleon]

a) Google is a single-task system. It runs custom software. You can afford to hand pick the software. They are just file servers.

b) if you think that the google servers are put together with parts from CompUSA by a couple of geeks in a basement, you are sorely mistaken. They are standardized and manufactured by two companies. Small profile machines are especially hard to design off the shelf due to cooling requirements.

c) Some companies do not have the rackspace to mount 20 pizzaboxes, they'd rather do with a 3U, 4-way or 8-way CPU.

d) If you are running a bank and have to do millions of transactions per minute, and your local linux guru tries to convince you to run mySQL on one hundred boxes he purchased at the swap meet, run! There is a reason why people pay a lot of money for servers like Himalaya. Same for telecom servers, etc. Not everything is a web or file server these days.

Re:Sure, build your own...

[Anonymous Coward]

Yeah. Tell that to google.

And how exactly is Google similar to a more common sort of corporate server?

Why don't you spare us the sound bytes and think a bit, eh?

Not a troll. Worse.

[Anonymous Coward]

It is another "I want someone to do my job foe me for free while I collect a paycheck" post.

Re:I am confused

[sphealey]

If I worked for a major "research" organisation which couldn't even find out simple stuff like the short term future of the microprocessor industry then I would want to remain anonymous too.

One sees this comment in every Ask Slashdot thread. It is not only tiresome, it is wrong as well. Seeking multiple opinions from diverse sources is certainly part of research, similar to skimming all the current trade and academic publications.

Sorting out the meaningful comments from the slush is part of good research.

sPh

You are nuts if you think ...

[joe_n_bloe]

... that a runtime environment where "Hello World" will require, let's say, several GB of disk, a few hundred MB of RAM, continuous online updating (also requiring continuous hardware updating), and hundreds of old and newly-arriving security holes and exploits, is going to "take over the world."

Granted, it's going to be popular for a while. But isn't what's popular *always* sucky?

Re:You are nuts if you think ...

[kubrick]

... that a runtime environment where "Hello World" will require, let's say, several GB of disk, a few hundred MB of RAM, continuous online updating (also requiring continuous hardware updating), and hundreds of old and newly-arriving security holes and exploits, is going to "take over the world."

Sounds just like Java in the 90s, hey? :) (although the security holes are MS's special addition to the experience, I imagine)

Redundant Story

[brechin]

Let's first take a look at Intel's Big Chip from Feb. 4th. and look at ExtremeTech's article about 64-bit chips.

As someone who works on making clusters of Itaniums (and soon McKinleys), I must say that I love the performance they offer, but the architecture has a few ideosyncracies (like elilo).

I wouldn't count out everyone else yet.

[jtshaw]

You talk alot about Sparc, MIPS, and Alpha in that question of yours. Yes, those are all relatively low volume products, yes they do cost a lot of money. However, the Itanium is almost like Intels version of those products, done in a slightly different way. Even though they are made in lower volumes they are still profitable because the people buying them will pay a lot more for a system. Sun can sell a 64-processor UltraSpac III system for in the realm of a million dollars and more. If you don't think they are making a nasty profit of of that you are nuts. That is why they keep advancing the technology.

People love to through buzz words like 64-bit vs. 32-bit and stuff like that but when it comes down to it what do you need on your desktop? If you are using your PC for basic development or coding there is not much to be gained from a 64-bit core at all. You don't really need anymore precision. If you are talking about scientific applications then maybe you do need the 64-bit core.

I am not saying that desktop PC's won't eventually go to 64-bit cores. However, even if you were to get a cheap Itanium right now it would perform no better, and possibly worse then your high end AMD and Intel x86 processors because few of your applications would take advantage of the core.

This question will be better asked for when Intel puts a processor on there desktop timeline that utilizes IA-64 technology.

Sparc dead? And what about SGI?

[wizzy403]

Umm... Given how well Sun is entrenched in the financial world, I think you saying the platform is dead is just plain FUD. Check with the IT department at any major financial company and ask them how many 4500 or better systems they have. (I know, I used to work for one) And yes, a lot of them are upgrading to the new UltraSparc III machines.

And for those folks doing hard research (or special effects companies with lots o' money) SGI is still king. Despite what nvidia would like us to believe, SGI's not going anywhere anytime soon for big 3d rendering projects.

AMD - Hammer Series

[Ex-MislTech]

8 processors per board possible with current
technology, on the high end version of
the 2 lines .

Can you really imagine (8)3+ Ghz 'rated'
processors with very affordable Gigs of RAM?

Imagine a Beowulf cluster of these 8way monsters.

Ex-Misltech

Address space requirements

[Florian Weimer]

At the moment, Itanium systems are worth their money only if you have large address space requirements. Intel seems to focus on optimizing the Pentium 4 compiler, and not the Itanium compiler. I doubt that the Itanium architecture will surpass IA32/x86 on the desktop (where 4GB is enough for everyone ;-) anytime soon.

That's why I doubt that we are going to see affordable IA64 systems soon. After all, the transition is quite rough, thanks to Itanium's abysmal IA32 emulation (performance-wise), so there isn't even much market demand.

In the future, Intel may well decide to switch to the IA64 instruction set before it is really time for it, just to make things a bit more complicated for AMD.

Re:Address space requirements

[Dave_bsr]

I doubt that the Itanium architecture will surpass IA32/x86 on the desktop (where 4GB is enough for everyone ;-) anytime soon.

I'm not sure if you are serious or not, but this is something i've been thinking about and others have probably said. 2 years ago, i thought 160 MB of pc100 ram was a tremendous amount. Now, I think 1 GB is a good chunk. in 2 years...we just hit the limit. uhoh. what now?

Re:Address space requirements

[Florian Weimer]

IA32 can currently handle up to 64 GB in one node, with some kind of EMS-like hack. This means that you can put more than 4 GB in your machine (actually, PCI devices need adress space, too, so you hit the barrier at 3.9 GB or so), and still use all of it.

On the other hand, the per-process adress space is still limited to 4 GB. I don't think this is a concern for the pro user who wants to show off his RAM size, though.

It depends on what you need

[jayslambast]

You have a very valid question, but you're statement,

"At that point, why should one spend $8-10k for that hardware from the likes of HP, Compaq, Dell and others when one can build it for $2k (or even less)?"

Is missing something. HP, Compaq and Dell provide more than the hardware. They provide services that go along with the HW. They use the hardware to suck you into to using their services. While small companies can build these systems on their own for cheaper, the larger companies are the ones that need to outsource some things that HP, Compaq and Dell's services provide.

Also its kind of silly to think that these IA-64 systems will be able to be built for $2k each (given the cost of similiarly performance) Sparc's and IBMs. Intel is hoping for their backwards compatibility and clout to push ISVs into programming for their systems. Once they have those vendors in their camps, the chip and server prices will go up again.

And finally, most people that would need a 64bit solution will probably need multiproc systems. OEM's will be able to provide the small systems, but once you go past the 4-8 way space, there really isn't a cheep way of scaling up any higher (, and btw, clustering is really only a solution for tasks that don't involve large sharing of data between processors that is time sensitive.) Which is where HP, Compaq, Fujitsu, NEC, and IBM will be with their high-end systems. I doubt I will ever see Dell release a system with more than 8 IA-64 processors.

Of course only time will tell what will happen next. OH, one last thing. The guy who posted should be informed that HP did not sell any processor guys, they sold some chipset guys to Intel. I'm surprised that someone that is in a processor research group would not know this. Checkout:
http://slashdot.org/comments.pl?sid=22319&threshol d=0&commentsort=3&tid=118&mode=thread&cid=0

Re:It depends on what you need

[ElectricRook]

HP, Compaq and Dell provide more than the hardware. They provide services that go along with the HW.

Yeah... They provide the OS... maybe not.

But if you have problems, and are willing to spend 35 minutes being quized on the phone. You can coerce the vendor into comming out to sell you over-priced components. Then you get to pay for your experienced (expensive) Geek escorting the vendor's sub-contractor's Geek into your data center. Doing something your Geek could have done in five minutes.

Parallel machines.

[Christopher Thomas]

Also, wasn't this inevitable. There are a few Beowulf jokes being posted, but that's really what's going on. Increasingly high performance tasks (Google, render farms etc. etc. etc.) are using massive arrays of low-power CPUs. It costs a lot of money to develop big iron chips, and if people aren't buying them then there's no point in investing that much money.

The problem is that a massively parallel computer is only useful for certain classes of problem. There are many types of problem where communications load goes up very rapidly with the number of processors, which makes a cluster (with its relatively poor communications bandwidth) impractical. This is what Big Iron is designed to be useful for.

Re:Parallel machines.

[foobar104]

There are many types of problem where communications load goes up very rapidly with the number of processors, which makes a cluster (with its relatively poor communications bandwidth) impractical. This is what Big Iron is designed to be useful for.

Also, some problems are inherently serial, and can't be easily parallelized. When single-threaded performance is important, you need the fastest single CPU you can get your hands on.

My 2c

[UTPinky]

I had a professor last semester that worked at Intel, and several things he told me, reminded me of somthing: It's still a busisness. In my opinion Intel will not make any huge move, until they KNOW that they will profit off of it. This means that they won't make any major move until the consumer market is there. For example, he was telling us that there have been times where they have come up with ideas that would in fact increase performance, HOWEVER due to their wonderful job at brainwashing the entire public into thinking that clockspeed is THE measure of performance, they scrapped the ideas because they noticed that they would cost too much to implement, and would result in no frequency increase. (Thanks Intel)

I also think that while AMD has shown that they can provide an honest competition in terms of performance, it is going to be stuck following Intel's every move, for the mere reason that Intel is "sleeping with" so many big OEMS (*cough* Dell *cough*), leaving it as the CPU for the hobbyist

Well, anyways, that's just my 2c...

Re:My 2c

[Dave_bsr]

*reads best buy ad*
Hmm...what's this? AMD chips in all kinds of computers? and not just eMachines? Hmmm...this is good.

*Reads about AMD's Hammers - x86-64...*
Hmmm...well...this is interesting too. I don't think that AMD is only "following in intel's footsteps." I doubt Intel has it THAT locked up...

Re:My 2c

[aengblom]

Hmm seems silly to me. Maybe Intel should talk with a real marketing company. The sure fire solution to this is

PIV Turbo...

Poof! Oh so it's like a biplane with a jetpack. I get it. Faster! ;-)

Re:My 2c

[UTPinky]

I was not referring to innovation. I personally believe that AMD's TBird was by far superior to Intel's P3. As for the marketing, yes I am aware that there are some OEMs that do use AMD cpus, however look at the big picture. Of the top OEMs including Dell, Compaq, HP, IBM, and Gateway, only Compaq (I believe) ships home desktops with AMD processors.

Itanium? in $2k systems?

[orz]

You're not going to be getting an Itanium based system for $2000 anytime soon.

First of all, Intel has said ever since the Itaniums much-delayed release that it couldn't really compete and is primarily released to get some infrastructure ready for when the McKinley is ready (IIRC, it's scheduled for about 3 months from now...).

Secondly, the die size for the McKinley is HUGE. On todays top-of-the-line .13 micron process, the manufacturing costs are likely to be too high for this chip to make it into high-end workstations, let alone $2000 consumer computers.

Thirdly, the competition isn't dead yet. Sparc and PA-RISC may be dead, but Sun offers competition, and IBMs Power4 will be a decent competitor. Alpha does indeed look to have disappeared, but I thought I heard something about some Japanese company buying rights to some Alpha stuff, and planning on a big die shrink and integrating a large cache (which is all the Alpha really needs to compete, for the near future).

Fourth of all, the performance of even the McKinley is questionable. Compilers for it's IA64 instruction set are still quite poor, with little sign of the anticipated improvements. It's predecessors, the Merced/Itanium, was dog-slow at most tasks (though good at floating-point). The most recent benchmarks show the McKinleys 32-bit performance as terrible, though it's floating-point performance is supposed to be stellar, and its integer performance decent (when combined with an enormous on-die L3 cache...).

Anyway. Intel just likes the Itanium because the the instruction set is sufficiently complex that the prohibitive cost of designing a compatible would raise the cost of entry to the market enough to give them a more secure monopoly for the next decade.

Re: wide load comin through

[Anonymous Coward]

Score: 2? Why did the moderators mod the above upward? fscking idiots.

The quick brown fox jumped over the lameness filter.

64-bit isn't necessary - and Itanium may suck

[camusatan]

The implicit assumption that the author is making here is that 64-bit CPU's such as Itanium will be the 'next big thing'. I'm not sure - 64-bit CPU's really only are necessary for machines that need more than 4 GB of VM space - and with various x86 addressing extensions, some IA32 CPU's can address up to 16 GB (I think).

Now don't get me wrong - 64-bit filesystems are great, and necessary - being limited to 2GB or 4GB files is terrible. But no 64-bit CPU is necessary for that kind of thing, the filesystem just has to be written as 64-bit (which is easier said than done, and could easily sacrifice backwards-compatibility with various API's, but I digress...).

That being said - Intel might very well be moving down the wrong path - the Itanium is a huge, expensive, hot, completely new chip. Even Intel is hedging its bets on whether or not Itanium will take off - and AMD is poised to eat Intel's lunch with their new Hammer design.

Who knows, perhaps all CPU's from now on will be compatible with x86 IA32, and innovation will be in the various processing units that sit behind the instruction-set decoder. Take a look at AMD or Transmeta for examples of that, already.

Re:64-bit isn't necessary - and Itanium may suck

[dlapine]

Both Linux with 2.4 kernels and Windows NTFS support large files (files greater than 4 gig) on 32bit CPU's. Yes, there is a need for apps to be upgraded to support this, but RedHat Linux 7.2 supports this out of the box.

It's possible that updates to the Itanium (McKinley and so on) may prove to be more useful than the Itanium itself. Anyone remember when the 60MHZ Pentium was released? It was hot, expensive, huge and completely new, just like the Itanium. It wasn't really worth the purchase price, in comparison to what was available in 486 at the time. You have to start somewhere...

64bit CPU's will provide a much better range of addressing, both for RAM and filesystems. They will also be faster than their 32bit cousins. How do I know? Well, we have 2 large-scale linux clusters here at NCSA. The IA32 cluster has 512 dual PIII nodes at 1.0 GHZ. The IA64 cluster has 160 dual Itaniums at 800MHZ. The Itanium cluster is about 10% faster for its top500 run. Check out entries 34 & 41. Yes, the Itanium cluster has more RAM per node than the IA32 and it was running RedHat 7.1 versus RedHat 6.2 for its older sibling, but you're still looking at a factor of 3 in CPU to CPU comparisions.

To sum up, Itanium doesn't quite suck :) Let's hope the AMD 64bit CPU's are even better!

Re:64-bit isn't necessary - and Itanium may suck

[megabeck42]

The brunt of the installed computers in the world do very mundane things - they type papers, run spreadsheets, browse the internet, and balance checkbooks. Similarly, most of the cars on the road out there are taking kids to school and soccer practice, driving back and forth from work, and getting groceries. Porsche proved itself on the race-track, Honda proved itself by building cheap, reliable cars.

I think the biggest thing in computing would be a route similar to the game consoles - controlled hardware and software environments. Commodity hardware that runs a straightforward operating environment designed specifically to do common computing tasks. 32 bit processors are ideal, have smaller transistor requirements, simpler busses and simpler logic than 64 bit brothers.

I think the computer market is maturing from glitz and glammour to reliability. People are getting to the point where they realize that a 1 gigahertz computer will type letters, send email, and play dvds just as well as a 2 gHz computer.

Lots of people have tried to create a commodity computer - but, there have been few successes. In fact, the only notable ones are the iMac and iBook. Niether are powerhouses, they don't even play games. But, they're great for a distinct majority of the computer using audience. They're cheap and have tightly controlled hardware. Apple is even trying to control software, they're making quality apps to suit common computing needs. iTunes, iPhoto, etc.

I'm a big fan of Apple for their move to OSX, but I appreciate the elegance of their iMac/iBook solution. They're not making Porsche's, they're trying to make Hondas. So far, they're doing a damn good job. Some people need Porsche's and they buy them. If you need 450 horses and 490 foot pounds of torque, you can get it - but, most people don't need it.

Re:64-bit isn't necessary - and Itanium may suck

[tomhudson]

Just a historical note:

The 60Mhz pentiums were released AFTER the 66Mhz chips. They were chips that failed the 66Mhz clock, and were underclocked (Intels' yield at 66Mhz was only about 18% half a year after they went into distribution, so they had a huge initiative to rebadge chips as 60Mhz and get back some $$$)

Re:64-bit isn't necessary - and Itanium may suck

[susehat]

And what about 36 bit? from what I remember, the vax(yes, old, but still 36 bit) could handle a max of 64 Gb. why not transition to 36 bit for the desktop and let 64bit wait in the server wing?

Re:64-bit isn't necessary - and Itanium may suck

[Anonymous Coward]

The implicit assumption that the author is making here is that 64-bit CPU's such as Itanium will be the 'next big thing'. I'm not sure - 64-bit CPU's really only are necessary for machines that need more than 4 GB of VM space - and with various x86 addressing extensions, some IA32 CPU's can address up to 16 GB (I think).

Yeah, and in fact 32-bit CPU were only necessary for people that needed more than 64 KB, and if you needed 640 KB, which was supposed to be enough for anyone, you'd just use the various x86 addressing extension, some i286 CPU could address up to 1024 KB.sigh.

The truth is: the CPUs need about one new bit of addressing per year, it has been that way since more than 20 years. That's why 64-bit CPU ARE the next big thing.

Re:64-bit isn't necessary - and Itanium may suck

[Guy Harris]

from what I remember, the vax(yes, old, but still 36 bit) could handle a max of 64 Gb.

You're either trolling or misremembering or think "N-bit" refers to the size of physical addresses. VAXes were 32-bit processors; I no longer remember what the page table entries looked like, so I don't know how large the physical addresses were (but the VAX-11/780 was designed in an era when 4GB was a lot of disk space, so VAXes may well not have had even 32 bits of physical address).

32-bit machines can handle more than 4GB of physical memory. (In fact, the Pentium {Pro, II, III} and successor x86 processors can support 36-bit physical addresses.) They just can't handle it conveniently within a single process (no, segmentation on x86 doesn't make things better; it's not even necessary).

There are some people who might be delighted to see 36-bit desktop machines, but I doubt you're likely to see any new 36-bit general-purpose processors any time soon.

Clockless Processors

[bcjanes]

As long as processors are limitted by a clock speed, they are being held back. Asynchronous processors would cause other problems with the rest of the system hoever, data bits crashing in the mobo circuitry and the like.

Now if we had fiberoptic mobo's and circuit boards, holographic RAM, and figured out a permanent storage solution replacing hard drives that used optics for storage and data transfer, the rest of the system might stand a chance of keeping up.

Consolidation is a Fact of Life

[dso]

Just look at the auto industry. GM, Ford, Chrysler began the North American market by consolidating all the smaller auto companies and dominated for years. Then along came Honda, Toyota, Nissan and now they have made huge gains.

The fact is that even though it looks impossible to overcome Intel at this point, someday someone will.

Re:Consolidation is a Fact of Life

[Peyna]

In 1999, here's what the market share for automobiles in the USA looked like:

General Motors: 29.2%

Ford: 18.1%

Honda: 9.8%

Toyota: 9.1%

Chrysler: 8.5%

GM has acquired Saab since then, and I'm sure a few other small companies have changed hands, but their numbers are small enough to not really matter.

Apparently Chrysler is no longer 1 of the Big 3.. but GM and Ford look pretty untouchable right now. (Doesn't mean it will always be that way.)

The killer is custom-made systems...

[Kjella]

Rewriting standard applications to take advantage of the Itanium is one thing. However, companies that need a $10k+ server usually have programs that are specialized. After 20 years of the x86 standard there's a large codebase, although given a few improvements along the way. If you read the FreeDOS article a little while back companies were still running DOS in production systems, because it *works*. Porting it to Itanium will be a lot worse than porting it to x86-64 and Hammer. Let's face it, the hardware cost is usually minimal today. Software programmers however, are not cheap.

Kjella

you're thinking too far away

[Anonymous Coward]

You won't see anybody building an Itanium for $2K, since the chips cost more than that when you buy 1000 of them at a time.

Maybe 10 years from now, but that's too far off.

1) HP's PA-RISC is as dead as Intel's x86

2) Alpha should regain the speed crown with the EV7 for a while, so they aren't dead yet. They've just announced they'll be dead in a few years :)

3) IBM's POWER4 is the current speed king and is likely to be around for a long long time.

4) MIPS.. Aren't these popular RISC chips in the world due to their embedded use? (N64, Playstation, networking) At 500Mhz in SGI's machines they are pretty dead, but various MIPS chips are doing quite well in emerging areas. Infact AMD just bought a MIPS company.

5) Sparc has never been that great CPU vs CPU with the other companies, but I expect them to be around for a fairly long time still, just based on their installed base. Their customers never really bought on performance (otherwise ALpha would still be around!), but on service and reliablity. As long as they can provide good enough performance they'll be around.

The next Itanium is HUGE making it very expensive to produce (meaning you won't ever build a system for under $2K with one!), requires a LOT of optimization in software to get accepable perfomance (meaning it'll suck unless you run active profiling optimizations and I doubt most game companies will even do that), it uses a lot of power and creates a lot of heat (it makes the Athlon/P4 look like embedded chips!), and it isn't really compatible with existing software. Nobody is going to run Win98, WinXP, or even GNU/Linux on it on the desktop.

The next Itanium will be more popular than the last, but it won't even register on people's radars as it won't provide the best performance, it won't have a bunch of software written for it, and it'll be expensive. Apple will sell more iBooks than Intel sells Itaniums for the next few years.

SPEC benchmarks for Itanium (It's slowwwww...)

[Anonymous Coward]

Anyone who has actually used an Itanium knows that they are slow. Here are the base integer and floatping point SPEC benchmarks so that you can see for yourself how slow it is compared to a high end PC.

The benchmarks are from:
http://www.spec.org/osg/cpu2000/results/cpu2000. ht ml

Dell Precision 730 (800MHz Itanium)
CINT2000 314
CFP2000 645

Dell Precision 340 (2.2 GHz Pentium 4)
CINT2000 790
CFP2000 779

As you can see the Itanium sucks at integer applications. Check the table and you'll see even a Dell 700MHz Pentium III system beats it!

In short the current Merced based Itaniums suck and are extremely overpriced. Even Intel and HP have said to wait for McKinley, the next IA-64 chip.

Re: wide load comin through

[Anonymous Coward]

If I had mod points I would have this at -1 now :(

I bet that person has some troll friends.

Big Iron

[Anonymous Coward]

Remember when Dinosaurs ruled the earth? The giant pens sucking power from the companies as fast as they could be given? Competition will arise if , for no other reason , than a better solution will come along. Remember to that By the time something is perfected , it's probably obsoliete.
IBM decided not to market home computers because no one would want them. DOS was the OS of choice cause someone wasn't home. Whatever the next big thing will be, it can crush the jugernaught as well as the ants. I know Intel is huge , and that they have a vested interest in making faster and faster computers , but the market is about to pass the faster is beter paradigm in chip manufacture.

Re:Big Iron

[maverick_and_goose]

the problem is that you are talking about software. not that it is easy but it is easier to make an OS. i can if i put in enough time, and it would be alot of time, make a OS that would run something and that would cost me $0 so yeah any kid at college can make the next revolutionary OS or software application but if I don't have capital I can't make a chip

plus im a software guy and I will tell you that you can be a lot dumber and pull of being a programmer than you can be dumber and do chip making. so in conclusion anyone or group of people if they spent enough time might be able to make some decent software but this is not the same for hardware

Get that new heat sink ready...

[AtariDatacenter]

Can you say, "Heat dissapation for high wattage CPUs?"

Re:Get that new heat sink ready...

[Anonymous Coward]

Yeah, I can say that.
But I'm wondering; do you actually know the wattage of AMD's future Hammer chips?

Re:Get that new heat sink ready...

[be-fan]

Umm, the first Hammer proc (clawhammer) is a laptop CPU with 100mm^2 die size. Should be pretty cool...

AMD patents, mild overview of some of Hammer

[Ex-MislTech]

http://www.chip-architect.com/news/2001_10_02_Hamm er_microarchitecture.html

Ex-Misltech

Itanium will take YEARS to commoditize...

[barfy]

There is little compelling need for desktop users (the ones that create the volume for commoditization) to move to 64 bit systems.

Until there is breakthrough brought on by computing speed, we will see a stall in computer upgrading as we have seen in the past.

I expect we will see more things like the Imac (very cool computers), before we see a press for new computers for speed.

The two things I think will create the next level breakthrough.

Real Time CGI imaging at Toystory/Mosters INC/FF, level of quality. We can probably predict precisely WHEN that will be possible by mapping the development speed of 3d hardware, memory, software breakthroughs, and polygon density to date, and where the predictable bottlenecks will appear. (My suspicion is that we are 5-8 years away).

The other breakthrough which I think would do it, and right now it is very difficult to predict when it will happen, but I suspect that adoption would be pretty rapid, is real time voice interaction that is 5 9's accurate. This is likely to appear after a certain speed level of computers, and a breakthrough understanding/algorithm for speech recognition.

However, I suspect the AMD x86-64 solution may be adopted much faster than the Itanium solution. Likely there is an app out there that may have a large enough niche to require 64 bit apps, and the rest of the apps on the computer would be 32 bit. I suspect that the app will be imaging or video related, and that will create an adoption around the AMD solution, before the Itanium moves out of the server market to the desktop market where it will be commoditized.

Re:Itanium will take YEARS to commoditize...

[Anonymous Coward]

what about deerfield? supposed to be the commodity version of ia64 in mid-2003.

Re:Itanium will take YEARS to commoditize...

[donglekey]

You are missing a big issue for computers that will emerge, and that is real time compression of video codecs like JPEG2000. JPG2k has seemed to go every which way but sober, but it is a proof of concept. Imagine a codec 2 or even 4 times as good as DiviX. Enocode it in real time and you have a very good video stream on your hands. Two people with broadband could video conference very comfortably.

A better link ...

[Anonymous Coward]

Better link ...http://www.linuxia64.org/

Mismatch?

[90XDoubleSide]

except IBM Power4 [& friends G4, et al]

While the Power4 will no doubt compete with the Itanium in the server space, since many people are talking about when 64-bit chips will hit the desktop, you should note that its "friend" the G4, which has been out since before the P4, is by no means meant to compete with new Intel offerings; the Goldfish PowerPC 8500 ("G5") is aimed squarely to dominate the desktop space before Intel can get to it with 64-bit chips. It's ability to run 32-bit code at much better speed than the othet 64-bit offerings makes it much more appealing to people looking to transition to 64-bit on the desktop, and if they can pull off the .13 SOI, 500MHz RapidIO bus, etc. it should reassert A.I.M.'s competitiveness in high-end desktops. Now when it will actually ship, how much of this will get implemented, and at what frequency it starts at is anyone's guess.

Re:Just wondering, not a troll. SUN IS OUT

[(outer-limits)]

Sun is out alright, they are going to release a Linux box based on intel x86. See here.

Grammer Problems

[ZeroEpoch]

Is it just me, because I can hardly understand what this guy is saying. It doesn't even appear to be english, well not coherent english.

Re:Grammer Problems

[Anonymous Coward]

why would you have problems. You dont seem to fare much better.

Re:Grammer Problems

[Anonymous Coward]

People in glass houses shouldn't throw stones... That's "grammAr", by the way... and "English", not "english". Also, generally in English, questions end with a "?", not a "."

Re:Grammer Problems

[Anonymous Coward]

Your grammar and spelling is worse.

Re:I am confused

[Anonymous Coward]

She doesn't want opinion, she wants hard facts about the microprocessor industry.
The best source of this information is the microprocessor industry.

/. opinion is good when you are researching people's opinions. Not when you want facts.

The Answer

[sharkey]

A boring movie titled "Itanic", starring an effeminate man-boy and a chubby love interest.

Re:Three way race...

[Ex-MislTech]

A breif read thru on your total post history
points to a care-free thoughtless method
to your posting .

If you want to undertstand why AMD has a chance,
read this ...

http://www.chip-architect.com/news/2001_10_02_Ha mm er_microarchitecture.html

Ex-Misltech

Sparc dead..? One word....

[rosbif]

Solaris.
People don't buy Sun just for the hardware, they're investing in 100's of person-years of 64bit software development and tools (and don't make me ROFL by pointing to M$ofts 64 bit efforts...)

Re:Sparc dead..? One word....

[rtaylor]

Funny.. Hardware is the only reason we buy sparc. Not thousands mind you, but several hundred.

Anyway, any and all software we write is developed under another unix (bsd, linux, osx) then moved to Solaris for testing and final implementation.

So.. The only reason those Suns are around is the ability to handle a load of 1000 which still being reasonably responsive. Most of that reason is the hardware.

Development hopes someday that research will switch the OS to something a little more reasonable. I want tar with gzip built in it damnit!

Re:Sparc dead..? One word....

[Anonymous Coward]

well, the, for god's sake man, install the GNU version! I even used to see a binary floating around on sunsite ! :)

Re:*cough* PowerPC *cough*

[Anonymous Coward]

Also featuring a proprietary design that Apple has burned way too many people on for it to be considered viable for any other OS than Apple's.

Re:Just wondering, not a troll. SUN IS OUT

[jproudfo]

Give me a break.

Anyone who sees the recent Sun announcements (re: Linux) as the end of SPARC or Solaris, clearly doesn't know anything about the business world or about Sun.

Yes, Sun has made an announcement to start supporting Linux. This is no big surprise, especially after the Cobalt aquisition.

This doesn't mean that they are switching to Intel or giving up on the SPARC architecture.

SPARC is far from dead. All you have to do is talk to anyone within Sun to see the U4 and U5 roadmaps. Sun firmly believes in their architecture and has/will spend the R&D to to continue to develop it.

Plus, the install base of these technologies is much too large for them to just give up on them.

Look at HP, for example... Here is a company that is part of the engineering process for Itanium. They've already committed to use Itanium on their higher end servers, but they aren't completely giving up on their PA series CPUS (yet). All of their new systems take both.

No company wants to alienate the majority of their install base. :)

Re:Dead? I doubt it.

[elmegil]

I don't see the basis for your assertion, and where you pulled 1B out of for cost I also don't know.

I dont' know either. If it were a valid cost though, it's worth nothing that according to the annual report, Sun has $18B in assets, and I'm willing to bet at least 1/18th of that is "in the bank" and available. SPARC is the foundation of the company, moreso even than Solaris, and it's hardly dead.

Re:Itanium? in $2k systems?

[Anonymous Coward]

ummm... deerfield?

Sorry...you're wrong..

[Croatian Sensation]

Umm. That was a bad example. Just a quick search of the web will lead to several manufacturers that have just recently come into the airliner market. Check out Bombardier, Embraer, and Fairchild Dornier just to name a few. What happens when the big guys get complacent like Boeing and Airbus, the little guys poke their noses into a niche and run with it. All of these companies have the ability to compete with the big two...

The same will happen in the CPU market.

Re:Sorry...you're wrong..

[Jeffrey Baker]

Whoa there. You just pointed out three HUGE companies entering the aircraft market, which strengthens the point that the barriers to entry are high. Bombardier manufacturers at least part of every passenger rail car currently deployed. They have been in the aircraft business since 1989 IIRC, their revenues just on aircraft exceed $10bn Canadian annually. I believe they are the thrid largest civil aircraft company after Boeing and Airbus. Their R&D efforts are funded significantly by Canadian tax revenue. So, all it took for Bombardier to break into the aircraft industry was to leverage a strong position in the rail market and get the backing of a major national government.

Embraer is a $6bn company that has been around for over 30 years. Again, it took no small resources to break into the commercial aircraft business: they funded that effort with their cash cows in suppyling and repairing military aircraft in the world's forgotten air forces.

It is also strange to say that Fairchild is some kind of up-and-coming civil aviation company. Both Fairchild and Dornier have been around since before WWII. Their chief product was developed with R&D money from Daimler Benz, and they are now owned by the largest insurance company in Europe. Also I believe they have not delivered any aircraft to major customers since their reentry into the market.

It may be that Boeing and Airbus are not invincible, that the age of the large jet has passed, and that a company with few resources and a big idea could come along and knock those Goliaths over. But, the three huge companies you mentioned don't qualify for the role of David.

Re:Sorry...you're wrong..

[rtaylor]

If you look at how Boeing got into the market in the first place it's not out of line to consider a company like the above mentioned knocking them out.

Boeing dropped everything on a huge risk called the Jet. Make or break. If Bombardier were to drop trains, planes, snowmobiles, boats, etc. and make a 'kick ass' shuttle thats cheap to buy they could potentially take over most of the airplane market. Leaving Boeing in it's wake.

If Boeing remembers what they did, and can make that jump in technology (again -- like twinprop to jet) they'll corner the market for quite some time.

Bought them a 15 year lead last time, and took 'em from second (third?) in the market to first with a huge margin.

Re:Sorry...you're wrong..

[calidoscope]

Boeing owes it's lead to the B-47 - virtually all Beoing jets are tweaks of the StratoJet.

Re:Sorry...you're wrong..

[Paul Jakma]

the de Havilland Comet was the "lets take a huge risk and build a jet" trailblazer.

boeing et al learned from the Comets mistakes (rapid development of metal fatigue in fully pressurised aircraft being the major one).

where boeing did well was its 247 twin-engined airliner, which paved the way towards development of large four-engined aircraft, most famously the B-17.

Re:I am confused

[Anonymous Coward]

Asking a source like slashdot where 99% of the posters are l33t script kiddies and bored VB programmers is not a particularily good starting point.

You work for a research firm?

[Wakko Warner]

As what, a janitor?

My question to them, and to the assembled masses here at Slashdot is what happens next when Itanium is real?

It's been out for almost a year now, Super-Sleuth.

- A.P.

Re:You work for a research firm?

[jo42]

"real" as in you can go down to Wang Woo's Komputer Shoppe, buy a no-name Taiwanese motherboard and the CPU for $300 tops. Tosser.

Re:You work for a research firm?

[Wakko Warner]

Like you could with the Pentium Pro?

Stupid fucking retard.

- A.P.

What about the StrongARM.

[orichter]

The desktop and laptop CPU market is starting to saturate. Only a few percent of the population, however, have PDA's. Cellphone markets are starting to saturate as well. There doesn't seem to be a killer app which really demands the new Itanium class of CPU's. What's really starting to take off, however, is the PDA market. I'm thinking that maybe, finally, we are going to get those silent computers which can sit in our stereo racks without massive fans and huge amounts of heat. I for one don't need an Itanium. I'm sure there is an app that will make it really desirable to have an Itanium, but I haven't seen it yet.

Wrong point of view guys...

[MrPerfekt]

This is a typical example of someone lacking clue and claiming to be authorative. I can admit I know nothing of most of the arch's there, but I can tell you about the SPARC.

The UltraSPARC for workstations has always kinda been a niche market. For the simple reason, that you can get an Intel box with far more hardware options and software support and for far less money.

However, in the server market (which I doubt the submitter has ever had any experience in) is a different story. For the most part, hardware support is irrelevant if it does what you want it to do. Which in most cases is just be some type of Internet server.. be it oracle databases or web servers or whatever. People that run critical servers and need the UltraSPARCs stability and Sun's support (or this can go for some other alt. arch. like IBM and an AS400) almost always do buy something other than Intel for their mission critical stuff.

Anyway, my whole point is, just because you don't use it in your workstations (or your webserv0r on your dsl line) doesn't mean its dead. Workstations and Servers are and hopefully always will be very very different to actual companies that need a different level of service from their servers. I suspect because the submitter has a lunix server with a mandrake enterprise kernel, he thought he was an enterprise business.

Re:Wrong point of view guys...

[sql*kitten]

The UltraSPARC for workstations has always kinda been a niche market. For the simple reason, that you can get an Intel box with far more hardware options and software support and for far less money.

I think you may be confusing "workstation" with "high end PC". Sun's equipment has always been popular with workstation users, in engineering, finance, oil and gas, scientific research, academia, etc.

Remember the Pentium Pros

[Pharmboy]

Yes. Yes I do. I still have 4 servers (IBM Personal Server 325) that each have two of the Pentium Pro 200's in them. One is running Win2k, the others are running Linux (rh6.2). They each have 4 SCSI drives (ufw/40mbps/2.1gb). They each have around 35000+ hours on them (4 years x 24/7). I have not replaced them because I have only had one go bad (now is spare parts).

I kept them because the quality of the ppro is UNREAL. I have not replaced them because the quality of PIIs and PIIIs are, well, OK at best, and Xeon's are simply overpriced for what they are.

Yes, I am just strengthening your point, to make a point. Those of us in the "smaller" world of serving will take durability over speed, reliability over clock ticks. What will get me to switch to AMD or Itaniums is that warm fuzzy feeling you get when you go to sleep, and don't have to worry about driving into town (30 minutes away) at 3am to reboot (or switch over) a server.

I did just order a Dell dual p3/1000, but it wont replace any of those machines until I have 90 days with it in place. (average uptime on the Linux IBM's is over 6 months)

Re:Remember the Pentium Pros

[eventhorizon5]

I've got a custom built production server with 2 ppro-200s that's running Linux 2.2.18. The system is completely rock solid and has excellent performance as a server, even in today's standards. The last system uptime was about 140 days when I had to bring it down for a kernel upgrade to 2.4.17 (I ended up going back to 2.2.18 because 2.4 was too unstable). In my opinion the PPros were probably the best processors ever made by Intel.

Build an $8-10 server for $2k - um, no.

[sirwired]

No, you can't build something like a Netfinity (oops. er - xSeries eServer) in your garage for $2k. Built into a high-level xSeries is:

1) Hot-pluggable power supplies, drives, and PCI - slots.
2) Built-in hot-plug SCSI
3) Integrated service processor for diagnostics (essentially a computer within a computer)
4) Extremely well-tested box. (Very important to do integration testing on high-end units.)
5) Very nice, serviceable, rack-mount chassis
6) Crap-load of PCI slots
7) Light-path diagnostics. (Lets somebody without training figure out what's broke.)
8) IBM Director
9) Well-designed cooling that would be impossible to achieve with a garage box. (Do you know how to do airflow modeling?)
10) Support.

The list goes on...

Yes, they will become a commodity, in that you will be able to get them from multiple major manufacturers, but don't expect to build it yourself in your basement anytime soon.

SirWired

Re:Build an $8-10 server for $2k - um, no.

[cabbey]

Exactly! It always amazes me how many people don't take this into account! The $6K you saved on parts will be lost the first time you have a power supply failure and crash the whole machine, or have a drive go bad in the raid and have to take the whole box down, pull it apart and swap one drive rather than just walk up, pop a clip, slide out the drive, slide in a replacement and snap it back, then login as root and issue a command to put it back into the raid. Compare no down time versus at least a half hour (if you rush the job, thereby risking doing more damage). The savings just aren't worth it for any business, let's face it that's why IBM exists and makes the kind of money it does.

Re:Anti-semitic processors

[Anonymous Coward]

Yeah, but do they run JEW/Linux?

I guess you'd only be able to use good Capitalistic Operating systems like Windows and Qnx.

Yes, but HE works for a RESEARCH FIRM!

[Wakko Warner]

So he obviously knows more than you.

Now sit down and let Research Boy do the talking, because everything he said was right!

- A.P.

Re:The Ace of Spades

[Anonymous Coward]

obligatory "Lenny ROCKS!" post.

Re:*cough* PowerPC *cough*

[Anonymous Coward]

BSD is proprietary?

The GUI and applications, yes, the OS, no.

Itanium will not make it

[Anonymous Coward]

As the parent poster said - the compilers are insanely difficult to write. It's also a chicken and egg problem - why write a program for it if no one is using it? Intel would be well advised to simply GIVE AWAY a million machines to businesses and schools to get the ball rolling. A kindler, gentler monopoly!

Re:Wrong point of view guys...-AMEN

[Ex-MislTech]

Amen,

I have been a Cellular TCAP processing room
in Arizona and the boxes routing those hand
offs from tower to tower and doing the
database dips were Sun, and if you talk to
most Telecom companies they are gonna say Sun.

Alot of DOT BOMBS bought sun boxes and then
ended up selling them on Ebay for a dime on
the dollar, because THEY "The DOT BOMB" sucked,
not Sun .

Sun took the hit in Sales, and then fear came
along and they got hit, again, and again ....

Sun will have another day in the 'Sun' LOL

Ex-Misltech

When will we finally have CLOCKLESS CPUs?

[Anonymous Coward]

Give up on the clock - we are wasting tons of potential CPU resources! Clockless chips are inherintly more efficient. Intel - wake up!

Re:When will we finally have CLOCKLESS CPUs?

[sn0wcrsh]

Have you ever tried to do large scale clockless design?

Imagine a ballet without music.... Very hard to
get things right.

Re:When will we finally have CLOCKLESS CPUs?

[KowShak]

The University of Manchester (UK) has done work in producing several different implementations of a fully asynchronous CPU. It supports the ARM instruction set too...

http://www.cs.man.ac.uk/amulet/

Re:When will we finally have CLOCKLESS CPUs?

[Paul Komarek]

If I understand "clockless" cpus, wouldn't the analogy be a ballet with lots of bands waiting on dancers, and dancers waiting on each other?

-Paul Komarek

Re:When will we finally have CLOCKLESS CPUs?

[morbid]

Think of it as the action of one dancer triggering off the action in another and so forth, like a chain reaction.

Re:When will we finally have CLOCKLESS CPUs?

[fitten]

Efficient how? Power? usually. Space? hardly. Typical asynchronous designs can easily require 33% to 50% more gates than clocked designs. Think about your 25M gate CPU suddenly being 37.5M gates. Then you get into all the problems that large chips have. Clockless isn't free, you still have to pay for it, just in other ways. Of course, the arguments against clocked designs is that clock drivers can take up huge amounts of real estate on the chip too. I think I recall one of the Alpha CPUs having about 10% of its die dedicated to driving the clock signal.

Actually, 4gb is not enough

[Anonymous Coward]

The main reason to go to 64bit is not for the CPU speed but because it can address more RAM. 4gb on a 2-cpu system is not enough these days. RAM is very cheap, cheap enough that most databases could be buffered entirely in RAM, IF the cpu could address it all. That's what I'm excited about getting 64-bit addressing. Then I don't have to worry about disk speed so much because I'll just keep everything in RAM and use the disk for only one thing: persistent storage.

Re:Actually, 4gb is not enough

[Florian Weimer]

I was careful to talk about desktop machines. ;-) There are no applications which require 4 GB per process on the desktop right now. Even databases do not require that much address space all at once (although it might simplify coding---but who runs large databases on a desktop computer?). Number crunching is a different issue, but you usually have specialized machines for this application if you really need it.

Re:Actually, 4gb is not enough

[roca]

The latest Everquest recommends 512MB of RAM. I think we're at most 3 years away from desktop applications (games) feeling constrained by having only 2 GB of addressable memory.

Re:Actually, 4gb is not enough

[Anonymous Coward]

the 32 bit address pointer is not just all about being able to address physical memory.

on a unix system, one is able to mmap() files so that they can be accessed just like other memory. this is a programming technique that i like to use when dealing with humongous amounts of data, like video data etc. but - if you only have 32 bits acting as a data pointer, how on earth can you mmap() files bigger than 4 gigabytes? physical *ram* memory is irrelevant here, we already have hard disks that exceed the 32 bit limitations by a great deal. or am i the *only* one here with 8 gigabyte files lying on my hard drive?

There's more to this than the processor

[Anonymous Coward]

Yes the Power4 is a monster processor. But what makes the Power4 so much more of a monster is the way it handles I/O.

IBM has said at every step of the way that Power4 goes further than pure chip architecture. When they say Power4 they want you to think not just about the chip but the whole I/O scheme.

In fact the product managers/Power4 designers at IBM have insisted that what makes a P690 special isn't so much the chip but the capacity to move enormous amounts of data around the system in a highly configurable manner.

Of course only time will tell, but it seems that a P690 can do some pretty dancing with that huge optional external level 3 cache if it's configured the right way.

Pure clock speed was not the primary factor in Power4 design. Overall system I/O was. They have implemented so much new technology into this design that I'm convinced that it will give anything else out there a serious hiding when the new compilers reach maturity.

Wrong math, was Re:compilers

[HuguesT]

Hi,

Speed of light is 3.10^8 m/s

In a nanosecond (10^-9s), light travels 30cm,
not 1cm like you wrote.

Re: Wrong math, was Re:compilers

[Anonymous Coward]

Math is still wrong, electrons travel much slower that light since they are "physical" particles.

Speed differs depending on the material they are traveling through.

Sorry, I don't have a metric at this time.

Re: Wrong math, was Re:compilers

[Doctor Bill]

Still wrong.

The speed of the electron is not the issue. The speed of the signal propagation in the medium is the issue. That is still a significant fraction of C.

As the previous poster commented, in a vaccum, C is about 30cm per second. While the speed of signal propagation in copper is somewhat slower, 1.0cm/sec (as the earlier poster said) is probably too slow.

Total off topic now,

-b

Re: Wrong math, was Re:compilers

[Alan Partridge]

so let me get this straight, you're asserting that the SPEED OF LIGHT is 30cm per second?? has the whole world gone crazy here?

Re: Wrong math, was Re:compilers

[Doctor Bill]

Doh!

(open mount insert foot, chew, spit toes)

That would be approx 30cm/ns, *not* second.

What's 9 orders of magnitude between friends, eh?

-b

Re: Wrong math, was Re:compilers

[Anonymous Coward]

yes the actual electron particles move at 0.01 cm/sec in copper. Which is rougly 3 hours/meter. The "signal" is virtually instantaneous.

Re: Wrong math, was Re:compilers

[MitchAlsup]

Lets get this physics right:

First, it is the speed of the electromagnetic wave that counts, and (indeed) in free space it does travel at C.

Second, EM waves in silicon have to deal with the permitivity of the oxide (insulating) layers, slowing the speed of the wave to no better than 0.5 C (Pe[SiOx] = 3.9).

Third, The copper signal traces have resistance which slows the edge speed of a signal. Even though the first vestiments of the signal edge arrives with time delay close to 0.5 C * l, the last vestiments of the edge do not arive until ~R*C later.

Forth, at the edge speeds of processors just entering design (for customers in 2005+) the skin effect becomes significant (making the effective resistance of signal traces larger).

Fifth, there must be sufficient signal to overcome any residual noise in the proximity of both the sender of the signal, and the receiver of the signal. And much of the time, this signal must transition from one defined value (VIL) to another (VIH) within a given time (10% of a cycle).

So even if the speed of the EM wave is ~0.5C, the speed of a rail-to-rail sent signal and VIL to VIH received signal is R*C limited. With a typical 0.1um process, the maximum distance you can send a signal with an edge faster than 0.2 cycles is about 5 mm (10 GHz==100 ps cycle time design point) with optimal repeaters and wire spacing. With a typical 0.18um process and a 2 GHz cycle time, one can achiev on the order of 15 mm distance (also with optimal repeaters). Both of these signaling speeds are on the order of 1% to 3% of the speed of light. Its a shame, but it is also reality.

This distance can be increased with:
a) slower processor design points (yeah right)
b) low permitivity dielectrics
c) smaller cladding in the copper metalurgy
d) superconducting wires (yeah right)
e) non-wire-based signaling (e.g. radio waves)
f) optical interconnects on-die

My money's on the 64 bit AMD Hammer

[Anonymous Coward]

AMD will kick Intel's ass. Everyone knows the x86 line is a piece of crap, but it is the market standard. It only makes sense to extend this bad boy to 64 bits and use the highly optimizing x86 style compilers we have today. No brainer. Low cost, high throughput computing.

I'm going to emulate 64bit on a 32bit apple....

[Anonymous Coward]

worked before and will work again

Fine and good, but Itanium is hard to JIT for

[Anonymous Coward]

The Itanium is not a good chip to do on the fly machine code generation due to its cache structure. The JITters would also waste way too much CPU up front to be useful. The Itanium bascially REQUIRES a static compiler for any decent level of performance. In other words, Java and Itanium are not the best of friends.

Re:Fine and good, but Itanium is hard to JIT for

[Mr Z]

I don't buy it. You should be able to do a pretty decent job, even on the fly. Otherwise Transmeta wouldn't have even half a chance. As it is, they're doing pretty good -- maybe not bleeding edge performance, but very acceptible for running essentially "JIT x86". Transmeta and Itanium both are VLIW machines, and so it's reasonable to expect the hurdles involved aren't gigantically different.

Granted, to get ultimate performance out of Itanium, you need to jump through some fiery hoops. (I program a VLIW machine at my day job, so I'm familiar with VLIW's quirks.) But to get "pretty good" performance, it's not too bad. And that's what JIT needs. There's lots of low-hanging fruit.

Another thing you fail to take into account is that dynamic compilers have many opportunities to improve on the generated code that static compilers lack. (That was the primary insight of the Dynamo project I linked before.) For Itanium, this is especially true -- a dynamic compiler could get feedback information on which loads miss the cache, which branches are mispredicted, etc. and twiddle the code appropriately. A static compiler would just have to guess, or accept profile information from previous runs.

--Joe

what's next?

[Cinematique]

hopefully intel will reduce the size of this thing so the big three can get it into laptops that aren't the size (and weight) of a sack of this.

i don't believe the laptop market is filled to the brim with people who wear back-supports.

Oh no he isn't

[Mike Greaves]

All of those little guys make much smaller planes and/or a smaller range of models than Boeing and Airbus. Boeing and Airbus are the *only*, I repeat *ONLY*, two effective competitors left in the world-wide market for large airliners.

Lockheed abandoned the market; McDonnell Douglas was bought by Boeing, and so on...

Ultimately, only IBM and Intel can stand on their own when it comes to state of the art fabs. It was the cost of continually upgrading the fab that caused Compaq to abandon Alpha. Sun will be very fortunate if it continues to succeed in it's traditional fab arangement with TI. I think that Sun, TI, AMD (and maybe others) should try to pool their resources some way here; maybe with jointly owned/operated fabs or something...

Remeber what about the Pentium Pros?

[spacefrog]

Only time will tell. Remember the Pentium Pros..

Remember, what, exactly about the Pentium Pros? That the Pentium Pro was the first product based upon the P6 core? That this same P6 core powers the entire Pentium II, Pentium III, Xeon, and Celeron product lines? This generation has easily been Intel's most successful to date.

Remember what? Remember that the PPro was a stop-gap that was directly replaced by the P2 and Xeon (depending on the market segment).

Given that the Pentium Pro technology begat product lines that made Intel Billions of dollars, trying to imply it was less than a success is very short-sighted and foolish!

If this weren't Slashdot, I would guess you an MBA

Re:Remeber what about the Pentium Pros?

[Talonius]

Fact is that the Pentium Pro itself was a marketing failure. While you go on to state that the future lines of Intel chipsets were based on the Pentium Pro that is and isn't true. The PPro when considered alone, was a dismal retail failure.

Consider me an MBA if you'd like. I'm fairly close to that.

Re:Remeber what about the Pentium Pros?

[khuber]

>The PPro when considered alone, was a dismal retail failure

Does anyone have real numbers? My guess is since
the PPro was so high priced, it made money in the
server/workstation market, but not the desktop market.

-Kevin

Re:Remeber what about the Pentium Pros?

[Anonymous Coward]

Complete Bullshit. The 4x Pentium Pro singlehandedly got Intel into the server room as a serious player.

I know you read in some dipshit PC magazine that the PPro didn't run 'WinBench' very fast, but the fact is it was a very solid chip and sold great in the higher-end markets. If I had a PPro/200 right here, I'd have no problem doing my normal computing tasks (except games), but fuck if I would even bother turning on a Penitum MMX.

Re:Remeber what about the Pentium Pros?

[Talonius]

Obvious you can read.

I didn't say the PPro was a technical failure. I said it was a MARKETING failure.

Before you spout off at the mouth with random insults - READ.

I have a Pentium Pro 200 x 2 running in my office right now and I do like it. IT WAS NOT SUCCESSFULLY RECEIVED AT THE RETAIL LEVEL.

End of story.

Re:Remeber what about the Pentium Pros?

[Anonymous Coward]

Much like current Xeon chips, it wasn't priced or marketed for retail consumers, so who cares.

Some more SPARC news...

[Anonymous Coward]

I heard SPARC chips are so fucking scared of the multi-GHz x86 clones that they are running their instructions out of order! Some of the Sparc instructions think they can even hide in a delay slot (under a jump) so the x86 clones won't find them and kick their sorry out-of-date asses!

Dead Processors

[Anonymous Coward]

In the desktop/server market, only 3 architectures
of processors will survive within the next 10
years. These architectures are the Intel x86
(and clones like the AMD K8), the Intel Itanium
(and successors), and the IBM PowerPC.

In the embedded market, scores of architectures
will survive. They include the ARM, MIPS, Intel
8051 (!), etc. The embedded market is where failed
workstation processors languish.

Determining the survivors in the desktop/server
market is easy. Just look at the 2 key benchmarks:
SPEC2000 and TPC-C. The Intel processors and the
IBM PowerPC have the best performance. All other
processors rank a distant 3rd, 4th, etc.

Sun's decision to sell Intel- (or AMD-) powered
servers running Linux is basically an announcement
that the SPARC processor will disappear within 10
years.

I also have an NDA

[Anonymous Coward]

A "Non Disclosure from talking from my Ass agreement".

Sparc is toast compared to the superior dual Athlon MP technology in the low end. In the high end IBM/PowerPC has got SPARC beat. IBM has the fastest high end Java2 platform. In a recent Spec test IBM/PowerPC needed just 32 CPUs to beat a 72 CPU score for Sun/Sparc. This is not news to anyone that Sun's hardware IS OVERPRICED relative to ITS POOR PERFORMANCE.

Surviving Processors

[Anonymous Coward]

In the desktop/server market, only 3 architectures
of processors will survive within the next 10
years. These architectures are the Intel x86
(and clones like the AMD K8), the Intel Itanium
(and successors), and the IBM PowerPC.

In the embedded market, scores of architectures
will survive. They include the ARM, MIPS, Intel
8051 (!), etc. The embedded market is where failed
workstation processors languish.

Determining the survivors in the desktop/server
market is easy. Just look at the 2 key benchmarks:
SPEC2000 and TPC-C. The Intel processors and the
IBM PowerPC have the best performance. All other
processors rank a distant 3rd, 4th, etc.

Sun's decision to sell Intel- (or AMD-) powered
servers running Linux is basically an announcement
that the SPARC processor will disappear within 10
years.

Re:The Ace of Spades

[Drunk4Free]

Its Lemmy dumbass. But he rocks anyway.

Will not become commodity

[Deflatamouse!]

Intel does not intend IA64 processors to become commodity CPUs like its IA32 processors. You will not be able to build an Itanium system for $2k, at least not for many years, just like you cannot go to Fry's and buy parts for a Alpha system or a PARISC system. The person who submitted the story is misinformed.

Re:Will not become commodity

[Anonymous Coward]

Intel does not intend IA64 processors to become commodity CPUs like its IA32 processors. You will not be able to build an Itanium system for $2k, at least not for many years, just like you cannot go to Fry's and buy parts for a Alpha system or a PARISC system. The person who submitted the story is misinformed.

You have to be stupid. He wasn't comparing Itanium to PIII and Athlon chips, he was comparing them to workstation/server chips like the Sparc series, Power4, and AMD's upcoming Hammer line, which are geared more towards the high-end, and none of which I expect to see available at Fry's anytime soon.

Re:Will not become commodity

[Deflatamouse!]

What a troll. If the poster of this story was not comparing Itanium to PIII and Athlon chips, why would he mention the word "commodity" and also mention about building it for 2k?

Corporations will never intend to have workstations and servers to be in that price range unless they are planning to go out of business.

Next time, read more carefully, and look up meanings of words you don't know before you post again... why am I answering to a AC anyway?

> You have to be stupid

Now this one is totally unnecessary, what's your problem? Abused by your parents when you were a little kid?

Peripheral communication.

[Christopher Thomas]

A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?

Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu. :P

The good news is that USB is well on its way to completely replacing serial and parallel ports, and that PCI has been the One True Bus for the past couple of years now. Everything south of the southbridge is slowly fading away.

IMO, if we'd switched to 66 MHz 64-bit PCI years ago, we'd have no further problems on this front. In practice, PCI-X may finally be pushed through by Intel, and that will serve most internal communications needs. Motherboard chipsets are modular enough that it doesn't really matter what flavour of IDE/SCSI/firewire your drive is hanging off of; the drive controller is just another PCI device to the processor. You have enough bandwidth and DMA functionality on PCI bus to handle it.

The only peripherals that are currently bottlenecks are RAM and the video card. RAM is handled by upgrading the memory bus every couple of years. This is easy to do, because peripherals don't care what happens on the other side of the northbridge. The video card was handled adequately by the hack that is AGP (64-bit 66 MHz PCI would have been a much better idea, but that wouldn't have given Intel its nice AGP port to license).

The only peripheral that *might* be a problem in the future will be the network card (when gigabit cards finally come into vogue), and that will probably be what forces motherboard makers to put wider/faster PCI on to midrange boards and not just high-end boards.

In summary, this is less of a problem than it first appears to be.

The only serious bottleneck for performance is RAM latency, and that's not because of legacy peripherals.

Re:Peripheral communication.

[Anonymous Coward]

> 64-bit 66 MHz PCI would have been a much better idea

4X AGP is a 32-bit 266 MHz bus. That's more throughput than possible with PCI. AGP doesn't have contention with other devices on the bus so it doesn't have to do any logic for mastering or controlling and can allocate all its clocks to doing a data transfer. Why would you want PCI? The only advantage PCI gives is that you can hang multiple devices off of it. But while that lets you get multiple monitor support easier, it will really kill your limited bandwidth.

Re:Peripheral communication.

[Christopher Thomas]

4X AGP is a 32-bit 266 MHz bus. That's more throughput than possible with PCI.

Unless you buy into Intel's PCI-X, which is 64/133.

And most graphics cards are not limited by bus bandwidth with *any* flavour of AGP (see the various Tom's Hardware benchmarks). The usual limit is fill rate for new cards, and lack of geometry processing for old cards (assuming you're playing a new game). Textures are stored on-card by any sane game, so the only thing going across the bus is lists of triangles.

AGP doesn't have contention with other devices on the bus so it doesn't have to do any logic for mastering or controlling and can allocate all its clocks to doing a data transfer.

While this would be an issue for very short data transfers, graphics cards will likely be transferring large batches of data. This is done in burst mode, which gives one transfer per clock.

Why would you want PCI? The only advantage PCI gives is that you can hang multiple devices off of it. But while that lets you get multiple monitor support easier, it will really kill your limited bandwidth.

You have bandwidth to spare; all you'd be doing in a multi-monitor setup is sending the same triangle lists over the bus, not cutting and pasting image data or doing texturing. Have one one dominant card and leave the others snooping traffic, and you have zero extra overhead for this.

The real benefit of having multiple video cards is that it lets you easily do render farming for things like games. Have each card render half the screen, and copy all cards' partial renderings to one card's frame buffer. 32/33 PCI is too slow to be practical for this, but 64/66 has more than enough bandwidth. I studied the feasibility of this at one of my past jobs.

Re:Dead? I doubt it.

[Schmendrick]

SPARC as the IV is experimental, and the V is the next production level as I understand it

You should say UltraSparc IV and V (Sun Microsystem), because the SPARC standard is at version 9 (Texas Instruments).

Of course it's Jtanium! (Also, Ptanium, Netanium)

[leonbrooks]

Then instead of VLIW it could run Java bytecode, and Java pages would load under Netscape in less than an hour.

Alternatively, as Intel seem to like skipping letters, you could have a Pytanium that ran Python bytecode - or just ran the ASCII Python source.

Naturally, Microsoft would like a Netanium that ran CLR. The licencing costs would quadruple the cost of the CPU, which from Microsoft's POV is ideal since they can give Windows away, live off the CLR licencing costs built into the CPU, and claim to no longer be driving up the price of commodity systems with an expensive OS.

Re:No they won't...

[Anonymous Coward]

Actually that doesn't describe me at all, but thanks for playing...

Different Directions for Processors

[chriscmp]

As CPUs have gotten faster over the years, it seems that the amount of die space that engineers are using to get each % increase in speed grows. Bigger caches and more sophisticated branch prediction are just some of the techniques they're using to suck up die space. But I'm not certain this is the best technique.

Perhaps a better approach is to move up the "stack" of computing, and start incorporating aspects of the operating system into the HW of the CPU. Two critical components that I could see are 1) Context switching. 2) Memory management. These are both hard problems, but some very significant advantages fall out.

1) The removal of significant parts of overhead of the OS.

2) Pervasive multi-threading ( al la BeOS ), become even more advantageous. Which has the following effects:
a) A far superior UI experience with very low latencies for UI events.
b) a multi-cpu package more practicle from a price/performance standpoint, which lowers the costs of parallelization computing tasks ( modeling, 3D calcs, etc )

Thoughts?

Re:Different Directions for Processors

[Anonymous Coward]

People are already putting full TCP/IP routing decision systems in hardware. It is a must when you have to process packets comming in on multiple 10GHz links. On the other hand this is a narrow area that all methods used are basically the same. With task switching and memory management there are multiple ways to do this above the CPU's own method's. Which method from which OS do you freeze into silicon? Personally I see the closser integration of the processor and other parts of the system. I expect to see memory, processor, and IO systems all built onto one chip. A fully integrated system built into a module. Modules will be fully non-volitile. Need more processing power, add a second module or buy a faster one. Another path I see is the fully reconfigurable computer. It's internal logic is remapable just like a FPGA is. As such the program compilation not only includes code, but processor layout also. Tailor the system logic to the task at hand.

As in, you're lucky if it does stuff?

[leonbrooks]

They could name their chip Assium!

The ultimate in speculative execution? If it turns out right every time, it's ``pure ass''? Sounds very quantum to me...

Yes, he is.

[Dastardly]

That is a very PC centric view point. TSMC and UMC in Taiwan have state of the art fabrication facilities. IBM's probably does more volume as a foundry for other companies than its internal customers (Power4). SPARC accounts for a small fraction of TI's capacity, their Fabs development and capacity are driven by DSPs. Motorola's Fab investments are driven by embedded products. There is also Samsung in Korea and some Japanese semiconductor manufacturers.

Compaq didn't abandon Alpha because of Fab issues. They got Alpha from DEC after Intel had already bought DECs Fabs. I believe Samsung built Compaq's Alphas, possibly in addition to a foundry deal with Intel related to the former DEC Fabs.

There is going to be some consolidation depending on whether some companies can really justify Fab investment based on the return on that Fab. Decreases in die size will help drive this. Considering that AMD is projecting a capacity 50 million/year Athlon/Duron parts from Dresden at 0.13 micron. This is ~50% greater than their total best PC processor shipments from Austin and Dresden combined. Companies will want to reduce die size to reduce cost and increase speed, but will not be able to fill that capacity alone. The billions to invest in a Fab is pretty cheap if you can fully utilize it. I think this is partially why AMD is building their next Fab as a joint venture with UMC, it gives AMD the added capacity and technology of a new Fab, the first dibs at capacity that ownership brings, and the capability of filling the Fab with UMC foundry parts.

porque?

[Anonymous Coward]

If you'd been around before the IBM PC, you would have seen the reign of the 36 bit processors. Go read your history.

You missed one important architecture -- ARM

[Anonymous Coward]

ARM's great strength, apart from low power requirements, is that it is very customisable: the CPU design can easily be extended with or embedded into circuitry specialised for particular application areas.

Doesn't Matter

[The Cat]

By the time anyone figures out how to really use it, it'll be obsolete anyway.

Then, any work done on it will become "dated" in the eyes of the technology "media" while they wait for the latest upgrade of colorful icons in a really expensive shrink-wrapped box.

Companies cannot invest large amounts of money doing cool things with technology when they are certain to see their investment evaporate when the rug gets pulled: and the rug *always* gets pulled.

What's Next?

[The Cat]

Why.. a 128-bit processor! Then we can access all the memory that will be manufactured for the next 50 years with just one pointer! Think of how cool that would be! Yeah!

sigh...

Fat binaries

[leonbrooks]

When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

There's a bit more to it than that. Apple also strongly encouraged developers to ship ``fat binaries'', that is, the executable component of programs came in two ``forks'', one for the 68K and one for the PPC, made together from one set of sources. This meant that you could write stuff for the PPC that would still run on the 68K, or from another POV, simply recompile your 68K stuff and be able to also run it on a PPC.

Linux (or at least the bulk of the gcc-related stuff) is set up to enable this kind of thing fairly simply. The same piece of loader that decides what to do with Java executables and the like would be able to select code for different CPUs from one binary. Careless application implementation would involve a significant memory and performance hit, but it would still work. Windows, on the other hand...

It would be kind of neat to have a truly asymmetric multi-processor system and be able to run x86/Alpha/MIPS/Sparc/PPC binaries on the one Linux box without blinking. I wouldn't want to be the one sorting out the data structures common to all of the kernels, though.

BTW, does anyone remember the Dec Rainbow (PC-100)? Imagine how much better that would have fared if .COM (Z80/8080 on CP/M-80) and .CMD (808[68] on CP/M-86 or MS-DOS) files were able to be run seamlessly on the appropriate CPU.

The Next Big move in Processors

[gururise]

Right now, the way to speed up a processor is to pack more transistors on the chip (which is made possible by the ever decreasing die sizes), and to increase clock speeds, which are also helped by better transistors and a smaller die size. The additional transistors are used for additional caches, better branch prediction logic, super scalar architecture (multiple pipelines), and a host of other techniques that help improve the instruction level parallism (ILP).

Eventually, the laws of physics will catch up to us, and Moore's law will not be upheld. How long this will take is anyone's guess; however, many respected scientists believe that uniprocessor systems will continue to see advances into 2006.

At some point in the future, we will not be able to make the die sizes any smaller (right now we are at 0.13 micron) due to the quantum effects that such small circuits display, engineers will be forced to seek alternative methods of performance enhancement. In addition, I suspect, there will also come a time when we can not get a transistor to switch any faster (you can't switch in 0 time). Then what?

So far, the only alternative is Parallel Distributed computing. Having a cheap/efficient parallel computer based on a commodity processor is where the future will be. Operating System support and Compiler support is another story, but Mosix for linux is a good start! =)

Guru
ERA Champion R/E, Inc.

AMD who?

[qurob]

Well...they never captured enough market/support.

MMX or 3D Now?

MMX

Intel will win by brute force.

Itanium or Sledgehammer?

Itanium.

x86 is bad enough....64 bit x86 will really be a kludge

Re:AMD who?

[Isle]

Actually not. I thought so too, but out of interest I skimmed the ISA of x86-64 and half wayt through something struck me: You can use program entirely using the extentions!

They also talk about SSE the same way as an alternative to x87. Infact gcc-3.1 has an option to always use SSE instead of x87.

In other words, when writting a compiler for x86-64 you can mostly ignore all the legacy stuff, and just generate some smacking fast 64bit code. OTH x86-64 is ofcause not as beatyfull as alpha or mips, but is a far way from the old x86 fuck-up.

Re:*cough* PowerPC *cough*

[ToLu the Happy Furby]

Also featuring stinking fast floating point.

Completely wrong. The G4 has some of the slowest IEEE floating point this side of a StrongARM.

Presumably you're confusing AltiVec with "floating point". AltiVec is a vector unit, not a floating point unit.

True, many AltiVec operations operate on vectors of floating point values (don't think they're IEEE, though), but that is most certainly not the same thing as normal floating point performance. Only a small subset of all floating point calculations can be effectively vectorized, and doing so requires extensive reprogramming (not just recompilation).

In any case most real-world floating-point applications have heavy bandwidth requirements and large datasets, which brings us to another glaring weakness of current Macs, namely their paltry PC-133 memory bus. Sticking two 1 GHz G4s on the same shared 64-bit PC-133 bus is almost comedy. (Tragicomedy if you want to run serious HPC workloads.) Sure the L3 helps if your dataset is 2MB and well-behaved, but if you think PC-133 is still ok for a modern desktop PC, perhaps you ought to think about *why* Apple and Moto had to start adding L3 cache and a backside bus to each processor when every other desktop CPU gets by with much cheaper on-chip L2 and a modern memory bus.

(Yes, I fully expect that DDR G4s will be available real soon now, but until then the situation on the high-end of Apple's desktop is just embarrassing. As for floating point performance, ditch the 64-bit PC-133 shared bus for a 128-bit PC2100 memory system and P2P interconnect and then that dual-GHz G4 might start looking credible...if only the G4 had decent fp number-crunching power.)

Bwa Ha ha ha ha ha ...

[BadlandZ]

Sparc is dead, Sun doesn't have the money (more than US $1B we'll guess) to do another round

Someone remind me to post a link back to this story in a month or two when Sun announces their faster processors with solved ecache solutions...

Who's paying for this researcher?

[spinlocked]

Fud, fud, fud. I can't speak for the other companies but Sun can easily afford to fund R&D on the next generation SPARC chip, they've got 6 billion $ cash in hand. Let alone investments, and have done for over 2 years. BTW the current generation is UltraSPARCIII, UltraSPARCIV is just a fabrication improvement. Work is already underway on UltraSPARCV's design. Sun's crown jewels are SPARC/Solaris, when Sun stops working on their own OS/CPU/Server platform it's time to stop investing in them.

Re:Who's paying for this researcher?

[Anne_Nonymous]

1. You're linking to data that's six months old.
2. Even if you look at that data, you're high by over $4 billion.
3. As of 12/31/01 they had $1.205 billion in cash and near cash, and $0.648 billion in Marketable securities for a total of $1.853 billion in cash-esque assets.

http://www.sec.gov/Archives/edgar/data/709519/00 00 89161802000605/f79125e10-q.htm#003

Slow and expensive v. fast and cheap

[Anonymous Coward]

What a typical buyer thinks...

Hmmm.... should I buy this slow and expensive Itanium or this fast and cheap AMD?

The rumor I hear is that Intel is urgently developing a 64 bit chip with an X86 compatible instruction set.

Re:Slow and expensive v. fast and cheap

[Anonymous Coward]

The rumor I hear is that Intel is urgently developing a 64 bit chip with an X86 compatible instruction set.

Yes, I heard that as well...

NDA Schmen DA

[Anonymous Coward]

K, Sparc inside scoop. By June expect to learn:

• There will be no ecache problems ever again with the next Sparc releases.
• Inside Sun there are 5GHz Sparc's running, THEY WILL BREAK the GHz barrior this year with CPU's well over 1GHz shipping.
• SUN has been "playing dead" on the hardware inovation because they got burned with the ecache thing, and refused to let anything new out until they were 100% sure it would not have any such problems. Meantime, INSIDE SUN, they have been developing like mad....

Re:NDA Schmen DA

[AtariDatacenter]

I'll go ahead and take this.

No ecache problems ever again... because they're going to fully mirrored. That was really a black eye for Sun that they don't want to repeat. BTW, they're saying one of the bad batches of L2 cache came from IBM.

Over 5Ghz running inside Sun? I suppose it is possible, but not an everyday event. They will absolutely break the 1Ghz barrier this year if they haven't already. 1050 should be the clock speed (150mhz bus x 7 multiplier).

Sun playing dead? Yes. We should have seen the 1Ghz processors a long time ago. Soon after the ecache problem surfaced, new technology enhancements almost completely stopped. Only now are we seeing stuff again (and at a cautious pace) now that the UltraSPARC III is shipping.

None of this is really inside stuff if you've got a finger on Sun's pulse. (Like a major customer.) Here are a few more things that are easily deduced:

The UltraSPARC IV should be compatible with the UltraSPARC III. Same line of servers and all. Even numbered CPUs at Sun are improvements over the odd numbers. Not a core redesign.

The UltraSPARC V will more than likely require new hardware, just like the UltraSPARC III did.

Re: Wrong again

[pdp11e]

The speed of the signal propagation trough the medium is not equal to the speed of electrons. The actual speed (group velocity) depends on properties of the "transmission line". For the good old coax cable it is about 0.66% of the speed of light. It is obvious that electrons in the coax cable do not even remotely approach that velocity but, the fact remains that signal travels ~20 cm during period of 1 ns. The actual fraction of c for the lines on silicon chip is very similar to the previous example.
When you discuss physics it helps if you know basic facts.

Re:Dead? I doubt it.

[BlackStar]

Very true. I type corrected, and thanks for the clarification!

What goes around...

[mengel]

Once again, the Grand Cycle of Reincarnation has come around, and folks suddenly think this is a New, Hard Problem.

In actuality, old systems like the CDC6600s used to have very similar constraints, where reordering instructions could give you signifigant performance improvements. Quoting from here

The 6600 CP had an 8-word instruction stack which functioned rather like an instruction cache, but without the flexibility of a modern cache. Program optimization consisted of allocating heavily used variables to registers, loading operands from memory a few instructions before they were needed, writing operands to memory a few instructions before their registers were needed to hold new operands, keeping several functional units busy simultaneously, and trying to get inner loops to fit into the instruction stack. The divide instruction was notorious, because it took about thirty clock cycles and its functional unit was not pipelined. The peak CP instruction rate was one instruction every 100 nanosecond clock cycle.

Rather than build that smarts into their compilers, they put most of it into the assembler, and all the compilers got it for free.

Of course, you can theoretically do better by doing it in the compiler than you can in the assembler, but you can easily get the first 80%.

The future may be simplicity, scalability and X86.

[Anonymous Coward]

What's Next after Itanium? Maybe more X86. It seems to me that X86's plain old von Neumann architecture is easier to

1. write software for and
2. scale up to the exponentially bigger chips that Gordon Moore's law predicts.

Think scalability.

Not to rain on your parade...

[Chris Burke]

This is exactly why 'virtual machines' (VM) or 'Just In Time' (JIT) compilers will eventually replace the current series of compile to asm compilers.

Actually... Java/.NET and JIT compilers are exactly why "Merced" or "Itanic" isn't well suited for the very things it was supposed to be good at. You see, for a VLIW machine like those, the degree of compiler optimization required to achieve good performance is much greater than for a traditional RISC-ish machine (in which I'm including x86, for reasons I'm not going into). Essentially, to get maximum performance requires a great deal of compilation, profiling, and compiling again. This is all front-end overhead on your process. The whole idea behind JIT is that it's supposed to be fast, and occure when you download new code... But now the opposite is true. At this point, you're just as well off using a traditional-style compiler/profiler that produce traditional binaries.

Sorry. No VM utopia here.

Re:Not to rain on your parade...

[Anonymous Coward]

Actually... Java/.NET and JIT compilers are exactly why "Merced" or "Itanic" isn't well suited for the very things it was supposed to be good at. You see, for a VLIW machine like those, the degree of compiler optimization required to achieve good performance is much greater than for a traditional RISC-ish machine (in which I'm including x86, for reasons I'm not going into). Essentially, to get maximum performance requires a great deal of compilation, profiling, and compiling again.

Well this is exactly what Crusoe does.

Re:Not to rain on your parade...

[borgboy]

But a JIT (or a VM) is in a MUCH better position to analyze the current operating environment, level of SMP, processor stepping, available physical ram etc and leverage that information for a better executable. And instead of redistributing a recompiled app when compiler technology improves, the customer is responsible for obtaining the best JIT or VM available that suits her needs.

Re:Not to rain on your parade...

[Chris Burke]

Which are all good features... for some architecture that isn't IA-64. Plus, optimizations based on number of processors or amount of RAM are not going to be something the -compiler- does, but something the -programmer- does.

Re:Not to rain on your parade...

[Chris Burke]

Well this is exactly what Crusoe does.

We're talking about IA-64 here, which isn't exactly what Crusoe does. IA-32 -- and Crusoe's underlying instruction set -- are much less dependent on compiler optimizations for performance.

a dead horse

[f00zbll]

Isn't this topic a dead horse already. Anyone familiar with server quality parts know there is a huge difference in tolerance specs. You can try to build a server with "off-the-shelf" motherboard, power source and ram, but there are reasons why it exists. If you're running a mission critical database, do you want bad memory to bring the whole thing down and corrupt your data? Or would you rather put out the dough for ECC Reg memory, which has been tested more thoroughly. Your typical desktop RAM isn't put through the same level of QA, so don't kid yourself.

Likewise, a Solaris motherboard goes through the similar tight QA procedures to make sure the motherboard is up to spec. There are PC motherboards with similar tolarances and specs, but they cost about the same as a solaris motherboard. People really should learn about the manufacturing process for motherboards and other components (beyond what's on CNN or Cnet) to get a good understanding of the difference between workstation and server hardware. You'd never use a motherboard designed for Sun e6000 on a workstation because it's way over kill. I've yet to see solid PC hardware that could support live swap of CPU, memory, hard drive, and ethernet cards. Nor have I seen or know of PC hardware that can support 32 or 64 processors. You're kidding yourself if you think Itanium will take over the high end market in the next year or three. It takes a tremendous amount of time and energy to reach that level of scalability. No matter what Intel or Microsoft says, PC architecture isn't ready take down solaris or AIX this year or next year. It will eventually get there, but Sun and IBM aren't going to sit by and loose market share. How many /. readers have had the need to load a 10gig database into memory. I haven't personally, but I sure wouldn't try it with a PC. Now of course if you had to make 10gigs of data available for search, you could distribute it by segmenting the data and using routing algorithms to get comparable performance with a hundred PC's. Building such a network poses it's own problems, so there is no magic in Itanium.

cheap SPARC hardware

[Anonymous Coward]

Yeah, blatant plug for my small startup. Tell 'em Dave sent ya. price might drop a little.

Cheap SPARC hardware: Anysystem.com

A little to early for post Itanium phantasies

[uweber]

Itanium at the moment looks rather bad and the full potential, in terms of raw power, might very well never be achieved outside of handcoded assembly. After all EPIC (Intels buzword for VLIW - very long instruction word) needs compilers that can build "meta instructions" where 4 Instructions, which can be executet together in parallel, are packaged in one instruction word. Current compilers however still suck in that respect which leads to the comical situation that usually only one real instruction is packaged with three "no-op" and thus most of Itaniums execution units are not used - unless you think filling up diespace is usefull enough. This problem worsened by the fact that EPIC isn't designed to do out of order execution or discover parallelisms at runtime, which AFAIK chips like the Power4 do rather well. Above all I read somewhere that besides parallelisation the Itanium ISA was suposed to reduce the need for large caches by providing some method for prefetching only things really needed - though somehow this didn't work out, otherwise Intel wouldn't have added such large caches to McKinley. So to summarize I think the real question will be wether Itanium is really the next big thing and if not (which I belive) what is.

Re:A little to early for post Itanium phantasies

[Anonymous Coward]

Your comments about EPIC are quite true. I remember hearing people at DEC who worked on the Alpha thought the EPIC idea was funny because they had thrown it out years before when they were working on the design of the Alpha chips. Instead they went with multiple pipelines, but having chips that could do out of order execution. This first came available on the 21264 and it give them almost a factor or 4 improvement over the 21164 at the same MHz.

As for the prefetching, that is a prefetch TO cache. You still need a big cache for it to really pay off. Having a bigger cache on the McKinnley doesn't imply the prefetch doesn't work. Of course, your point about compilers is probably just as valid here. The prefetch instruction only helps when the compiler "knows" how to use it. They don't do it well right now so it isn't of great significance. I should note that the Alpha instruction set had prefetch in it as well, it was just never implemented in the chips that had been made.

I morn for the Alpha and what could have been.

Re:The Ace of Spades

[Anonymous Coward]

Fuck you all! Carl ROCKS all you lamerz!

SPARC performance

[Anonymous Coward]

First, go to the SPEC web page at
http://www.spec.org
Then, go to the TPC web pate at http://www.tpc.org

The performance of SPARC processors lags far behind
the performance of x86 and PowerPC processors.
The latter 2 processors (and their successors)
are the winners in the performance battle.

Sun's decision to sell Intel/AMD-based servers
running Linux is basically an announcement that
the SPARC processor will be retired within 10
years. Whenever a pro-SPARC person issues FUD,
he never supports his claims with objective 3rd-party
data.

Re:The Ace of Spades

[Anonymous Coward]

Hey! Play "Freebird!!!"
Wahooooo!

Re:Of course it's Jtanium! (Also, Ptanium, Netaniu

[alext]

Well, the ARM got ignored up to now, so here's a link to Jazelle, the (90% of) Java bytecode native to CPU trick. And the benchmarks are quite impressive too...

Re:Itanium already was hammered.

[evilpaul13]

Dell has dropped their Itanium workstation line because none are selling. Think PIII+i820+Rambus bad.

It doesn't matter how great your CPU is, or how great it will be in the future if there are no applications for it NOW. Will today's Merced Itanium be great when IA64 gains mainstream acceptance? No, it will be as widely accepted as the 80386 is today.

This is the same as people who ran out for a GeForce 3's Vertex and Pixel Shaders. By the time there are enough cards in people's computers that use them the GF3 will be horribly slow compared to the newer cards with them.

Emulation, code translation...

[Nyarly]

I've seen a couple of threads devolve into "this proc emulates that one...", so I wanted to drop a question in this forum.

I've long wondered what the insurmountable hurdles were to convert the machine language of one processor were to any other. Should it not be possible to abstract the results of instructions and convert between instruction sets?

I can see there being a huge time complexity argument, since the algorithm I have in mind runs something like: translate instructions from source to a base language (say, a modified version of MMIX, or whatnot), idealy designed as a RISC, where there are no convenience instructions - every instruction is atomic (by which I mean not the usual "is completed all at once" but "can't be split into other instructions) - and then regather translation language instructions into destination language instructions. That "gathering" process is, I'm sure, analogous to some solved problem, and might even be NP-complete.

I can see a few difficulties, such as differences in registers (both in number and roles), byte-widths, word lengths, bus function and memory size, but I see those primarily as features (non multiple byte width conversion, allowed?) or run-time checks (oops, that program needs more memory than the target machine can address). But the biggest issue would be the time complexity of the problem.

But if the only workable algorithms are NP, so what? I mean, the concept here is that I write a set of rules for converting to and from any proc, and you can write your code for anything (even the JVM...) and have it be converted into nice code for everything. It might take a while, but at one run per app, there aren't as many actual instances of the problem, if it is large and complex, you know?

Better still, I wouldn't need the source for the original code. So I could conceivably run Windoze through this code, and get an app that'll run on whatever proc I want.

So, the question is: why isn't this feasible, or if it is, why hasn't it been done?

Re:Emulation, code translation...

[Anonymous Coward]

This is a fair question as the majority of moderen ISAs contain the usual set of basic arithmetic, logic and branch style instructions. It is also fairly straight-forward to convert register-to-register type operations to and from memory-modifying type instructions and this is indeed what is done internally in all modern x86 implementations. In a sense, this is a form of emulation: large convenience-type operations are broken up into a stream of "atomic" microoperations and executed internally. This process is accomplished by microcode running somewhere deep inside the processor and is invisible to above layers. The problem with converting ISAs in some general abstract sense is that while nice optimizations exist (simple one: caching the result of translated instructions), it is difficult to correctly emulate the rest of the architecture. User and kernel software expect certain things of the architecture with regards to interrupts, memory management and bus architecture. Then there other nuances such as instruction latencies and pipleline issues that compilers assume about processors, eg. P4s do not have a barrel shifter so divide by powers of two are not optimized to the appropriate shift instructions. Even small issues like that can cause code to execute terribly on machines employing some general emulation mechanism. So I guess the thing to take away from this is that there are significantly more complications that instruction translation and decoding.

Re:Emulation, code translation...

[Anonymous Coward]

> why hasn't it been done?

Because it is extremely difficult to do.

At best you can achieve only 1/2 the speed in emulation. Often you end up emulating everything even though they are just side effects of instructions that are never used - take the carry flag for instance. Carry flag *might* be used later - or it might not. Who is to say - you cannot, so you must faithfully emulate the carry flag behaviour.

An emulator cannot know the programmer's intent - no more than the host CPU would know the intent of the machine code it is running. If you solve the unknown intent problem, you win the prize.

Re:Emulation, code translation...

[Anonymous Coward]

there are lots of refrences to things like NP complete and Turning Machine ect on slashdot, and I for one have no clue what any of this stuff means =p

I'm going to be the first to admit I know next to nothing about CS, but I am quite interested in it.

Are there any books that a semi-intelligent HS student should read to get up to speed with basic algorithms? As my income is rather limited I want to get some decent opinions before I go spend money =p

Re:Emulation, code translation...

[IronTek]

Any computer can be made to behave (emulate, if you will) just like any other computer...

It's always doable, but the overhead involved in such a thing can be quite large, and the time to get such a thing working even larger.

Re:Emulation, code translation...

[dakoda]

until you run some self-modifying code. gonna recompile the whole thing everytime some memory is written that _might_ be executable? afaik, this hasnt been solved cleanly, but it has some possibilities that are less expensive than the above. (recompile the local memory area, insert nop's if the result is smaller on the local machine. but what if it's bigger? scoot the end farther, and realign all the pointers? what about modified pointers that are now somewhere+1, and you cant find with a simple scan?).

it'd be quite hard, i imagine (on the other hand, self-modifying code is probably rare these days)

Re:Emulation, code translation...

[Anonymous Coward]

Code Translation (better known as binary translation) is in fact a hot research topic in many of the big corp's software labs. This is especially true for companies like Intel or HP that had a lot to gain from doing this (migrating customers from a competitor's platform to their platform).

Here's a link to a very mature university research project called UQBT that has some shown some amazing results. And the best part is that its going open-source really soon!

Re:Emulation, code translation...

[Anonymous Coward]

I would recommend just doing a net search and finding the notes that different college profs have posted on the web. Here are some quick defs for you though. NP is non-deterministic polynomial. It describes a set of problems where given a solution you can check that is is a valid solution in polynomial time. However, there is no known algorithm to find that solution in polynomial time. NP-Complete (or NPC) is an NP problem that any other NP problem can be mapped into in polynomial time. Hence, if you can solve an NPC problem in polynomial time you could solve all NP problems in polynomial time by mapping them to the problem you have a solution for, solving it and mapping it back. By the way, polynomial time just means that as the size of the input increases, the number of operations needed to solve it goes up as some polynomial function (n^3+5*n^2 or whatever). Typically only the highest order term is considered because you are looking at so called asymptotic behaviors where n is very large. As for the Turing Machine, it is a mental construct of a remarably simple machine developed by Alan Turing. This simple machine can "run" programs (in a manner of speaking though algorithms is probably more accurate in this sense). The Church-Turing hypothesis is that the Turing machine (and the Lambda Calculus) prepresents the actual idea of what an algorithm is and can solve anything we would call an algorithm. Because it is a formal construct is can be used to prove things like the fact that there are some problems that can't be solved with algorithms. The most famous of these is the Halting Problem which Turing proved to be unsolvable. Web searching is definitely the way to go here.

Re:Emulation, code translation...

[Nyarly]

For stuff like NP-completeness, and Turing machines, etc, the dicipline you're looking for is call "Theory of Computation" by most universities. The Lewis & Papdimitriou textbook is decent and comprehensible. It's one of the few courses, though, that I'd say is difficult to screw up, so I'd almost say any inexpensive text on the subject would suit your needs.

Hell, this might be a good use for the Slashdot journal. I mean, what use is a CS degree if I can't inflict my misunderstanding of mathematics on the uneducated?

Make you a deal, AC. Get a Slashdot login, and I'll start adding journal entries regarding Computation.

Re:No they won't...

[thetman]

hmmmm, someone's a little bitter. Career not progressing so well perhaps? Haven't you heard, there's no money in open source man!!!

aaaahahahahahahahhaaaaaaaa

Remember the PPro

[Anonymous Coward]

The PPro did the same thing as the P4 and just about every other Intel CPU: Sucked at the beginning until people optimized code for it, and in the end, won out. Every Pentium II and III out there has a PPro core in it (with trivial modifications).

Re:wide load comin through

[Anonymous Coward]

Moderators on drugs? Why is the above at +2?

Re:Dell has already discontinued that model....

[Anonymous Coward]

look here.... http://www.ebnews.com/story/OEG20020211S0081

SPARC Will Die Within 10 Years

[Anonymous Coward]

Ignore the marketing from Sun. Cut through the
FUD and ask yourself this question: "Why would
Sun announce that it will sell an Intel/AMD-based
server running Linux instead of a SPARC-based
server running Linux?"

An Intel-based server running Windows has a huge
software advantage (i. e. tons of applications)
over an Intel-based server running Linux. However,
an Intel-based server running Linux has no signifcant
software advantage over an a SPARC-based server
running Windows.

Again, "why would Sun announce that it will sell an
Intel/AMD-based server running Linux instead of a
SPARC-based server running Linux?"

The reason is that the SPARC processor is no match
for the Intel/AMD x86 (or IBM PowerPC). Just visit
the SPEC web site at http://www.spec.org or visit
the TPC web site at http://www.tpc.org

Both SPEC and TPC are well-regarded, honest organizations.
They are not in the business of producing distortions
and lies (like far too many marketing departments at
major computer companies). The objective, fair data from
SPEC and TPC clearly shows that the SPARC processor performs
poorly against the Intel/AMD x86 (or IBM PowerPC). In
the near future, the SPARC processor shall perform poorly
against the Intel McKinley.

Re:Itanium? in $2k systems?

[Ffakr]

Deerfield is supposed to be the 'low cost' IA64 chip. Problem is, the performance of the IA64 right now (and in the near future), combined with the fact that Deerfield must be castrated to be small/low power enough, means that it won't fair well.
Right now, the P4 is faster than the Itanium. P4 should make 3 GHz this year, probably hit 2.5 by the summer release. If one were to believe Intel's PR machine, a Dual P4 should easily overpower the enormous, expensive McKinley.
Deerfield will be McKinleyMX (to borrow Nvidia's naming conventions). It will be a smaller, castrated processor. It will still be big, and it will perform poorly on a price/performance basis. I would expect that you will still be able to get a dual Athlon or dual P4 system for less, and the dualie will blow it away. The only thing that IA64 has going for it is 64 bit address space.

... and don't forget, deerfield isn't expected till sometime in 2003 (and remember how well Intel keeps to IA64 schedules). Expect Deerfield to be a major disappointment by the time its released.
It will be directly competing with:
SMP .13micron Athlon systems
Hammer systems
SMP P4 systems (at over 3GHz per CPU)
SMP G4 (7470?) systems
SMP G5 systems (Yes, they will be out by then ;-)

...stupid Ffakr

SPARC is _ALSO_ no Match for Pentium4

[Anonymous Coward]

Ignore the marketing from Sun. Cut through the
FUD and ask yourself this question: "Why would
Sun announce that it will sell an Intel/AMD-based
server running Linux instead of a SPARC-based
server running Linux?"

An Intel-based server running Windows has a huge
software advantage (i. e. tons of applications)
over an Intel-based server running Linux. However,
an Intel-based server running Linux has no signifcant
software advantage over an a SPARC-based server
running Windows.

Again, "why would Sun announce that it will sell an
Intel/AMD-based server running Linux instead of a
SPARC-based server running Linux?"

The reason is that the SPARC processor is no match
for the Intel/AMD x86 (or IBM PowerPC). Just visit
the SPEC web site at http://www.spec.org or visit
the TPC web site at http://www.tpc.org

Both SPEC and TPC are well-regarded, honest organizations.
They are not in the business of producing distortions
and lies (like far too many marketing departments at
major computer companies). The objective, fair data from
SPEC and TPC clearly shows that the SPARC processor performs
poorly against the Intel/AMD x86 (or IBM PowerPC). In
the near future, the SPARC processor shall perform poorly
against the Intel McKinley.

What's the problem?

[Anonymous Coward]

I'm just an uninformed idiot, but what's the big problem? Why was the transition from the 286 16-bit architecture to the 386's 32-bit architecture so seemless, and now the translation from 32 to 64 is such a big hastle? Is there no backwards compatabilty or something?

Mr.Oreo
-idiot

Isn't it quite obvious yet? Amiga!

[Digitalblasphemy]

The Amiga will make a comeback.

byte order

[Paul Jakma]

javierco is right, and you're full of the proverbial bull's faeces.

little/big endian makes no difference to performance. if anything, for networking little endian are at a disadvantage to big-endian machines as the likes of htons(),ntohs() are not no-ops.

similarly, big-endian machines might have to byte-swap little-endian data formats. (eg ext2/3, etc.) and PCI is little-endian, so data to/from PCI cpu has to be byte-swapped, but that's arbitrary. there is no inherent performance advantage to either byte order.

also, some CPUs can use either byte order, eg MIPS.

that said, nearly everything, is little-endian, simply because of the prevalence of i386.

What Intel's 64 bit stategy should have been.

[Anonymous Coward]

Hindsight is 20/20 and all that, but here is my opinion about what Intel's strategy for 64bit processors should have been.

1) Piv should have included 64 bit extension to x86. This would have given it a leg up over the piii in lowend servers.

2) Itanic should have been a low cost CPU that worked in the piv system architecture. Performance be damned, produce the CPU is real numbers and sell them cheap t however wants them. This should have been released in say 1998 (I know this doesn't fit with the above). Spend 3-4 years giving the things away to CS students, Open source developers and Proprietary Software developers.

3) Keep the FUd in high gear. The one great success of the Itanic so far and the thing that you wouldn't want to change, is the most excellent FUD campagn against the existing 64 bt RISC CPUs and big iron manufacturers. SGI, Compaq-Alpha, Compaq-MIPS, HP, IBM (to some extent) have all fallen on their swords in RISC CPU developement.

Anyways, hindsight is 20/20, but Intel would have been much better off lauching a development EPIC CPU that could drop into existing PCs a few years ago than spending all this time trying to push the CPU design to high performance before releasing it.

Disclaimer: nobody pays me for product developemnt and I'm probably full of sh*t.

UltraSparc RoadMap

[spiro_killglance]

AcesHardware as this info on the UltraSparc
RoadMap which looks pretty strong to me.

http://www.aceshardware.com/#55000446

With Sun's presentation here: http://www.sun.com/analyst2002/presentations/Shoem aker_WWAC_020702.pdf

An UltraSparc V running at 2.0-3.0GHz should
be very competative with Madision (McKinley II),
and it should have on chip multiprocessing, SMT or SMP (or both).

IAXX

[Anonymous Coward]

Ia32, IMHO, is very crappy. I use it but it's slow and is expensive to maintain. I'd love to get my hands on a PowerPC based system or a SPARC as they have the real power behind them. Unfortunatly the market favors popularity instead of inovation making IaXX the clear winner.

author of article quote?

[glo-worm]

who submitted the quote listed in this article? i don't see anybody attributed.. am i missing something?

This really isn't flamebait, retard monkeyrator!

[Anonymous Coward]

Nothing in this guy's article was backed up with any actual facts. Sparc's dying! Ooh, yeah, I believe you! Oh, so's MIPS and PA-RISC? Oh, and you have a bridge you're looking to sell?

Stupid cockass.

It's not CPUs, it's the architecture

[Anonymous Coward]

Before I say anything, my first question is why did anyone think Intel could lead the way with a new CPU architecture? It would have been one thing for HP or IBM to push VLIW stuff, but Intel? They are absolutely the best in terms of the manufacturing, but architectural innovation for the high end?

To me they are the "Microsoft" of CPU makers; their forte is in attacking an existing market though cost of manufacturing and evolutionary product cycles (as well as their sheer size and ability to intimidate competition via agressive pricing and pre-emptive product announcements). They are also pretty good at picking up talent from organizations throwing folks out the window. I read the Compaq spin on abandoning the Alpha, and it wasn't the EV7 that was the problem, but the cost of EV8 versus Intel's projected cost of production for CPUs in the same timeframe. The Alpha's might still be better CPUs, but would a 10:1 price difference be supported? I bet not. (And without the Hudson fab, there's no chance of doing anything about the manufacturing process; but that path was abandoned because DEC under Bob Palmer couldn't get that right either!)

So instead, let's assume Intel gets Itanium right in the 3rd or 4th generation (don't remember the names; I figure the third CPU - the one beyond the one due this year - will be the first one on .13 silicon, and will be finally cost effective, especially on the new 300mm wafers). The real issue now is how to utilize all the CPUs that will be produced. Think about 2x SMP for every desktop; 8-way SMP for just about next to nothing (relative to today's RISC UNIX boxen prices). Intel's got no choice - it has to make the volume of CPUs to validate all the new fabs it's been building.

Hey, I'm talking 256, 512, 1024 CPUs folks; way more than we work with today. My analogy is the size of disks - using 4GB disks in 1995, it took almost a full rack just about to get 100GB of mirrored disk (10 shelves of disks, at 5 disks per shelf). Now if I wanted to I could put 100GB of mirrored disks in my no-name clone home desktop, and nobody would think twice about it. This made many things that were prohibitive for joe and jane user to do when it took 50 disks much more attractive if it just takes two, or even one. I certainly couldn't have afforded the space I waste on MP3 files today 6 or 7 years ago.

So start dreaming! In an era where Intel will commodize the 64-bit CPU (one way or another), the real challenge will be how to build systems smarter. I don't know whether "blade servers" or "grid computing" will be the right answer, but very shortly, we are going to have 64-bit CPUs coming out our ears. Let's come up with a good use for them.

And before anyone says "Who needs 4x SMP in a home machine?" I would remind you to recall similar such statements for the mostly recent past. K.O. said "Who needs a computer in their basement?" (Hey, not the direct quote, but close enough). Now his Compiler team works for Redmond building the next OS for Bill_G, and the Chip team (or those that didn't go to AMD) now work for Intel. Pretty good for a business he didn't even think would be worth anything.

I for one would like to have a home "cluster", with a set of interconnected systems serving as the core of my internet/entertainment/home office complex. No, no, NO - I don't want to keep buying disposable machines; I don't buy disposable home furnaces or water heaters, so why should computers be different? Let me set up a cluster so that I can keep adding systems (even if they are in separate parts of the house - "single system image" with a cluster-wide file system is the direction). I really don't care - figure it out. But between Intel and AMD, I should be able to start buying bulk 64-bit CPUs in aisle 7 of the local X-Mart real-soon-now. We still have some time - start dreaming!!

--AC--

Re:Three way race...

[Anonymous Coward]

How long will Hammer last if Microsoft refuses to deliver a version of Windows for Hammer? Yeah, yeah, Linux, xBSD, blah blah blah...love it or hate it, it's a wintel world...and how long will AMD last if Intel sells Itaniums at a loss for a little while just to undercut them? Actually, MS is throwing a bit of support AMD's way it seems. I'd say the Hammer has a good chance at being accepted.

Are the slashdot moderators drunk or what?

[Anonymous Coward]

What's going on here?

On the first half of that page,
everything is moderated "1",
then the second half is uniformly
moderated "2". Guys, if you don't like this subject,
don't put the topic on in the first place.

I know, you'll moderate this
down anyway, but maybe I can wake
you up this way...

Sun processors - buggy and late

[Anonymous Coward]

Let's see... the last chip was only 2 years behind schedule. Sun is still smarting after their last faulty rushed chip. Expect the next chip to BE LATE - as usual.

Re:Sun processors - buggy and late

[Multics]

Expect the next chip to BE LATE - as usual.

... and benchmark poorly on real jobs - as usual.

The reality of this is Sun's lost any claim on 'high performance' computing. E10,000 has just not got the bang. It especially doesn't have the bang compared to high end Intel or AMD CPUs. The Sun supporters need to run real jobs on E10k then run the same job on an Intel/AMD cluster that cost 10% as much. The differences are profound and not in Sun's direction.

Sun's last 5 years of CPU development have it way behind the performance curve. Can they catch up? Perhaps. I doubt it.

-- Multics

Re:Sun processors - buggy and late

[Anonymous Coward]

Sun's last 5 years of CPU development have it way behind the performance curve. Can they catch up? Perhaps. I doubt it.

Well, considering their sales, support, and software all pretty much blow I guess it's not surprising that their CPU's suck as well.

Oh wait, tell me again how the slow CPU built on a PCI bus is going to give better I/O performance for some reason!!! I can hardly wait until Sun dies.

Re:Sun processors - buggy and late

[BadlandZ]

"Let's see... the last chip was only 2 years behind schedule."

I'll wait and see. I sort of know more than I should, and more than I should say... But, let's just wait and see ;-)

I know what comes next

[Anonymous Coward]

It's a realy nice piece of hardware, it's a bit hard to find, but it's got a name it's called...the 68040 Macintosh

Reality

[Anonymous Coward]

CPU speed is only one portion of the equation. Think of the whole execution time of a program as time spent on the CPU and time spent moving data around. If you somehow come up with an infinitely fast CPU, you are still bound by moving data.

Balanced design is important. You make one aspect very fast, you may do so at the risk of not making another aspect very fast. It is a balancing act.

You can turn the speed of your P4 past 3.5 GHz with a nice LN2 cooler. But your applications (not meaningless synthetic benchmarks like SPEC, Linpack, etc.) will not be 3.5/2.0 x faster.

The issue is that data starts off chip, gets on chip to be processed and goes off chip again. The faster you make that chip, the less time it spends computing, and the more time it spends waiting.

You can also look at the VLIW Itanium. VLIW is tremendously difficult to program for. Writing compilers for it is almost impossible. Think Trace Multiflow.

The whole Itanium architecture is highly questionable. As other readers pointed out, it largely doesnt matter, as Intel has basically killed off all the competition but AMD.

And thats the rub. The AMD stuff is a dark horse. If someone there gets a clue and starts getting some major OEMs to ship their chips in computing servers (not desktops), well, then they will have a chance to play in this game. Otherwise, it will be Intel everywhere.

The AMD chip pummels the P4 and the Itanium on many int/fp heavy codes which are latency sensitive. The P4 is tremendous on bandwidth limited codes. Itanium should be great on those too. It isnt.

And that is a problem for Intel.

Research this! (Sparc: its alive!)

[Anonymous Coward]

http://biz.yahoo.com/n/s/sunw.html

Sun has approx. $ 6 billion in cash...
that is US dollars, not any kind of variant.

Research company pffff.

Sun and IBM better start porting your Solaris, AIX

[cuteface]

Considering the tremendous market clout that Intel possesses,

there's no way IBM or Sun can hope to match the cost

advantage of Intel and corporate customers just are not

willing to continue investing huge budgets in legacy chips!

IBM and Sun should seriously consider porting

their AIX and Solaris to Itanium if they don't wish to

lost out in the long run.

Sounds like a trollish or clueless post.

[guacamole]

My world view is that Itanium based systems will become commodity products very quickly after good silicon is available in reasonable volume. At that point, why should one spend $8-10k for that hardware from the likes of HP, Compaq, Dell and others when one can build it for $2k (or even less)?

When peolpe start buying Itanium systems in volume, then the prices will drop on the Itanium systems. The reasons, they're expensive is not because the chips are hard to come by but because no one wants to buy them right now.

However, this comment alone makes me wonder about he posters cluelessness. He obviously hasn't worked in any real production environment. You people should realize that you simply can't build the kind of systems that Dell, HP, etc sell -today- out of commodity components. Take a look at a typical high-end SMP Dell server: propietary OEM motherboard, propietary case, hot-swap hard drives, hot-swap redundant power supplies and cooling, LOM support, etc. All components have been carefully designed to work together to produce a reliable, and scalable server system. You will never ever build the same kind of system on your own and if you do it's not going to be cheaper than buying one. Plus you don't get the vendor support.

The comment about SPARC being death is completely astonishing at the time when Sun is -THE- unix market leader. SPARC CPUs were never faster than the competition but that didn't worry Sun users as long as they were up to par with the competitors. The reason people buy Sun hardware is not the CPUs (CPU is alone is useless) but Solaris which is THE enterprise class OS and its applications, Sun's excellent support, massive multiprocessor scalability of Sun systems, massive I/O bandwidth, etc.

Current Sun chip is not bad at all (UltraSPARC III) and Sun is working on UltraSPARC V.

Re:Sounds like a trollish or clueless post.

[Anonymous Coward]

When peolpe start buying Itanium systems in volume, then the prices will drop on the Itanium systems. The reasons, they're expensive is not because the chips are hard to come by but because no one wants to buy them right now.

ZZZTtt wrong answer. Die sizes of 2.1cm a size assure that even McKinley is going to always be expensive to produce because yields are always going to be poor.

The Intel Roadmap for Itanium has 2 or 3 new cores over the next 2-3 years, each will be faster and each will be smaller. At some point in this time frame Itanium will reach a price point where it competes well with PIII/IV and AMD Athlon. They already compete favorably with Sparc.

However, this comment alone makes me wonder about he posters cluelessness.

Nope, you don't get it. Most Itanium volume purchases will go into clusters in the medium time frame. A cluster node needs memory, network and perhaps high-speed disk. It doesn't need hot-swap this, redundant that. Besides, I'll take an ASUS motherboard and stack it up against any Dell MB and come up at least equal if not faster. Remember that Dell, HP, and Compaq buy many of their motherboards from the same places we can and just rebadge them.

So system 'integration' isn't a valid reason... we can do (and have done) better in the parts market and often do.

The comment about SPARC being death is completely astonishing at the time when Sun is -THE- unix market leader.

How does 'market leader' compete when Sun has consistantly failed to deliver even moderately high performace CPUs for 5 years? Face the fact that Sun is behind the performance curve and slipping fast. DO A FEW BENCHMARKS. And don't even get me started on the stupid cache consistancy mess Sun got themselves into -- stable? ha! dis-reputable CERTAINLY

I'm not arguing that Sun isn't usually stable, etc. I am arguing stability doesn't mean squat if your CPUs are 100-1000% slower than inexpensive commodity Intel Itaniums.

Annon

Re:Sounds like a trollish or clueless post.

[marcovje]

Yes, but the entry is much less. An own main processor is a much bigger barrier to entry than a customized mobo on commodity chips.

One can easier step into that market than invest
the 1E9 dollars.

It is not that you can buy the Itanium machine in the shop on the corner, but there might come more
companies that can supply them, which will result
in a price drop.

Re:Sounds like a trollish or clueless post.

[enkidu]

When peolpe start buying Itanium systems in volume, then the prices will drop on the Itanium systems. The reasons, they're expensive is not because the chips are hard to come by but because no one wants to buy them right now.

Uhmmm. Have you seen the die size specs for the Itanium? It's a freaking monster size chip (McKinley's >400mm2 I believe). Unless Intel is able to pull off an order of magnitude decrease in defects, the prices in Itaniums ain't ever going to drop compared to other CPU's (Sparc, MIPS, PowerPC etc.)

He obviously hasn't worked in any real production environment. You people should realize that you simply can't build the kind of systems that Dell, HP, etc sell -today- out of commodity components... All components have been carefully designed to work together to produce a reliable, and scalable server system. You will never ever build the same kind of system on your own and if you do it's not going to be cheaper than buying one. Plus you don't get the vendor support.

Really? Have you worked in a real production environment? The motherboard may be proprietary, but the chipset (90% of the development cost if not more) certainly isn't. AFAIK you can build your own with almost all of the features you need from off the shelf components. With vendor support also if you want. Checkout Penguin Computing if you want to see some solid server boxes made out of quality commodity parts and with vendor support.

The comment about SPARC being death is completely astonishing at the time when Sun is -THE- unix market leader. SPARC CPUs were never faster than the competition but that didn't worry Sun users as long as they were up to par with the competitors.

I don't know what you mean by "-THE- unix market leader"; but without objective criteria it's hard to say where you're coming from (unless it's Sun marketing literature). BTW, SPARC CPU's are not up to par with the competitors, especially with regards to floating point processing. In FP, PowerPC, Athlon, Pentium, all wipe the floor with the SPARC. And the Alpha still wipes the floor with all of *them*.

Re:Sounds like a trollish or clueless post.

[Anonymous Coward]

quality commodity parts

Ummm... isn't that an oxymoron?
I really thought that quality and commodity
were mutually exclusive...

Commodity: Generic IDE Hardrive, Generic Mobo?
No?

Normalise the scores to clockspeed.

[Anonymous Coward]

Doesn't look so great now, does it, smart guy? Fuck you slashdot niggers are dumb. AMD and intel and dell and whoever probably compile spec with mmx optimisations on anyway.

Re:Normalise the scores to clockspeed.

[Datafage]

I'll just reply to your subject line, the rest doesn't warrant it:

Why normalize to clockspeed? PPC chips are engineered for lower clockspeed and a greater IPC. Normalizing to clockspeed would give them an unfair advantage. You have to measure at what's available, fact is Athlons are available at a higher speed than PPCs.

haha, you actually buy that bs

[Anonymous Coward]

Go start quake3 back up and brag to your friends about how fast your "computer" [video card] is.

I suppose mojo-raisin is your 31337 |-|4>0R handle too?

Re:Sun and IBM better start porting your Solaris,

[Anonymous Coward]

Reality check: AIX is on Itanium already.

SPeed of ...

[leuk_he]

I think you are talking about the speed of electricty, which is much slower than the speed of light.

By the way the speed of light in matter (glass) is slower that the speed of light in vacuum.

And to answer your question: Yes.

Re:Sun and IBM better start porting your Solaris,

[guacamole]

In addition, Sun was the first to announce that Solaris run on an Itanium emulator and there is a rumor that the OS used to run on test IA-64 equipment in Sun labs. However, because of Sun's squabbles with Intel, this project never saw the light. Was Intel so naive to believe in the beginning that Sun would abandon its SPARC platform for IA-64?

think bigger

[NovaX]

Sorry this is so late, /. must have gone on their backup server, cuz my account stopped working and I couldn't post... oh well.

Your missing a huge number of issues. For one, these high end chips aren't usually put together by hobbiest and used in enterprise situations, like a PC is for a desktop. Here the branding is half of the importance - support contracts. The other half is the technology of the company - the O.S. and tools, the hardware solutions, and finally relative performance. HP made a killing for years at government labs through support contracts on UNIX workstations, and while the systems became ancient they stayed around due to the support until they had to be killed off.

HP, IBM, Compaq, etc. bring solutions to companies, which is what matters. The chip itself isn't to important, so the R&D gets to be a hassle making few players. The chip must simply have relative performance to the competition. The factors involved are then the scalability of the system, which involves the chipset. The chipset sets the system bus, memory type, multi-processing ability, etc. This is the 'solution,' which is what the companies are offering. Intel offers the core technology, but the system manufacturers bring in their own 'secret sauce' (as Paul DeMone called it) to the table. Above that, they bring the support, Operating System, and platform.

Therefore, while sure, you could build a workstation Itanium (but definately not for $2k), the big money are the clusters and the like. But the workstations will be built, and for a high end, high quality machine who would you trust, a brand like Dell with support contracts, or your neighbor? Its not commodoty yet, so few will turn to the guy down the street until prices drop significantly.

There are definately players left. The $1B mark R&D mark I assume is from how much Intel spent on the architecture, but that's on building an entire platform + obtaining corperate support. Sparc already exists and upgrading it is like doing the same to x86, it simply requires talent. Sun has mentioned both SMT and multi-cores in the future, and has spent work on their compiler in recent months (notice the big SPEC jump?). Don't count them out, their getting hit at the low end by PCs and the high by IBM. Its not Intel killing them just yet.

Lastly, some people on here seem to still believe Itanium is huge due to its core. In actuallity, the core is 25 million trasistors and rest is all cache. For the exact numbers, read the RWT forum, since I forget them offhand.

IA-64 wont rule the world due to expense, compilers, software platform, and where the market positions it. And lets not forget performance, different jobs need different skills and Itanium shines at FPU unneeded for desktops, fails at integer which they love. Vice-versa for many scientific apps. Intel wont distroy everyone else, but they'll certainly make a dent. Its already been felt.

SGI MIPS

[marmite]

SGI are still designing new MIPS chips, and recently opened a new microprocessor design office in Boston.

Binary Compatibility will save sun.

[jm91509]

The key to sun is binary compatibility.
If a big corporation has to recompile/rewrite all their software to take advantage of the new speed of these chips, they simply won't buy it. It the emulated performance is as bad as I've heard there is little reason to upgrade.

With a sparc on the other hand, if you write and compile something 10 years ago on a sparc 5, it'll run just as nicely thank you very much on todays 15k's.

Thats suns advantage.

Re:Binary Compatibility will save sun.

[Anonymous Coward]

As opposed to, say, running i386 apps on a P4...

Re:Binary Compatibility will save sun.

[Anonymous Coward]

There is no speed associated with the itaniums. I have several boxen here - a 4-way, and a few 2-ways, and they're pretty slow. The only advantage I can see in them is the added address space.

High tech: Commodity=Debranding, = Open?

[Paul Komarek]

After checking 3/5 pages of >=+2 comments, I got tired of checking if this opinion has already been stated. At risk of repeating someone else's post, here's my opinion.

If and when mainstream processors become true commodities (there's a good definition in here somewhere), the value of Intel's brand will vanish. This will reduce Intel's revenues, and hence R&D and capex budgets. Companies like AMD, who have always run their business on slim margins, will have a structural advantage over "fat" companies like Intel; this will allow them to survive.

The above scenario occurs when nobody has any cost-efficient means of stimulating the mainstream market for cpus. This will leave customization and services as the profitable parts of cpu design and manufacturing. It is easy to imagine that focus will turn toward other bottlenecks in system architecture. For example, suppose an effort is made to push parallel processing into mainstream computers, with multiple vendors create a multitude of approaches requiring quick and cheap cpu modifications. I expect that such a market will favor increasing openness in cpu design, just as the software markets are discovering the serviceability benefits of open source software.

Therefore, my prediction (woohoo, let's guarantee that I'll be completely wrong by predicting the future) is that cpu commoditization will lead to the prominence of open cpu designs. Because of the increasing success in open source software, this shift will occur somewhat quickly and less painfully than it has for operating systems. Of course there are major differences between open cpu cores and open source software, there will be plenty of exciting socioeconomic developments leading to profitable open cpu cores.

In the end, this could be a major win for established semi-open cores like SPARC. However, community-developed open cores like the FCPU and various efforts with open StrongARM implementations, will have a jump on building the community infrastructure that allows open markets to be efficient and useful.

That's my contribution on the subject. It won't be a technical change that we'll see next in the cpu market; rather it will be a socioeconomic change.

-Paul Komarek

SPARC is dead, jugding by performance

[Anonymous Coward]

A ~ $6k Ultra5 (450MHz one) was killed by my cheap, ~$300 K6II-500 when compiling a couple of C sources - looking at the total time the SUN was 3-4 SLOWER; both were running gcc.
Working as a sysadmin in a faily large company producing mobile equipment and therefore needing large amounts of computation power for simulation, we are also using testwise an dual P3-Xeon-550 running Linux. Jobs are mostly running matlab. Sad for Sun, that little box is stillt around 2-3 times faster (matlab-jobs are not too multithreaded).

Solaris/Sparc may scale beyond 8/16/32/50 CPUs - but who needs that much, when 2 of them are faster (think: S/390) ?

Real numbers

[r6144]

2.2GHz P4: SPECint2000_base = 790, SPECfp2000_base = 779
800MHz Itanium: SPECint2000_base = 370, SPECfp2000_base=711

The P4 is a Dell Precision Workstation 340.
The Itanium is what mentioned on the intel site.

So it isn't really worthwhile to use an Itanium to run compilers or similar things.

OT: division by 0

[shani]

Incredibly off-topic, but your sig interested me:

it's late. i'm tired. DIV 0 ERROR! - why not just make divide by zero return zero, or NaN, or whatever, anyway?

This is easy to achieve with floating point math, at least on a Unix box:

#include <stdio.h>
#include <signal.h>

int main()
{
signal(SIGFPE, SIG_IGN);
printf("Positive number divided by 0 yields: %f\n", 11.0/0);
printf("Negative number divided by 0 yields: %f\n", -11.0/0);
return 0;
}

On my system, I get:

Positive number divided by 0 yields: inf
Negative number divided by 0 yields: -inf

In the integer world, there really is no value for infinity, so you can't so casually ignore division by zero. In any language with exceptions you can trap the error and carry on as well. Or you could just be a man and test your code before shipping it to the user. :)

Yes, and it's pro-itanic FUD.

[morbid]

It's a kind of marketing. It's probably someone with a vested interest in itanic (from HP, Compaq, Dell or intel) trying to spread FUD about the "demise" of current working, available, better 64-bit processors (like PA-RISC, PowerPC, MIPS, UltraSPARC, Alpha etc.) to make the less well informed geek community think that itanic is the future. Unfortunately, they're 3 years too late and everyone sees right through them.

SPARC Dead? I don't think so.

[oddRaisin]

Sun's greatest feature isn't it's SPARC, although that's a major component. It's the fact that SPARC Architectures are so scalable. Take for example an E10K server. 16 system boards with 4 CPU/ 4GB RAM. Any number of system boards can be connected together to make a "domain" or a single system. So you could have a single instance of Solaris on a 64/64 system, 2 instances with 32/32 each, or 16 individual domains.

From what I've seen, Intel has only recently introduced its ProFusion chipset, which allows Intel systems to scale to 8 processors. Hmmm . . . . 64 max CPUs together ( E15k will have more ), or 8 CPUs. Granted I haven't looked into SMP for the Itanium chipset, so there may have been advances there ( especially with the partnership with HP ).

Finally, there is far more hardware redundancy and error checking in Sun hardware ( E class ) than in Intel based platforms. Until this is addressed ( removing all Single Point Of Failures (SPOFs) ), Intel won't be seen has a high available environment except through extensive software failovers.

Just my 2 cents.

Re:SPARC Dead? I don't think so.

[MidKnight]

. . . 64 max CPUs together ( E15k will have more ), or 8 CPUs.

The E15k already has more: up to 106 processors. And you're right, the supposition that SPARC is dead simply because of the current financial state of Sun is pretty silly.

Even more silly to me is the fact that people are still equating Mhz to the overall value of a chip. And before people start whining, I'm not talking about the "Megahertz Myth", either. Currently, per-chip computing power is dirt cheap. It seems to me that factors like scalability, power consumption, and (as you mentioned) error checking are quickly becoming more important in general-task CPU's.

--Mid

Re:SPARC Dead? I don't think so.

[Anonymous Coward]

What about the ? 32 Pentium III Xeons in one Windows OS image, AND it's Itanium ready. In addition, it's got ECC and full data path checking.

In ignoring this system, you're comparing a top of the range, 64-processor enterprise-level server with high-end commodity 8-ways.

Russians may make a comeback

[muchandr]

Their airframes have been quite competative
with Western ones so far in passenger jets and
they rule the heavy-duty cargo jets, IMHO.

Things that Make you go hmm

[linuxislandsucks]

I was just looking for more confirmation of this thought

"Why are web service platforms(software) so high cost from those companis that also sell big servers"

I think I may have foudn the answer in part of your post..

If this is correct there are going to be alot of small companies competing in several key new technology areas acrross the web in the next 2 years..

Should be very exciting!

How was this a troll?

[Marx_Mrvelous]

Being modded "troll" means that they're jealous of your comment ;)

Incorrectly assumed

[crimsonplauge]

Speaking as a Solaris admin myself I would like to state this isn't completely accurate. Not all Solaris software runs on all other machines. Lot of applications are based on arch of the machine. Hence if it's a Sun4u it'll work on any sun4u workstation. Not all sun4m applications will work on a sun4u.

asynchronous?

[blind_abraxas]

What about asynchronous chips? No clocks, low power consumption...wouldn't this represent another track to Intel's single track?

You can smell the death on Sun

[Anonymous Coward]

Sun's market share will only continue to decline.
Only a handful of large companies can afford Sun. And as these old dinosaurs go out of business (it only takes a few Enrons goin out of business) and as new companies go with cheaper x86 chips (Intel or AMD)running either linux or windows.

Re:Sun and IBM better start porting your Solaris,

[Anonymous Coward]

AIX 5 is already ported to Itanium.

The Future is Uncertain, The Endian is Always Near

[Anonymous Coward]

Apologies to JM, Thanks to Anandtech:

Intel may design Hammer-like chip

http://www.anandtech.com/news/shownews.html?i=15 31 5&t=an

Misinformation

[deanstevenson]

HP did *not* give up processor engineers, they sold a chipset group to Intel. The referenced story states that quite clearly. Why perpetuate misinformation?

Re:Sun and IBM better start porting your Solaris,

[toddstock]

IBM and Sun should seriously consider porting their AIX and Solaris to Itanium At least IBM has been there, done that, and shelved the outcome

Way down the line

[junkster191]

Quantum computing will, of course, take over everything. Assuming they iron out all the kinks and make it a marketable product- which could easily still be ten years off. But the potential is absolutely mind-boggling. The acceleration in computing power will make Moore's law obsolete.

Consider the speed at which you can compute things with an abacus, and the speed of the ASCI White, the world's fastest machine, running at about 7.2 teraflops. The difference in speed between these two things is orders of magnitude smaller than the difference between a relatively simple quantum computer and the ASCI White.

If you are thinking *very* long term it might be a good idea to start learning the new programming rules of quantum computing.

Parallel to Itanium

[Anonymous Coward]

I have heard from a fairly reliable source that Intel is working on a next generation X86 chip in case the Itanium is really the unobtanium.

More Information on the AMD Hammer

[advtech]

The Edge Report has a review of the AMD Hammer Processor as well as a look inside AMD's server strategy going forward. The link is:

http://www.edgereport.com/article.php?sid=133

--

Multiprocessors!

[morcheeba]

There is a large barrier to entry for designing huge processors, but I think processor startups will always exist. With resources a small fraction of the big guys, they can't design and manage a device this complex. Instead of designing a 25 million transistor beast, people are designing much smaller processors, making sure that each can network well, and then populating chips with multiple copies of these processors.

Startup Pact (with a staff of only 30!) has designed a 30 million transistor chip by iterating a 200k transistor processor 128 times, yielding a theoretical maximum 12.8 billion MACs/sec @ 100 MHz. Of course, that's the theoretical max... it will take the correct problem and/or some good programming to get anywhere near that maximum.

Lexra has put 16 MIPS32 processors on a single die. Again, with only 30 employees.

How many of all those fabs do .13 micron?

[Mike Greaves]

Answer that and you'll just have shot down your entire first paragraph. There are almost no CPU fabs at .13 micron, outside of the PC market. Are there *any* CPU's at .13, other than Power4 and x86?

Your second and third paragraphs are essentially agreeing with me - there is on-going, and will be more, fab consolidation...

Good math. Mod him up

[Anonymous Coward]

He even got the velocity factor of RG-58 right

ARM?

[Anonymous Coward]

I want a 64 bit ARM or XScale!

CLR != all .Net software

[eples]

Just a friendly reminder that you can still write C++ (unmanaged) code and compile it to machine language under .NET . Using the CLR is just an (often useful) option.

Re:*cough* PowerPC *cough*

[Nalmar]

Altivec is a vector unit that operate on integer and IEEE-754 floating-point. Vectors are 128 bits arrays of 16 * 8bit integer or 8*16 bit integer or 4 * 32 bits integer or 4 * 32 bits IEE-754 floating poing.

And for the bus part, DDR is only a small improvement on the pc133 bus. If you think it's twice or more the speed of pc133, you're completely wrong. And what kind of code do really saturate the memory bus ? G4 like intel or AMD are aimed at desktop computing uses. Most memory accesses are filled by the caches and by design, RISC CPU ( g4,mips,sparc,... ) work mostly on register data reducing the memory access speed dependency.

Re:*cough* PowerPC *cough*

[ToLu the Happy Furby]

Altivec is a vector unit that operate on integer and IEEE-754 floating-point. Vectors are 128 bits arrays of 16 * 8bit integer or 8*16 bit integer or 4 * 32 bits integer or 4 * 32 bits IEE-754 floating point.

Thanks; did not know that. But I was thinking of IEEE double-precision floats, because the original topic was whether the G4 could be a replacement for the big iron chips discussed in this article. Those are not included in Altivec, as I suspected. (They are in SSE2, though.) But I should have been more clear.

And for the bus part, DDR is only a small improvement on the pc133 bus. If you think it's twice or more the speed of pc133, you're completely wrong. And what kind of code do really saturate the memory bus ? G4 like intel or AMD are aimed at desktop computing uses.

For many pieces of useful desktop code--some 3d game engines, streaming media encoding/decoding, etc.--the performance increase could easily be 30% or more on a single processor machine. (As for a dual-G4, the performance increase depends too much on how scalable the program is, etc. But using two processors sharing a single 1 GB/s bus for floating point work is ridiculous, as I said.) For many fp-intensive HPC-style programs, the performance increase could be 80% or higher.

And yes, I know that no one would use a G4 to run that sort of stuff in the first place (although P4s would be a great choice if the application could be parallelized to a cluster of PCs); but the thread was discussing using the G4 as a replacement for big iron machines, so yell at previous posters for getting on the topic first, not me.

Most memory accesses are filled by the caches

Yes but most of the *time* spent waiting for memory accesses is spent waiting for memory access from DRAM.

RISC CPU ( g4,mips,sparc,... ) work mostly on register data reducing the memory access speed dependency.

A larger register set means less spilling to L1 cache; it has no effect on memory usage from L2 on out. If your application has a 10 MB dataset, then it has a 10 MB dataset, period.

Incidentally, RISC code is bloatier than CISC code because it uses more instructions of fixed instruction length to do the same amount of work than fewer, often shorter CISC instructions can do. This of course makes the CPU core simpler to design and therefore faster with a given set of design and implementation quality. However it does lead to significantly larger binaries, and thus a larger bandwidth burden on all levels of the memory hierarchy. This very often leads to RISC processors placing a higher strain on DRAM bandwidth. However, these issues generally only show up in integer code, not in fp code which was the original subject. Still, it is generally the case that a RISC processor needs more DRAM bandwidth than a CISC processor to achieve the same level of memory performance. (Although, as you point out, L1 data latency is more critical for an ISA with a small register set like x86 than a large one like all standard RISC ISAs.)

Just to be clear: I'm not arguing that RISC is not clearly superior to CISC as an abstract design philosophy, because it absolutely is. Just that RISC does have some negatives, including code density. And that even saddled with their inferior ISAs as they are, the P4 and K7 are among the fastest performing single CPUs in the world, and blow everything else away in terms of price/performance. And that the G4's fp performance sucks, which it does.

Most 32 bit processors are embedded

[Anonymous Coward]

From Embedded Systems Programming (which I think is the best programming magazine out there, and I am not an embedded programmer). They claim that the percentage of 32 bit CPU's sold in computers is so small compared to all the embedded 32 bit CPU's out there, that the number rounds to 0.

If you are looking for competition for Intel, look at it coming from the low end. Just as Intel eats the margins of others, their margins get eaten as well. ARM (all varieties), MIPS, embedded x86, dragonball (Palm), ect... all are around, consume little power, and are cheap. Combine with a DSP or some processing units. You can have massively parallel machines on the cheap.

Re: Wrong again

[Anonymous Coward]

Do you mean 0.66 (66%) or 0.66%? I'm confused.

66% of 30cm is about 20cm.

Anybody can build a Dell

[Anonymous Coward]

Sorry, but Dell doesn't do research. Other companies certainly do research, and custom build servers. Dell just puts commodity components together. Any whitebox manufacturer can build a better Dell than Dell. Just take a server case with redundant power supplies, purchase a server motherboard, get a raid card and a stack of Hard Disks, throw in tape backup, and put a few NIC's in it. The trick is getting everything to work together with the software, which Dell outsources to people like Cray. That is the way Dell runs their operation, and they have been very successful.

You are correct in saying that building a server is not like building a PC. However, you wrong in mentioning Dell as an example. IBM, Compaq, HP, Unisys, ect... are the ones building actual servers with proprietary hardware.

Re: Wrong again

[pdp11e]

oooops 66%

Lies!

[Anonymous Coward]

top500.org is a list of top 500 fastests clusters on earth.

you will see that PowerPC is faster than intel and that is why it dominates the largest percentage of the supercomputing clusters at top500.org

that means you are a lying moron when you tried to claim that intel is faster than BM PowerPC.

Spec is a lame test. it offesrs no free source for verification and uses deliberately proprietary source.

they lied when they created it and rejected existing benchmarks as part of the suite.

its a scam. and it used to cost 50,000 dollars , then still eventually 5,000 dollars.

a real benchmark should cost 0 dollars an not require revision every few years.

review top500.org before you spout lies.

also notice almost none of them are linux.

Re:*cough* PowerPC *cough*

[Nalmar]

When you design a processor, you look at what kind of job it'll be doing and optimize it for the most frequently used instructions. Double precision float are very far from being a priority. What kind of data range from 10E-1024 to 10E1023 ? The forces applied on the different areas of a space shuttle entering the atmosphere ? A simulation of a nuclear explosion ? The 10E-128 to 10E127 of the single precision is more than enough for most of the situations. The G4 floating point units support double precision but not altivec.

On any system, the memory is a bottle-neck but the problem is DRAM chips, not bus. As long as the bus support what the dram chips can spit. 3D games send lists of polygons to the memory card. Even if we imagine a real crappy game using absolutely no acceleration, 30fps*1024*768*3 = 67 MB/S even if we double it for memory reads and add a lot of disk and network use, we're still far from 1GB/S. The same hold true for streaming video. The only solution is either faster ram ( SRAM is a lot more expensive, and the other solutions like DDR and other are only marginally faster ) or bigger and smarter caches that preload data while other data is being processed.

A larger register set means less spilling to L1 cache; it has no effect on memory usage from L2 on out. If your application has a 10 MB dataset, then it has a 10 MB dataset, period.

A large register set allow you to work with your data without having to read and write to memory all the time which is the biggest time waster on any modern system. Like you said, most of the accesses on a intel will be handled by L1 but you still have to calculate the physical address from the logical address in the instruction which means page table lookups ( ie other memory accesses ) and the arithmetic operations associated.

IBM's dual - cpu die ...

[Anonymous Coward]

is a complete failure. The two cpu's share the same level 2 cache. If you look closlely at IBM's benchmarks using these cpu's, (for example their preposterous comparison of a "16-cpu" Regretta vs. a 16 cpu Sun 15000) you will find that they invariably *turn off* one of the cpu's on each die. In order to run a 16 cpu benchmark they use a 32 cpu machine with only half the processors actually running. Why? Because when you have two cpu's sharing the same cache you thrash it. Your cache hit rate goes down the tubes. How do you do instruction or data prefetch when you have two cpu's working the cache? You can't, not with any reasonable amount of silicon. Every cpu needs its own cache and its own prefetch logic running that cache - those aren't things you can just lump together and share.

Re:*cough* PowerPC *cough*

[ToLu the Happy Furby]

When you design a processor, you look at what kind of job it'll be doing and optimize it for the most frequently used instructions. Double precision float are very far from being a priority. What kind of data range from 10E-1024 to 10E1023 ? The forces applied on the different areas of a space shuttle entering the atmosphere ? A simulation of a nuclear explosion ? The 10E-128 to 10E127 of the single precision is more than enough for most of the situations. The G4 floating point units support double precision but not altivec.

Yes, most consumer applications use single-precision floats. However, most HPC code uses doubles. The original poster was positing that the G4 would be a good replacement to all the 64-bit CPUs that are getting pushed out by Itanium because of its fp number crunching abilities (i.e. for HPC workloads). This is wrong in almost every way possible:
1) the G4 doesn't have the SISD execution resources necessary, because the G4's fp units are underpowered
2) the G4 doesn't have the SIMD execution resources necessary (even if all HPC code would magically be vectorized), because Altivec doesn't do doubles
3) the G4 (as it appears in Macs) doesn't have the DRAM bandwidth necessary

Indeed, the current top of the line, a dual 1GHz PowerMac G4, would be about the worst possible choice for replacing big iron HPC machines, even if a strong FORTRAN compiler existed.

My points were all in reference to this proposed use for the G4. But yes, you're quite right that the G4 isn't nearly as inferior when it comes to desktop workloads.

Of course, your assertion that "when you design a processor, you look at what kind of job it'll be doing and optimize it for the most frequently used instructions" is both extremely true and extremely ironic, because the G4 is much more widely used as a signal processor in various embedded systems than as a general-performance desktop CPU. This is why it has comparatively meager OoO abilities and why it allowed itself to be saddled with an overpowered vector unit which gates clock rampability, while leaving its SISD execution units relatively underpowered. OTOH, I'm fairly sure the G4 has been equipped with DDR in its embedded incarnations; certainly that particular fault can't be blamed on the chip's intended design.

On any system, the memory is a bottle-neck but the problem is DRAM chips, not bus.

Huh?? Um...try sticking some faster DRAM in a PowerMac (e.g. PC2100, PC2700, RDRAM, etc) and tell me how that helps!

As long as the bus support what the dram chips can spit.

Which the current G4 bus cannot. The difference, so far as I can tell, is semantic. (It's also wrong; DRAM chips can be made to run at fantastic speeds for reasonable prices: witness current high-end 3d cards, with DRAM bandwidth of 7, 8, and in the case of the newest G4s, >10 GB/s! The problem is coming up with a bus which can handle all that throughput in the much noisier and more complex environment of a motherboard with socketed DRAM, as opposed to a small chip with soldered DRAM.)

3D games send lists of polygons to the memory card. Even if we imagine a real crappy game using absolutely no acceleration, 30fps*1024*768*3 = 67 MB/S even if we double it for memory reads and add a lot of disk and network use, we're still far from 1GB/S.

This is quite incorrect. First of all, what you're imagining is not a "crappy game", and not even a non-interactive rendering, but a non-interactive video playing in 24-bit color. If we want to turn the calculation into how much polygon data gets sent to the video card, we'll replace the number of pixels (i.e. 1024*768) by the number of polygons in the scene (say, 100,000), and the number of bytes per pixel (3) by the number of bytes per polygon (3*32-bit spatial coordinates for each of 3 vertices plus for the normal = 48 bytes; note that this doesn't include other information which needs to be sent along with the polygon, e.g. pointers to its textures, etc.) So instead we've got 30fps*100,000*48bytes = 144MB/s. Of course, 30fps looks pretty shitty, so for decent immersion we're actually looking at 60fps, or 288MB/s. And, again, this leaves out all the other polygonal data besides the vertices and normal.

And, of course, we're just talking about data that comes from the CPU and is sent over the AGP bus to the graphics card; in a real game situation the DRAM most certainly does not store the predetermined locations of every polygon in the game world (how could it know?)! Um, so this has very little in fact to do with what we're talking about.

I can't provide solid approximations of how much DRAM traffic a real 3d engine actually provides, except by pointing out that in non-graphics-card-limited situations, a high-end K7 can easily gain 20-30% in fps by replacing a good PC133 chipset with a good PC2100 chipset. For example, see the last benchmark on this page. The KT266A beats the KT133A by 27%, and the nforce increases that to 32%, albeit with an ill-utilized-but-still-there dual-channel configuration. This is direct real-world proof that moving from PC133 to PC2100 can gain you ~30% in very common consumer desktop applications. (In fairness, the Serious Sam engine is known to rely particularly heavily on DRAM throughput where, for example, the Q3 engine seems to care more about throughput and latency on the cache level. Still, 20-30% is a pretty fair estimate overall.)

A large register set allow you to work with your data without having to read and write to memory all the time which is the biggest time waster on any modern system.

Having 32 GPRs (PPC) instead of 8 (x86) means you need to use an astonishing 24x4=96 bytes of cache to make up the difference. Most modern processors have L1 caches of slightly more than 96 bytes in size. Having more GPRs is good, but it has nothing to do with saving memory traffic on any higher levels of the memory hierarchy than L1-to-register and back.

Like you said, most of the accesses on a intel will be handled by L1 but you still have to calculate the physical address from the logical address in the instruction which means page table lookups ( ie other memory accesses ) and the arithmetic operations associated.

Wrong. Try looking up how a cache works, how memory pages work, how virtual memory works, etc. (Short version: believe it or not, but they've solved that problem. The translation from logical->physical addresses only comes into play when you have a page fault. OTOH, there is still work associated with calculating the physical address, but this is why all modern CPUs have seperate execution units to allow for the computing of memory addresses without clogging up the ALUs.)

OTOH, the effect I pointed out--that RISC code is more bloated than CISC code--*does* have an impact on the level of DRAM-to-CPU throughput, albeit, like I said, usually only in particularly ugly integer code.

The alrogithms for most heavy fp number-crunching, in contrast, are usually pretty good, and the code pretty tight. But the datasets are often too large to fit in even a 2 MB cache, and the nature of the calculation is often such that it is gated by memory throughput. There's just no way to run these sorts of calculations on a computer with a 1 GB/s bus and have it be anything but slow. And this is without even considering the folly of having a 1 GB/s bus that's supposed to keep 2 CPUs fed with data from DRAM *and* carry all the messages passed from one CPU to the other. (e.g. anytime CPU 1 wants data that's in that nice big 2 MB L3 cache of CPU 2...)

Java bytecode native to CPU

[leonbrooks]

here's a link to Jazelle, the (90% of) Java bytecode native to CPU trick

Excellent! WeirdX might run in realtime... (-: