Slashdot Mirror
A Brief History of Chip Hype and Flops
On CNet.com, Brooke Crowthers has a review of some flops in the chip-making world — from IBM, Intel, and AMD — and the hype that surrounded them, which is arguably as interesting as the chips' failures. "First, I have to revisit Intel's Itanium. Simply because it's still around and still missing production target dates. The hype: 'This design philosophy will one day replace RISC and CISC. It is a gateway into the 64-bit future.' ... The reality: Yes, Itanium is still warm, still breathing in the rarefied very-high-end server market — where it does have a limited role. But... it certainly hasn't remade the computer industry."
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap. ...
Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat
Dont make a better sig, you insensitive clod!
Intel Itanium never took off / didn't replace Xeon
The PowerPC architecture was dumped by Apple and failed to challenge Intel in the PC market in a big way.
AMD is consistently beaten by Intel in the mobile marketplace.
I don't know enough about the architectures to say which one is better (x86-64 vs IA-64) but backwards compatibility with x86 is a big win for x86-64.
I don't think so. x86-64 is fully backwards-compatible with x86. Itanium is not.
Wanna guess why they're not that popular?
How could the writer blatantly ignore the 486sx, the winchip, or the original (cacheless) Celeron??
Although, I've always contended that TI's 486dlc (which fit in a 386 socket) was one of the worst chips I ever used, it overheated, lacked full 486 compatibility, and froze up the system with random halts whenever I needed to get something done on it!
Well, I guess having better compilers for IA64 would helped greatly, considering that the architecture's performance is critically depending upon the compiler detecting instructions that are not interdependant.
Back in 1999 the ACE Consortium had Compaq, Microsoft, MIPS Computer Systems, DEC, SCO, and a a bunch of others.
The plan was to launch a MIPS based open architecture system running Windows NT or Unix. Back then the MIPS CEO said MIPS would become "the most pervasive architecture in the world". The whole thing fell apart as Compaq defected, MIPS run out of cash and got bought by SGI. Dec obviously moved to supporting Alpha instead. Microsoft shipped NT for MIPS, Alpha and PPC for another few released and then gave up the ghost.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I don't think so. x86-64 is fully backwards-compatible with x86. Itanium is not.
Wanna guess why they're not that popular?
You don't know the architecture? The first Itaniums had hardware x86 processors. The only reason they don't now, is that it was found to be faster to emulate the x86 than run it with a diminished hardware.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
The biggest advantage of AMD x64 over Itanium is the ability to run x86 32-bit code natively without any performance penalty.
The comparison is not just about better technology. Think of the trillions of lines of x86 32-bit code that has been written.
Would you render all this code unusable just because you want to move to a better architecture.
A short paragraph about Itanium (or, as the Register likes to call it, Itanic)? A few brief paragraphs about PowerPC? A few brief paragraphs about Puma?
Come on. There's a lot more scope for this sort of article. What about Rock, promised three years ago, with tape out two years ago, and yet we're still waiting for systems? What about the iAPX 432?
You've got the basis for a good article, but dear $DEITY, flesh it out! There's more meat on Kate Moss than on this article!
The Itanium is not superior at all.
Even before the AMD64, the Itanium was only good at mainly contrived FPU benchmarks. It was dismal in integer performance.
When you didn't care about x86 compatibility and wanted to spend lots of money for the usual reasons, it was better to go with IBM's offerings like POWER (which is still a decent contender in performance).
Intel couldn't offer you much else other than the CPU. They had to rely on HP, who just left their Tandem and VMS stuff to rot. Yes there were other big names pretending to do Itanium servers, but in practice it was HP.
The Itanic was an EPIC failure.
AC how could you have forgotten to mention the socket 4 Pentiums, or the K5 on AMD's side, the Transmetta Caruso, the Cyrix MII, or the slot 1 PIII 1.13?? From the extraordinary cost alone, you could have also called most of the intel overdrives a flop too.
although the winchip (shudders) I hope no one was unlucky enough to have to depend on a box with one of those running it
Reading through the article, it seems that other than AMD's Puma, most of these failures have one thing in common: they are not backward compatible with the chips they replace.
People are loathe to buy a new computer and all-new versions of software to run on it. Look at the 64-bit Windows architectures. How many folks are running 32-bit software on those?
Bottom line is that the software IS the computer and the chips ultimately are sexy only to EE's and gearheads.
AMD's 4x4 Quad-FX dual socket motherboards were also a flop. AMD's line of FX-7x series processors for these boards were a limited run. Now considered collectors items. If you can find them! Intel's Skulltrail, was much hyped, but it is now very much quietly pensioned off by Intel, although it a few more boards sold than 4x4.
Anyway where are the Mandatory FLOP puns I was expecting? (Considering this is a brilliant set-up by article poster)
(Mandatory wiki linkage: http://en.wikipedia.org/wiki/AMD_Quad_FX_platform)
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Well, I guess having better compilers for IA64 would helped greatly, considering that the architecture's performance is critically depending upon the compiler detecting instructions that are not interdependant.
That's pretty much right on the head there. Intel made the IA64 under the assumption "make a better chip, and the compiler will follow", unfortunately, they didn't realize how much inertia was behind x86. AMD exploited it and POOF, Itanium goes down in flames. :(
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
I just got out of my bed 2 minutes ago and by vaguely reading the word FLOP I thought about Floating point Operations Per Second...
Here be signatures
If AMD hadn't rushed with their 64 bit version of the x86, about now, Itanium would be getting popular and hence cheap. Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat ...
Perhaps, but how superior is that superior technology?
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
It was a neat idea, but advantages in manufacturing technology favored CPUs with more complicated front ends. The Itanium advantage never materialized on the desktop, so had this "superior" technology taken off we'd might have had faster computers at the cost of making our software run on this bling architecture.
Making big ISA changes for a mere speed boost is not worth it, and it's not certain you'd get even that as the Itanium does not always outperform the x86.
It turns out that the cost of a translation layer has become irrelevant as chips have gotten faster. It's not even considered a pipeline stage any more, not really. That is, it is no longer a bottleneck to have to have a layer of essentially combinational logic to convert a CISC instruction set into a mostly RISC / VLIW one internally. This savings grace is also why the fairly badly bloated intel instruction set no longer has any real impact on the performance they can squeeze out of the chips.
-Matt
TI's 486dlc (which fit in a 386 socket) was one of the worst chips I ever used, it overheated, lacked full 486 compatibility.
What app did you run that needed full 486 compatibility? Being able to plug a 486 into an old 386 mobo seems like a neat idea, and any software that ran on that 386 would of course run on the nerfed 486 right?
Too bad about the overheating though.
That definitely belongs in there. Sorry, Linus.
Stop the brainwash
AMD still won't openly admit this but there's a timing problem with all or at least most of their Athlon X2s where the cores' clocls get out of sync with each other. That causes major graphics problems in games that rely on it like Runescape and Halo 2. It also causes really strange side effects where basically the computer gets slower and less responsive over time until you restart it. I never knew what was wrong with my computer and assumed it was inefficient software but then I heard about this and OMFG was I mad! They even have a program on their website that fixes some mysterious, unnamed problem with X2s and graphics and as soon as I installed it, it worked and yet they still won't admit to the public how badly they screwed up! I didn't even see the story on slashdot but it's all over the web.
Also they should add to the list of major screw ups, the entire naming system used by Intel. Centrino sounds like Celeron and they brought back Pentiums but the Pentium D's and Pentium Dual Cores are different and then there was Core Duo and Core 2 Duo which are easy to overlook. Ugh, it's just stupid!
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
Actually you could see that Itanium was in deep trouble when it launched at a lower clock rate than x86. The whole idea behind EPIC "explicitly parallel instruction computing" was that you move instruction scheduling to the compiler, and that allows you to essentially out-RISC RISC, i.e. build a dumber chip that can be clocked faster. I think you're right about technology too. Back in the CISC vs RISC days an R4000 for example could be clocked faster than a 486 due to its ultra streamlined pipeline - MIPS originally meant "Microprocessor without Interlocked Pipeline Stages". Itaniums for a variety of reasons ended up clocked slower than x86. Partly I think too much stuff got added to the architecture, and partly I think x86 chips were already very close to process limit for frequency, so a simpler architecture wouldn't run any faster.
I sort of wonder if .Net might have been part of the sketchy Itanium strategy too. The big thing about .Net is that it is a VM that is designed to be JITted rather than interpreted. Part of EPIC was that chips would be binary compatible, at least for user code, but that old binaries would not necessarily run optimally. It's easy to see why - a binary compiled for an old chip with n functional units would have fewer instructions scheduled to run in parallel than one compiled for a new one with 2n units assuming the scheduling was done at compile time.
Of course with .Net the applications are compiled for a VM and then JITted. If you had a new chip, the .Net JITter could detect this and schedule optimally.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Still one of the best register 'articles' http://www.theregister.co.uk/2006/02/17/itanic_oracle_idc/
> Would you render all this code unusable just because
> you want to move to a better architecture.
Yeah, and I'd put Debian on that machine.
Do you think that the i7's new socket will prove to be a barrier to upgrade?
I recently had to get a new motherboard, and the combined cost premium of an i7, taken over the processor and motherboard, was far too high to even consider. I could have bought three computers for it!
All intents and purposes. Not intensive purposes.
The program I needed the full compatibility for was a compiler iirc...
it was a cool idea except the original mobo I had for it didn't work right, so I bought another one which was compatible with it, and that got it working...sort of...
it was annoying because they didn't make 386 heatsinks for the most part, and a 486 heatsink wouldn't fit and clear all the components on the motherboard without modification... ..I think it was a 486sl that was integrated on an IBM blue lightning motherboard....
It was more than a nerfed 486 though, it was more of a badly copied 386 with _some_ 486 instructions, as sometimes it failed to even run correct 386 assembler correctly...
the best day I had was when I replaced it with a
speaking of flops, I really, really enjoyed the heck outa my blue lightning, the (rather tiny looking) 486sl onboard was clocked at 75mhz, and I found that could even run circles around the 75mhz Pentium that I later got... and yes, I did send my 75mhz pentium back to intel during the recall, I kinda wished I kept it for fun though.
Do you think that the i7's new socket will prove to be a barrier to upgrade?
Nah. CPU only upgrades are actually pretty uncommon. New CPUs often require new FSB speeds and lower voltages so you'll end up having to change the mobo anyway.
:-)
Don't buy a mobo thinking you get to update to a much faster CPU later on - unless you buy a slow ass Celeron today and snag a cheap Extreme Edition of eBay in a few years (and even then you might be better off with the slow ass Celeron of the future
I worked on Itanium/Merced. Keep in mind I was mid-level (not high enough to see the good political fights first hand, only getting the after effects). Below is my opinion from what information I saw or collected at the time. Take it or leave it as you will.
Itanium (or I-Tanic) was supposed to be the P7, back when Intel still used P#s for chips. That Pentium 4 was never supposed to exist. Basically, Itanium was so bad, the Portland design teams came in a ate the Santa Clara team's lunch.
The biggest problem for I-Tanic was management, on many levels. ... finally. He lasted about 3 months, until his wife (supposedly) gave him the "me or CPU design" ultimatum. He then moved up to start the Intel DuPont site (which was supposed to be as big as the Portland cite). That didn't work out so well for him.
1) No good top guy
The main and original project lead was more focused on marketing and "the platform" than actually making the chip. So, there was no top leadership at the CPU design level. This allowed the "lieutenants" to squabble among themselves (more later).
They finally got a good guy in (who's name I hate to say I forget. It was a long time ago). I believe he had done Kalamath. The project was in a never-ending re-design spin at this point. When he was there you knew there was a Captain of the ship. You weren't 100% sure he was sailing in the right direction, but felt things were moving
His hand-picked successor lasted about 1 week before "family reasons" caused his resignation. I assume he looked at the state of the now 2 year delayed chip and ran.
2) Dot.com boom & Silicon Valley
The "lieutenants" didn't give a rat's ass about the project. It was mostly a "pump and dump". Being the Dot.com boom and in Silicon Valley, their main concerns were taking over ownership of a "cluster" (State sized chuck of the chip), getting the ownership on their resume, finding a new non-Intel job, and splitting.
So, every part of the chip got a new guy every 9-12 months who blamed everything on the previous owner, forced a re-design on the part (which may have been needed, but seemed to be needed an awful lot), and then left (forcing the cycle to repeat).
3) Constant Re-Design
Look I know re-design is part of engineering. But perpetual hamster-wheel-like re-design is not good. Nothing got finished!!!! No specification was stable (let alone the written specs; I mean verbal specs). You ask people (and this was years, years into the project) about your interface to their part of the chip and they wouldn't have coded it up yet. So, who knows what the Hell the timing issues would be. "Can I move a flip-flop to your unit?" "Go fish. I haven't coded that."
Let us also remember that back then (I doubt they still do this) you coded in iHDL (not VHDL or Verilog) using macros for AND & OR gates. So, you're basically doing stencil EE work using a programming language. You want an IF-THEN construct, well break out the K-maps because you'll need them.
4) Moral
After the chip had slipped 2+years, no one wanted to work on this thing anymore. They had to freeze internal transfers. You had to threaten to quit to get out. "I am leaving Itanium. Are you going to make me leave Intel to do it?"
The first Itaniums were pretty much a dismal failure...
They ran at around 800mhz, so clocked lower than x86 systems of the time which were around 1.4ghz if i remember (and the mhz myth still very much alive, with intel fuelling it using the p4)... Their x86 support was roughly the speed of a p90 and therefore of little use beyond running one or two small legacy apps.
In terms of outright performance they were behind Alpha and Power at the time, so much for this new architecture. And when it came to price and power consumption they were behind everyone else.
When Itanium2 came around it performed a lot better, still guzzled power, and they realised that software emulation of x86 was faster than the hardware support, other than that the chips were still too expensive for what they were.
Now, Itanium is pretty much relegated to the high end niche that Alpha occupied before it was canned.
Itanium suffered from end users being locked in to proprietary binary only software - which only the original vendor could port... Some were unwilling, some didn't see the business case, some demanded that HP/Intel fund the porting, only they couldn't fund everything, so Itanium is left with a very limited set of apps...
OSS support was better, but it suffered from the high cost and rarity of the hardware, in that hobbyists had little chance of getting hold of the hardware to play with.
Personally i think HP/Intel would have been better off putting the effort into continued development of Alpha... It already had a software and user base, it already had x86 emulation which performed reasonably well, and it had a legacy behind it of old hardware that was cheaply available to OSS developers. Even today, Alpha versions of Linux seem far more active than the IA64 versions... Plus any customers already using Alpha would not have needed to migrate (and many of them migrated to Sun or IBM).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Very little code is written in x86 assembly, the vast majority is written in higher level languages and then compiled or interpreted... When you have the source code, porting it to IA64 is relatively easy. Look at Linux, it runs on a variety of architectures, as do a huge number of applications. Many of the original authors of those apps would never have considered they might be running on IA64, Alpha, Arm, Mips or Sparc someday...
The problem is software being delivered as binaries. Binary software distribution is holding back progress, making it necessary to continue supporting old kludgy architectures instead of making a clean break to something new and modern.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I'd not hesitate, assuming I had a way to virtualize the code (16 bit, 32 bit, and amd64 bit) in such a way a user wouldn't care that it was running under a hypervisor.
Why stop at flops ?
Itanium easily qualifies itself as a mega-flop !
IA64 wasn't so much about clock rate, as theoretical instructions per clock...
Rather than having multiple cores, the idea was a sort of SIMD throughout the processor... But relying on the compiler to generate optimal code...
Assuming you have optimal code, an Itanium should be able to get a lot more work done in a single clock cycle than any x86 chip.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Boohoo! AMD is being so *mean*! They're *competing* with us! It's just not *fair!
Compilers that one wasn't expected to PAY FOR? Yeah, I tried to get a compiler, way back when. I can't remember the price - but it was much more than I could afford to pay, just to play with it. And, I'm sure that some businesses that needed it pretty badly balked at the price tag.
Itanium did one thing well...it killed a lot of other chips. The threat of it killed MIPS post-R12K plans - and the Alpha, and PA-RISC architectures as well.
I remember how SGI kept the team around that was going to work on their next-gen processor while they were negotiating with Intel. These guys had no work - they just played a lot of foosball in good old Building 40 (yeah, Google, you weren't nearly cool enough to build that campus). Then once SGI had sold it's soul they axed the project (and the team). That was a sad day...
"Where quality is like a dead stinking rat - you just can't miss it."
Why is that even in there? It "only" powers all three current games consoles and IBMs Power Systems server lines (i and p).
If that's a failure, I hope IBM has many more failures in the future.
Commenters seem very young today. Noone remembers the failures of Intel's and Motorola first attemps at addressing RISC designs? Both the Motorola 88000 and the Intel i860 were great designs that failed.
no the main problem is proprietary software. the amd64 could establish itself because it supported the existing proprietary software. it would be interesting to know what percentage of x86-64 systems are still running 32-bit software exclusively. i'd estimate about 90%. the reason? broken or missing flash for x86-64, broken or missing windows, broken or missing microsoft office, broken or missing photoshop, broken or missing autocad etc.
free software has the advantage that, if you aren't embedding assembler, the entire free software stack should work for a new architecture after adding a new target to gcc and a couple of assembly routines to the kernel code. this is the reason why i can change seamlessly from hppa over sparc32 over ppc over x86 over x86-64 over alpha over mips for all my daily needs without having to know which architecture i'm using.
Itanium did one thing well...it killed a lot of other chips. The threat of it killed MIPS post-R12K plans - and the Alpha, and PA-RISC architectures as well.
Here's an idea: Let's throw out years of proven engineering in favor of an architecture that has yet hit silicon. That way we can fire our engineers and pocket the change. What could possibly go wrong?
I feel a big bonus is coming up, and just to be safe let's add a parachute too.
It probably won't be popular to say around here, but Transmeta was a fairly spectacular failure, particularly the Crusoe line.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Did anybody else read that as A Brief History of Flip Flops?
And what sort of thorough article would this be in missing out Sun Microsystems' MAJC chip from the 1990s ?
Promised to accelerate JAVA instructions, the chip was a multithreading multicore design (can you say Niagara?) but Sun couldn't get it to market fast enough and advances in general purpose CPUs left it for dead.
Sadly MAJC only made it into two models of Suns own-brand graphics cards before it was dropped, though it's design principles live on in Niagara and Rock.
The original Itanium was shit. That was why it went down in flames. It was worse than the end-lined processors it was meant to replace.
It's probably not too important in the large scale of things, but the Alpha worked fine in workstations, something Itanium doesn't seem to be suitable for. Having workstations in the same architecture is likely one of the reasons Linux/alpha is doing well, and I it might be convenient for the other developers as well.
Here's an idea: Let's throw out years of proven engineering in favor of an architecture that has yet hit silicon. That way we can fire our engineers and pocket the change. What could possibly go wrong?
You must have been there...Belluzzobub, is that you?
"Where quality is like a dead stinking rat - you just can't miss it."
It didn't help that part of the advantage of IA-64 was that it let programmers write their own branch prediction. Which they didn't want to do.
We probably have as many PowerPC chips in our homes than x86 these days. How many people own two of the following game consoles but only have 1 PC in their home? GameCube, Wii, xbox360, PS3?
It's true that Apple killed PowerPC on the desktop and it will probably never come back. And ARM and Atom will fight over the mobile and netbook market.
The article doesn't mention POWER, so I think we can technically assume it only considers PowerPC a failure (which is wrong of course). Even though POWER and PowerPC are almost the same thing, they aren't the same thing. But governments and corporations are still ordering iSeries systems, and IBM is still making plenty of money off them. (although I bet they sell less than 100 of them a year).
“Common sense is not so common.” — Voltaire
Core i7 is enthusiast high end though.
Core i5 will be out soon, and yes, it has a new socket, but the motherboards will be cheaper.
I find it odd that when CPUs are reviewed against each other, the motherboard cost is very rarely factored in, so they'll pit the Intel CPU against the AMD CPU of the same price, and then declare the Intel the winner, without factoring in the $300 Intel motherboard price (for the i7) when the AMD is on a $100 board.
Still, AMD aren't executing very well, and haven't for a couple of years now. Core 2 knocked them back a lot. AMD could have spent some resources last year on developing a 45nm single-core CPU with built-in graphics and chipset and they could be winning the netbook war, but no, the company has no vision. Just roadmaps.
Oh, and the article sucked. PowerPC failed? What about Cell? 360? Wii? POWER servers? Hundreds of millions of embedded devices like set top boxes? It only failed as a viable desktop CPU because it didn't get the investment that x86 has over the past ten years.
I've had mixed luck with CPU-only upgrades.
I've got a 440BX Asus P2B machine that went from a PII-266 in 1998, to a Celeron 500 in about 2000, and a PIII-450 in about 2003. I've also got a i845PE Gigabyte GA-8PE667 Ultra which went from a Celeron 1.7GHz in 2002 to a P4 2.53GHz in 2008. On the other hand, I've had two machines that I've never upgraded the CPU on because the upgrade path disappeared, or simply wasn't economic.
Just because a chip isn't available in the PC at your local Best Buy does not make it a failure.
From zSeries, iSeries, and pSeries, machines which make up a large number of server and midrange hardware sold to variations of the theme in some of today's popular gaming platforms I think the PowerPc as an architecture does just fine. G5 is alive.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
How would you address the issue of software distribution to home users, who may have neither the time or patience to wait for the compilation process? I'll assume for now that the compiling would be added as part of the installation process.
"Pro" or "power" users that pay for big apps may appreciate the flexibility, but home users, as we all know, want it to "just work."
Government's idea of a balanced budget: take money from the right pocket to balance...oh who am I kidding?
HP/Intel would have done better, technically, to work on Alpha, but they couldn't sufficiently dominate the market for their tastes in that case. half the point was to have something that they controlled, and Alpha, while technically great, was already too widespread for that.
which, really, is the most important response to the original parent's point. what was AMD supposed to do, sit around while Intel dictated what the terms of the next stage of the market would be? what gives Intel some inherent right to that sort of dominance? AMD did exactly the right thing, from a business perspective: they saw what they believed to be a strategic mistake that left a market hole open, and produced a product to fill it. turns out they were right.
turns out it was the right thing to do technically, too. when Itanium hype was at its peak, i remember lots of actual engineers i knew (and even some subset of the tech press) pointing out that EPIC was really just tweaked VLIW, and that had been tried and failed a few times. amd64 has consistently outperformed IA64.
even the quote in the summary is misleading. yes, IA64 is still plodding along in the high-end server market, but it's even an also-ran there. POWER and amd64, in particular, continue to trounce it, both for your normal "server" market and for the really high end scientific cluster stuff (it's got, what, one spot on the top500 list?). it's a pretty substantial failure, really all around.
i speak for myself and those who like what i say.
Intel's i960 was a nice chip for embedded development. One of its nicest features was the large number of individual interrupt vectors which is really useful when you want to hang off a large number of I/O devices off it. Compare that to the x86 where they have to share interrupt vectors. For some reason however Intel decided to drop the whole line and move to ARM architecture instead.
However the second one is a what might of been. During the 80's we did a lot of development using INMOS T2 and T8 transputers. They were a joy to use and made parallel programming at software and hardware level so easy and natural. The next iteration was to be the T9000. It promised a lot, much improved execution speed, a faster and more flexible processor interconnects. It looked so good we had even sold our next project based on it. However when we started getting the first samples there was obviously something wrong. Bits of the chip did not work or would fail. At the end of the day it looked like INMOS just could not deliver. The T9000 never became a reality but anyone who used transputers how good they were and and could if it had been done right with enough finance could of fundamentally changed the computer industry.
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies
Home users are "end users". No matter how the software is distributed, end users don't have to compile everything. It's the distributors' job to release pre-compiled binaries for all targeted architectures, and Open Source makes porting to a new architecture possible and easier for the distributors.
You are worrying about all home users going the Gentoo way, which is not happening.
Colorless green Cthulhu waits dreaming furiously.
Alpha was starting to hit clock speed limits, or at least, DEC wasn't able to increase them (shock amazement.) PA-RISC = garbage, at least compared to the modern competition. MIPS is still around as an embedded core - it wasn't keeping up with x86 either, which is why SGI tried to make x86 machines. All of these processors have basically no reason to exist whatsoever now that Hammer is around, with superior TDP and unparalleled ease of SMP. Then again, the same is true of iTanic :)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I was at SGI (mtn view) during that time, also. we called the intel chip and system 'IBT' (intel box thing) ;)
it killed MIPS and was helping to kill IRIX, too (irix has little relevance outside of the mips cpu).
it was truly the beginning of the end for SGI. I watched as SGI disappeared before my eyes. very sad.
SGI was dying anyway but this chip really did put the nail on the coffin for SGI.
--
"It is now safe to switch off your computer."
Now, Itanium is pretty much relegated to the high end niche that Alpha occupied before it was canned.
All I know about iTanic sales is that the only customer I know of was unwilling. Yuba College in Marysville used a 4-way alphaserver to handle the system on which their student information is kept. The upgrade path for that software after the death of the Alpha was to go to iTanic. So they now have an 8-way iTanic2 server to do what? Some database shit, basically. Run HP-SUX. I used some of the extra horsepower to implement ipsec to the windows clients for them, but it's still a massive overkill and a massive waste of tax and tuition money. But they had no choice.
Given just how fucking dismal iTanic sales numbers have been, I wonder how many of those sales are customers given no choice by their vendor and forced to install such a system.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Google, you weren't nearly cool enough to build that campus
little known fact: SGI was in its last days when it built the 'charleston buildings' (ones very close to the shoreline park). I was on the site I/S team that was doing the building planning, network planning and whole add/move/change team.
what struck me as 'interesting' was that we designed those 3 floor buildings FOR US but intended *eventually* to be leased out to multiple different non-related companies. that makes designing your network infra. a bit more interesting since you have to design in security (physical) so that you can break 1 building into 3 or more, later on, for even competing occupants.
its almost like building a house knowing you'll only live there a year and then rent it out. that was our mode for the new SGI buildings (back in 1998 timeframe).
google basically just inherited SGI's buildings. probably for pennies on the dollar, no doubt, too. but some of them were meant for multiple companies. kind of funny that ONE company bought our *multiple* buildings rather than multiple companies living in a *single* building.
--
"It is now safe to switch off your computer."
How could the writer blatantly ignore the 486sx, the winchip, or the original (cacheless) Celeron??
The 486SX was hardly a flop, they _very_ well.
... to be precise, by intel's bankroll and investment in process.
Power PC and Alpha were outcompeted by the fundamentally inferior x86 family not because of flaws in their designs, but because intel spent more on improving their process than anyone else.
Both the Power PC and Pentium turned into furnaces, the Pentium 4 and G5 were both following the "megahertz myth" into long pipelines to let the clock speed ramp up. Neither got the clock speeds they were hoping for. Both were too hot for mobile processors. In both cases the solution was going to be shorter pipelines, slower but more clock-efficient cores, and faster busses. The Freescale e700 was torpedoed when Apple went with Intel's Core Duo... because Intel had the resources to get their respin of the PIII out quicker than Freescale could get their respin of the G4 online.
So now we're still using hacks upon hack on the truly horrible x86 architecture.
Well, it could have been worse. It could have been SPARC.
lack of chip-level backwards compatibility is an issue, but not a deal breaker. that can be reasonably managed, and has in plenty of cases you can point to without trying too hard. these examples failed to deliver on their promise for entirely unrelated reasons.
look at the examples given, and you'll see compatibility wasn't really a factor for the first two, either.
Itanic had explicit backwards compatibility, at first in hardware (through the use of a separate embedded core), then in software. that compatibility failed to save it from other market forces.
i'm not sure what you think backward compatibility did to PowerPC. it wasn't compatible with "the chip it replaced" (the Motorola 68k series), sure, but Apple managed that transition quite well, including backwards compatibility higher up the stack (Apple, you'll note, has a history of handling these potentially fatal cut-overs very well). it wasn't compatible with the x86, but it was never designed to replace that; rather, it competes with it.
i speak for myself and those who like what i say.
Exactly you could have the fastest computer in the world but if it doesn't run the software that the people want the people wont buy it. The Companies to make the software that people wont wont make software for that hardware if no one has it.
It is kinda of a catch 22. The only way out is to do minor upgrades Removing and old feature rarely used and adding a new feature that will not break much. And software companies will slowly add the new feature that take use of the new hardware features but the big switch off the old x86 to something newer and better will not happen anytime soon.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
It's a *little* harder than that... you have to worry about endianness, alignment issues, word sizes, etc. and these do affect higher level languages. Compiling for new architectures - even on code that's been compiled on other architectures before (if it hasn't, chances are it'll need modification) - is more than a simple recompile.
y'know, i'm embarrassed to say i never made that connection before. that's a really interesting line of thought.
still, MIPS was having lots of other problems, including a rather big split in focus between high-end servers and embedded systems, two markets with very different design constraints; schizophrenia probably did them in. that and getting in bed with WIntel.
PA-RISC was a pretty obvious knock-off, but no sympathy for HP making their own stupid decisions. the most direct and disappointing casualty was likely Alpha, who really lacked anyone who cared for it at all after DEC got eaten.
i speak for myself and those who like what i say.
transmeta, anyone? also, the ibm servers have all binaries running in a 128 bit vm... since the dinosaurs walked the earth. they have provided one of the most nice upgrade path for application ever seen, and yet to be matched.
It's not just patience and time. Compilation creates uncertainty in your code, because your compilation environment may be changed by utilities installed, or removed, for other reasons. A lot of software is _not_ gracefully integrated or bundled for multi-application environments. If it were, DLL-hell wouldn't be such a problem for Windows users, and the CPAN dependency hell of poorly written apps with the same filenames wouldn't fracture Perl tool chains.
If you make a better chip, the users will follow. But if you make a chip that is marginally better than x86, slower than most of its RISC competitors, and more expensive than anything with similar performance, no one will follow. This is especially true when you release an incredibly power-hungry server chip just as the market is starting to care about performance per Watt.
I am TheRaven on Soylent News
Lots of printers use PowerPC in the low-clock versions. Basically PowerPC was a success everywhere it didn't have to run X86 applications. The PowerPC/X86 thing is a bit like the gas/Diesel engine thing; US consumers think Diesel is the inferior technology because their auto industry fixated on spark ignition early on, and then all the technical, marketing and political decisions were taken with spark ignition in mind. But in the world as a whole, everything from generators to bulk carriers runs on Diesel, it's just that Joe Public is rarely aware of it.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
It's easy to see why - a binary compiled for an old chip with n functional units would have fewer instructions scheduled to run in parallel than one compiled for a new one with 2n units assuming the scheduling was done at compile time.
You are confusing EPIC with VLIW. This is, indeed, the limitation of VLIW. EPIC improves on this by grouping together any instructions that can execute in parallel into bundles. The issuer loads these in groups of three and starts as many as can be run on the available hardware.
The really sad thing about Itanium was that they could have made it massively faster by tweaking the instruction set to allow the register set to be partitioned and providing a dynamic version of SMT.
I am TheRaven on Soylent News
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
One would think they learnt this particular lesson from the i860, but apparently not. Perhaps they believed too much in the ability of compilers to predict what the code would do at run-time. This was bad enough at the time the i860 was built, but far worse in the age of the Itanium, given the insane ratio of CPU throughput to memory bandwidth.
The one oddball platform in common use is Win64, where sizeof(long) sizeof(void*). A huge amount of code assumes that you can losslessly cast a pointer to a long, and on Win64 this discards the top 32 bits. Apparently someone at Microsoft thought that doing the opposite of what programmers expect would help backwards compatibility.
I am TheRaven on Soylent News
Why not. NASA did it.
Chose a vaporware launch system over a working prototype model. So now BOTH are dead and we are stepping backwards to the old Apollo and Saturn-5 launch model.
It happens a LOT. Bad decisions made for dumb reasons.
Do not look at laser with remaining good eye.
What app did you run that needed full 486 compatibility?
OpenBSD just dropped support for i386. The 486 didn't add much, but it did provide atomic operations and a few other things. It's not difficult to imagine software floating around that required a 486 for the instruction set, rather than just for speed. If you're producing something that will be too slow on a 386 anyway, there's no reason not to use 486 extensions.
I am TheRaven on Soylent News
You just distribute both, the way linux and bsd are currently distributed...
If you have source available, then interested parties (vendors of new architectures, pro/power users etc).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If anything, this article is to long and doesn't have enough lolcats and baseless rumors that author thought he heard someone say on the bus home.
The internet, mediocrity spread around the world.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I worked on Itanium/Merced. Keep in mind I was mid-level (not high enough to see the good political fights first hand, only getting the after effects).
I have to believe that there were forces inside Intel that wanted Itanium to fail. It's hard for me to believe that if the project was this important they wouldn't have pulled some Top Guy that Gets Things Done on the project.
After the chip had slipped 2+years, no one wanted to work on this thing anymore.
Back in 2000 or 2001 I went to JavaOne and went to a talk by some Intel engineers about how cool Itanium was going to be. They had to be he least enthused about any project I'd ever seen. The paper features sounded pretty cool, but you'd talk to them and you could just tell they thought the thing was a total piece of garbage. They didn't say it outright of course, but the sounds of their voices and the expressions on their faces told a very different story.
AccountKiller
Seriously, *YUBA* College has that? What're CSUS and UCD running? Because I can't imagine they made the mistake of migrating to IA64 for freaking student info, and I'm 98 percent sure the JC's are all x86 for that backend stuff as well.
On the contrary, competitors can and do reverse engineer binaries, it just becomes more time consuming, but also harder to prove. If someone rips off the source your published and it shows up unchanged in their product its very easy to prove in court.
Having sourcecode would benefit users and the original vendor, and may actually hamper competitors because they have to be careful not to copy existing code.
Open source has often innovated, these days it is stuck copying because there is often no alternative - people are locked in to the existing applications and cloning them is the only way to achieve a user base. And you could argue that commercial software hasn't really innovated in the last few years either.
When you talk about open source copying commercial software, consider that...
The first web browsers were open source, commercial browsers copied.
Many of the other protocols we take for granted were developed as open source.
Bittorrent started out as an open source program.
And much more...
Commercial software need not be closed source, BSDi was distributed with sourcecode, even MS make source available to some of their products, tho on rather inflexible terms...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Was so far ahead of its time, we still are not ready for it. Tho finally silicon has advanced far enough to make the architecture work.
( note my nick.. you can tell i was a fan :) )
---- Booth was a patriot ----
You did not use Transmeta-based notebook, did you? Those sucked bollocks!
The answer is emulation and a much better architecture. Emulation can run applications at 50% of the host speed in most cases now. For tight, mathematically-intensive loops, it's more than this, for things containing a lot of branches it tends to be lower.
When I replaced my 1.5GHz PowerPC Mac with a 2.16GHz Core 2 Duo, I didn't notice the speed difference on legacy code. I forgot to replace VLC with an Intel build for a while (they do universal binaries now, but they didn't for a while), and even the PowerPC version in the emulator could play H.264, although the CPU load spiked to around 80% on both cores. Switching to the native version dropped this down to around 20%.
When people talk about backwards compatibility, what they really want is two things:
If you can only run DOS software at the speed equivalent to a 200MHz Pentium, do you think anyone will care? It was most likely written for a 16MHz 386, so you're still running it fast enough. I can play all of the old DOS games I own, the ones that used to make my machine struggle when they were new, in DOSBox on a PowerPC machine, and they're fast enough.
Backwards compatibility isn't nearly as much of a problem as persuading developers to support your architecture for new programs. Any new chip can emulate a three to six year old chip from another architecture at a reasonable speed.
I am TheRaven on Soylent News
the "Itanium" approach that was supposed to be so terrific - until it turned out that the wished-for compilers were basically impossible to write.
(http://www.informit.com/articles/article.aspx?p=1193856)
When Don Knuth says your chip is impossible to program for, you're in deep, deep trouble.
Itanic had explicit backwards compatibility, at first in hardware (through the use of a separate embedded core)
Uh, what? That's not having it. That's having the compatibility next to it.
then in software. that compatibility failed to save it from other market forces.
That compatibility was pathetic - it executed x86 code slower than pretty much any x86 on the market at the time.
i'm not sure what you think backward compatibility did to PowerPC. it wasn't compatible with "the chip it replaced" (the Motorola 68k series)
PowerPC was explicitly designed to make 68k emulation easier.
but Apple managed that transition quite well, including backwards compatibility higher up the stack (Apple, you'll note, has a history of handling these potentially fatal cut-overs very well).
You will note that anyone who bought a G5 got totally boned by the switch to x86.
it wasn't compatible with the x86, but it was never designed to replace that; rather, it competes with it.
Yes, and when you compete successfully, you replace.
Each of these processors was killed by a lack of a reason to live. iTanium has no reason to exist, Hammer blows it out of the water whether you measure by price or power consumption. PowerPC got sadly outdistanced by PC processors as well (especially when you compare prices.) It had nothing to do with backwards compatibility either way. On the other hand, x86_64's success is definitely due to x86 compatibility.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I dunno about the idea that All of the Intel Overdrives were flops. The Pentium II Overdrive for the Pentium Pro boards was a neat chip. Kinda like the best of the PII and PII Xeon all in one. PII core and full-speed cache on board. It was limited by its circumstances, of course -- 440FX mobos only went up to 60MHz FSB, but put one on a slocket in a 440BX mobo, and the Pentium II Overdrive was a great, if pricey, cpu.
Well, the idea was more to take a lot of things that were typically done in hardware (such as trying to exploit parallel execution as much as possible) and push those tasks into the compiler. An interesting idea that never really sat well with me though.
Most half-decent Free Software developers test their code on x86/BSD and SPARC64/Solaris.
What? Maybe if it's a server application. Solaris on the desktop has never gained much traction and every Unix shop I've ever known that had SPARCstations on the desktop ditched them en masse as soon as PCs got good enough.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I thought the death of SGI was pretty much assured when they told a bunch of their graphics chip designers that there was no market for a consumer-grade 3D chip, and watched them leave to form nVidia.
I am TheRaven on Soylent News
Socket 4 pentiums sold just fine. So did the K5, which was probably the best PC CPU of its day. Transmeta's Crusoe did bomb pretty hard. Cyrix MII is a fair assessment. Intel overdrives sold fine, the cost is not and never has been a measure of a product's success, but market penetration and profit. By that token you are at about a 50% hit rate, which is pretty good for automatic weapons or baseball but totally shitty for a slashdot comment. Your comment is a massive failure.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Stop me laughing. I worked at HP at the time. Two years into the project we showed Intel a working Merced prototype - 1/4 the power and twice the speed of what Intel eventually released. They didn't want it. Stated reason? "We'll never get that to run on our process". This was because no one at Intel was allowed to know the details of a fab-line from end to end in case they left the company and took valuable information with them. We sent our engineers in to one of their fabs during this debacle and they pissed themselves laughing.
The problem is software being delivered as binaries. Binary software distribution is holding back progress, making it necessary to continue supporting old kludgy architectures instead of making a clean break to something new and modern.
Depends what you mean by 'delivered'. If it's to fellow IT professionals, then they're probably going to want the source, and will hopefully know what to do with it. The only problem is, you might not want to give/sell it to them. Not everything is FOSS, and most of the big commercially used server apps are definately not, (OK, outside Apache, I'm thinking ERP).
As for end users, wll, most of them can't even install applications, let alone compile something...
Your comment is stupid, but I'm going to reply to it anyway. I have no idea what CSUS and UCD are running, but Yuba was offered no choice about their upgrade path - it was either completely change student records applications or buy the 8-way iTanic. Which yes, is going mostly underutilized given that the 4-way Alpha was overkill. And given that I personally set up the HP-UX to Windows ipsec integration for the system (the HP docs on IPSEC are backwards BTW, their examples are exactly backwards and do not work) and in fact I did the prior, ssh-tunnel based encryption that they were using on the Alpha server, I am entirely sure of what they are running.
I have no idea what other JCs are running, but Yuba is running Colleague under HP-UX 11i on an 8-way iTanic. And thanks to me, student information is actually encrypted between the server and the client :P (Actually, thanks to the district's money going into my pocket... it's not like I would have done it for free. HP-UX is the great satan of the Unix world. I'd walk a mile for AIX after fucking around with HP-SUX for days.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Another this is: Look how many processes back Itanium is! I mean seriously aren't they just now migrating to 90nm? If they'd moved up process scaling and had it leapfrogging onto say one process behind current x86 they could be in a lot better position performance-per-watt-wise. But as it is they're so many processes back they look like mainframe hardware as the microcomputer was coming out: Reliable, and in many cases fast, but bulky and hot in comparison.
"PowerPC was explicitly designed to make 68k emulation easier."
That is false. PPC was largely designed to be compatible with IBM Power chips. There were three bits from that which just happened to make a 68K emulator more efficient. The PPC was big endian (well except for CHRP boards), there were lots of registers, and there were 8 fields in the CR (CR0-CR7). The emulator used a bit in CR5 (if I remember correctly) to signal that an interrupt occurred and there was a branch after that in case there was. The other bit that helped was that there was a cache, but on the 601 and some 603s it was too small. They would have made them larger if a faster 68K emulator was so important. And then there was one thing lacking in the PPC that made the 68K emulator hard, there was no 80-bit FP on the PPC, only 64-bit and 32-bit. As a final issue the MMU was different from the 68851 used on previous Macs.
The problem is software being delivered as binaries.
I think that's chicken-and-egg: if you have a single, dominant, binary-compatible architecture then the most efficient way to distribute commercial software is as pre-compiled binaries.
Linux runs on so many architectures for the simple reason that many Linux developers take a pride in their work and actually care about interoperability: all that cross-platform support doesn't happen magically because its written in C! A substantial app will be riddled with "#ifdef IA32/#ifdef MIPS"-type, and if you compile from a tarball someone, somewhere has spent a lot of time preparing that .configure script.
Given the existence of a ubiquitous single platform with 90% of the market, there's no short-term commercial case for that sort of attention to detail (...maybe posterity will show that there's a long-term case, but since when did that amount to a hill of beans?)
Interestingly, though, most Linux distros have gone for binary packages as their main form of distribution...
My bet is, long term, "bare metal binary" software will naturally disappear in favour of scripting languages, JIT compilation and/or virtual machine bytecode. Compatibility will be determined by the API, not the hardware and, by definition, any software that still needs "raw hardware" performance will need to be hand-tailored for the hardware anyway.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
IA-64, iirc was slower than x86 when compiled with primitive compilers (read gcc).
A lot of the advancements were in floating point, which is still meaningless to most people except gamers (which wouldn't be using the platform) and special interest companies. Namely, branch-prediction's were more accurate for instructions which take 32 to 64 clock-ticks (64bit sqrt, divide, etc).
The advancements of the VLIW were negated by very-large prefetched instructions with cached pre-compiled op-codes.
The branch predictions only gave you a theoretical advantage over the very large branch-prediction buffers, and in some circumstances the branch-predictors gave you better decisions (hot code could pre-guess a direction before a predicate register was even populated - the Itanium would have to execute both paths, but the branch-predictor choose the hottest path). Further Alpha laughed at Itanium, saying they've had branch-prediction hint op-code variants for years(without predicates), and they showed many synthetic algorithms which would produce better alpha code than Itanium.. Basically saying for most algorithms, predicate-registers produce less efficient code than other alternatives (just happens that x86 didn't have any such instructions - but that would have been easy to correct with yet another op-code prefix). Note i686 did introduce the conditional move instruction, which goes a long way to small but common branch avoidance.
Register windows (a la sparc's) are a neat idea, but with register renaming on the x86, a tight function-call loop can be just as fast. Plus the spilling of registers into memory often is mitigated with the high speed cache. Further, many arguments against the small register set of the x86-32 are avoided in the x86-64's much larger register pool. Lastly, if you only have 16 registers (of which only 8 are hot), then you can efficiently utilize a pool of 256 rename-registers. If, however, you have an explicit 128 register addressibility (most of which is statistically cold), it's difficult and inefficient to remap them in future versions of the architecture. Note that every power of two register-size causes slow-downs in register interconnects - to say nothing of the real-estate and power-drain.
Then there's the fact that a program that only needs 2Gig of RAM will generally work better in 32bit than 64 due to the half-sized mem-pointers. More fits into your cache. Note other unrelated optimizations in x86-64 may counter-balance this (though this is independent of the 64bit design), so YMMV. I know that SUN's JDK 32bit runs faster, more smoothly than the 64bit version for most of our apps. Yes there are some CPU instruction optimizations for x86-64, but memory in java tends to be the limiting factor.. The same server app will consume 400Meg on a 32bit version and sometimes breaks a gig on the 64bit version. The GC times are measurably slower.
The explicit register rotation used in tight-loops - allowing a 6 op-code loop to execute every op in every stage of the loop, thus degrading a loop to at most n clock cycles is nice in theory. But what if your loop is more complex than a trivial inc/dec. And what if you need one more op-code than the architecture supports? Moreover, there's no technical reason why a CPU can't detect such a loop after k iterations and allocate register-renaming to do the exact same thing. With a hot-spot detector (part of branch-prediction), a subsequent access could fire up the loop immediately. But more importantly, future versions of the CPU could support even larger loop-lengths, as you're not explicitly limited by the bit-lengths, or the originally staticly compiled code.
The sad part is that the explicit compilation of CPU hints, and minimization of register spilling that are the hall-marks of the Itanium should theoretically lead to a slimmer, lower-power, higher-theoretical-clock CPU.. But due to other engineering decisions, the exact opposite is true. Lower clock, bigger silicon, higher power.
Basically th
-Michael
Your comment is stupid, but I'm going to reply to it anyway.
...
--
Don't feed the trolls - when an AC says something stupid, let it slide.
Heh.
My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
Not fully, is correct, but the IA-64 DID have x86 transfer instructions, which allowed an on-board x86 chip to execute them.. I Think this was slightly similar to the old 8086 FPU instructions which were ignored by the main processor and triggered activation on the co-processor. I think this explicit support was to allow libraries or emulated context switches. Don't recall. Was slower than a P3 at the time either way.
-Michael
That is false. PPC was largely designed to be compatible with IBM Power chips.
WRONG. Only the PPC601 even implemented the full POWER instruction set. They were not designed to be compatible with POWER, they were derived from POWER. After the PPC601 POWER compatibility was dropped; it was no longer even a feature, let alone a critical one.
Your objections about floating-point are a non-issue, "All versions of this emulator emulated the 'user' subset of the 68EC040 instruction set with a 68020/68030 exception stack frame." This provides basically a 68LC040 processor, which doesn't provide floating point anyway - and beyond that, any PPC after 601 can probably emulate the floating point faster than the fastest 68k processor ever used in a Mac (IIRC, 68EC040@33MHz?) Many Macs have no FPU or even MMU.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The statement in my sig is a general principle. Sometimes I violate it for posterity - to let future generations know that something some AC said is pure bullshit. The simple truth is that the above AC doesn't know shit and never will yet feels qualified to comment anyway, and IMO we should strip all anon access from slashdot. It's not like there's anything forcing you to make an account with any information which can be used to track you; similarly, logs for AC comments can be used to track you as surely as logs for non-AC comments.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You stated that "PowerPC was explicitly designed to make 68k emulation easier." I stated that PPC was largely like Power. Then I listed three ways that the Power-like-isms were utilized by the 68K emulator. Then I listed three things that could have been addressed to make 68K emulation better, faster, or easier if that was a design goal.
Please name one feature of PPC, not in Power, that was added to make the 68K emulator better, faster, or simpler to backup your original outlandish claim.
There kinds of pieces from the various magazine never stop disappointing, the title could indicate a mildly interesting article but some writer had a deadline and no story and banged this out.
If PowerPC is a failure, one of the most popular architectures on the planet, then just about every chip is a failure. Every game machine has one. How many cars have one? How many tivos have one? Even if you limit it to "desktops" by their standard there is one winner, ever, and that's Intel. Specifically the p6 architecture and now the core, everything else is a disappointment. It's the Ricky Bobby definition of failure.
It's like Vista being a failure for not selling as many copies as XP, likewise, despite massive growth, OS X must be a failure. If you're not first, you're last.
No mention of PARISC, Alpha, MIPS, Sparc? ARM? Intel dumped that business...
Outside perception - it started even before you say but really rooted in your reason #1.
From what I could see IA64 wasn't really started for reasons of pushing technical performance, the problem being solved was the existence of clone designs. All of the IA64 IP was held by a third company, and then licensed back to Intel and HP. That way, none of the IP would be covered by existing Intel or HP cross-licensing agreements. Then the architecture had to be sufficiently different that it would be fully covered by that IP, and none of the essentials covered by anything else.
So the initial design point was driven by legal and marketing concerns, and technical considerations were a distant third place, if that high.
That's the impression from one well versed in chip design who watched from outside.
The living have better things to do than to continue hating the dead.
To complete the history, this is the Itanium II story.
Itanium (Merced) was 80%/20% Intel/HP driven. Itanium II (McKinley) was the opposite, 80% HP driven. The HP guys considered Merced garbage and did not leverage much from Merced. But it was probably already too late for Itanium II. Just like in the early days of Microsoft and Apple, the market had already spoken and placed a huge premium on backward compatibility. Both Merced and McKinley performed about 6 years behind on the performance curves when running x86 code. Intel's bet was AMD was not going to be taken seriously with 64bit-Athlon simply because AMD was too small to create a trend by itself and customers would be forced to go to Itanium. Of course Intel was wrong, but it did not hurt Intel too much. Intel always had a backup plan-- codenamed Yamhill. Intel was only a few months behind AMD if x86-64 was to take off. McKinley also suffered from political turmoil at HP:
1) HP placed a high value on seniority and balked at hiring 1-3 year job hoppers. Even industry recognized people with PhD's and 20+ years of experience at other companies were usually told they would have to start as MTS but in a year or two would get promoted to TC's. And the few people who took this bait usually ended up getting screwed. At their yearly review they would be told maybe next year; they simply have not been around long enough. This meant they had a hard time attracting top of the line talent since while HP would match salary it would balk at matching titles and power.
2) The Carly Fiorina factor was a huge blow to HP employees expectations. She did not realise how many engineers were simply at HP for the work/life balance and promise of no layoffs in recessions. HP paid about 15% less for engineering talent because of the HP Way. When Fiorina basically destroyed the HP Way a lot of 10+ year HP'ers started to suddenly look around the industry to realise they could get paid a lot more by simply jumping ship so they did. She also made it very clear she wanted to exit the semiconductor industry and the Fort Collins,CO Itanium II team saw the brunt of her complete indifference about what they were working on; no raises, inadequate funding, etc. They were basically being setup to be sold to Intel which did eventually occur.
3) The Intel buyout was also a sore point. The HP employees were given no way out. Either take it or unemployment. It was pretty obvious at this point Itanium was a failure.
4) AMD moved into Fort Collins,CO about a year later and stole the best of the Itanium II team. Even the Captain of Itanium II jumped ship!
5) What remains now is just a shell of the former team. They can't hire since Intel isn't exactly enthusiastic about Itanium's future and what good engineer wants Itanium on their resume at this point.
This is why ARM or MIPS-based netbooks are so interesting. Every x86 these days is a RISC chip with an x86 interpreter on the front - but that's enough that ARM and MIPS still use less watts for the same processing power. But the ARM/MIPS netbooks are Linux just like you're used to, running all the GNU/Linux apps just like you're used to. The lack of Flash is the only practical problem.
http://rocknerd.co.uk
The PowerPC is a pretty successful product. It's not used for PCs anymore, but it's plenty popular in products that need more than an ARM/PIC/etc, but not the full-blown cost/power/heat of the current generation CPUs. It fits nicely into an ASIC. The MIPS and i960 play a similar role.
'Brief' is right. Although they should have added "somewhat accurate hearsay" in front of it.
Seriously, the Itanium stuff is all things we've heard before, with no real details. The IBM section is completely wrong:
(Though [PowerPC] has been reincarnated as IBM's Cell processor that powers Sony's PlayStation and the architecture still powers IBM servers.)
wtf? No mention of POWER? Reincarnated as Cell? huh?
And who cares about Puma? Where are the ugly details of PA-RISC giving up the ghost because intel looked at them funny? What market are we even talking about? Desktop? servers? Very different chips are needed for different markets.
Sorry ya'll, this one's dead in the water.
FUNK!
I am surprised that they knocked the AMD Puma in the article while leaving the following piles of crap unmentioned:
1. The original Covington Celerons with no L2 cache
2. Original Pentiums with the FDIV bug
3. The Pentium III Coppermine 1.13 GHz that was infamously unstable
4. Socket 423 Pentium 4
5. The Pentium 4 Prescott 3.6 and 3.8 that overheated and throttled at stock speeds on the stock heatsink
All of those chips were bigger duds or had bigger errors than even the TLB error in the BA/B2 Barcelona Opterons they mentioned in the "Part 1" article.
Just "gittin-r-done," day after day.
The author is right that Itanium never caught on the way Intel expected it to, but to say it's totally dead isn't exactly correct.
After their huge round of acquisitions in the late 90s/early 2000s, Compaq and HP pretty much killed all of their high-end processor lines and standardized the platforms by porting them to Itanium. Compaq/DEC brought HP the Alpha, and HP stopped making that line and ported OpenVMS to Itanium. Compaq/Tandem brought in NonStop/MIPS and HP folded that product line into Itanium. Finally, HP has killed its PA-RISC line of processors and ported HP-UX onto Itanium.
Itanium does have a place, but it's at the very high end of the server market. As long as these platforms exist, it proabably will as well.
(Side note, this is why I'm able to buy older Itanium boxes on eBay for $200 -- no one understands that they'll run Linux just fine and the commodity x86 market gets so much more attention!! Thanks everyone for unloading these cheap, fast boxes!)
Being as 4-way and smaller Integrity servers have been available since day one, I still don't understand why they had to go to an 8-way box. A dual CPU Itanium2 would pretty much destroy any 4 CPU Alpha in CPU performance.
Gamingmuseum.com: Give your 3D accelerator a rest.
Then by that logic, this whole article is a massive 66%.66- failure, I thought it was using a different rubric than just number of products sold, as the following quotes demonstrate-
"IBM's original PowerPC platform never lived up to the hype. Even when Motorola and IBM processors populated Apple computers."
PPC chips have sold truckloads, this guy acts like the G5 was the first PPC chip ever made! I mean let's look at all the embedded systems it ended up in anyway, and I'm sorry, it's not like they sold only 2 macs with ppc chips in their lifetime (even if we just count G5's and ignore G4's, G3's, and 601-604's). Xbox, Gamecube, Wii, not even counting the cell that's in the PS3 because it was an evolution of a chip, several laserjet printers, several thin clients, routers, and other embedded devices are driven by ppc chips.
"It's not so much that Puma (aka Turion X2 Ultra coupled with ATI graphics) is a failure of epic proportions like Itanium, it's that the CPU component (separate from the ATI GPU component) fell so far short of the long, ballyhooed build-up it got."
So why the hell does the article mention it if this article supposedly called a chip (or platform) a flop just by numbers alone?
Now, if we were mentioning it by numbers, and specifically by numbers that didn't challenge the pc market, then the amd 2900 and intel i960, while both are excellent chips, never made it in a big way to the computer market as the main cpu driving things, would be called flops... not to mention the MIPS in the SGI boxes, the Sparc processors in SUN boxes, the Alpha procs in DEC and later compaq/hp boxes, all AS/400 cpu's, all which he doesn't call flops... Which is why I made the selections for "flop" processors I did. I thought he was looking at "failures of a processor/platform" which included how well the product worked or didn't, rather than just market penetration.
Therefore based on this failure of an article which you neglected to read or at least apply to the comment made, your slashdot comment fails by 100%. However since you are living in your own world, that math doesn't apply, in which case the article fails by 66% by your math, which means your comment fails by 33% in your world, which is considered failing in many finer parts of the world.
This article is pretty much written with this philosophy: "If it's not running on my desktop, it's a flop." I can't speak for Puma, but considering how many Macs and game consoles were shipped (and are being shipped) with PowerPC processors, and how much of an improvement Itanium2 is over the original, I simply don't get it.
Gamingmuseum.com: Give your 3D accelerator a rest.
(IIRC, 68EC040@33MHz?)
The Quadra 840av used a 40MHz and that Mac managed to do some tasks like av encoding faster than anything till the 604e came along in 1996. That was more due to the DSPs though, than the CPU.
Why save your soul when you can sell it for a profit?
This is why ARM or MIPS-based netbooks are so interesting.
Interesting, but not popular. Where do you even find a netbook that's not running an Intel Atom or VIA Nano? (And the only one I know of running the Nano is Samsung's... 90%+ of the market belongs to Intel.)
Comment of the year
I didn't say all overdrives!
I was primarily thinking of the 486 socketed pentium overdrive, as well as the socket 4 pentium overdrive. I did not have a pleasant time with the 133mhz 486 overdrive either.
So commercial software pioneered W^X, randomized memory layouts, execute protected stacks, type inference, virtual machines, Unix, SMTP, UUIC, DHCP, Reno TCP, and Berkeley sockets?
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
Go to: http://www.spec.org/cgi-bin/osgresults?conf=cpu2006;op=form
Change Processor from SKIP to Display.
Order by published asc, baseline desc, result desc.
Submit the form.
Look for the CFP2006 benchmarks.
Then look from then on.
You will see that the POWER6 or Itanium 2 lead over the x86 at any time was rather low.
In Aug 2007, the Intel Core 2 Duo E6850 was about even with the POWER6.
By Oct 2007 the x86 Intel Xeon X7350 was leading.
AFAIK the CFP2006 benchmarks are single threaded performance tests, and the "CFP2006 Rates" are for multithreaded tests.
The x86 may be an ugly pig, but it now has a huge jetpack strapped on.
So the "elegant" eagles that want to be as fast now also have to wear huge and ugly jetpacks.
From a distance they now look about the same and run about as hot :).
POOF, Itanium goes down in flames. :(
Don't you mean F00F?
The various business decisions around this cheap and slow processor didn't help either. Demanding a king's ransom for the only compiler for the platform didn't help nor did refusing to provide the information needed for a free compiler to support it. Nothing ran on it, so nobody bought them. Thus, nobody was terribly interested in paying a fortune for a compiler plus a learning curve in order to make their software support a processor nobody had.
Meanwhile, AMD is offering these nice speedy x86_64 processors that are perfectly happy to run the regular 32 bit code already in production. Oh, yeah, the AMD solution was thousands of dollars cheaper.
http://www.littlelinuxlaptop.com/ - these things are widely available in the UK. They're basically toys as yet (locked down, user-hacked firmware is a hideously rough alpha), but very interesting for their potential.
http://rocknerd.co.uk
Did you just make that conspiracy theory up?
The Alpha and its instruction set was covered under intellectual properly laws. First Compaq bought DEC, then Compaq sold most of the good parts of the Alpha technology to AMD. The smash hit "Opteron" was based on Alpha technology, and most of the old Alpha engineers were hired by AMD. One reason AMD has struggled to repeat their surprise leap-forward is that it was not based on home-grown technology but rather a onetime boost from the legacy of DEC R&D.
Now that HP owns Compaq, and they may hold some critical IP (such as the ISA). So a derivative is possible, but the timeline does not work. The "Itanic" was then, this is now.
That was pretty hilarious, considering that when other chipmakers were making chips (68k, PPC, Alpha, etc) which didn't take over the personal computer market, Intel made the 80286 which could work as a fast 80806. Then the 80386 which could work as a fast 80286. Intel proved backwards-compatibility was the most important feature in personal computer processors, overriding any other concern.
They forgot, and then AMD expanded x86 exactly the way Intel had previously done twice: by making something that could work as a fast 80386.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Let me demonstrate why we have binary distrobution.
"Hey dude, my copy of Adobe CS4 is coming today!"
"What? I thought you picked it up at the store a month ago?"
"Yeah, I did, but I had to wait for it to finish compiling!"
This is all without mentioning corperate need for code secrecy, and the need for an environment to compile an operating system on.
Itanium is also the current processor for NonStop systems.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap.
...and AMD would be well and truly hosed. Given that Intel and HP weren't licensing IA-64 to anybody, if it ended up replacing x86, AMD would be screwed, so I'm not sure they had a choice in the matter.
Wayyyy OT, but that's interesting: I had a few entry level classes on VHDL/Verilog in 2005ish and had no idea they were that new--or was iHDL just the dominant hdl at that point?
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)
VLIW has been more successful in other markets, such as embedded processors for telecom equipment. I got the impression from my computer architecture class (hopefully someone with more specific information can chime in here) that a VLIW processor beats the socks off x86 given a well-crafted stream of instructions, but compiler support was just too hard and never really materialized, so VLIW is used mostly used for special-purpose devices where the software hot spots can be hand-written (using C intrinsics or assembly) to make efficient use of the processor. Basically, given the lack of sufficiently intelligent compilers, VLIW platforms suck for general-purpose computing.
If you really care about CPU design and history, read Great Microprocessors of the Past and Present.
Chips that ran FORTH and Java, intel RISC chips from the 1980s, the M88k, Transputer, Alpha, you name it, it's there.
makes your comment even more retarded. Intel has their own compiler which is leaps and bounds ahead of GCC. Get out of your basement ..
My bet is, long term, "bare metal binary" software will naturally disappear in favour of scripting languages, JIT compilation and/or virtual machine bytecode.
That's the long-term outlook, but in the short term, most developers are working in an older mindset, using a definition of "portable" that includes C. Of course, very few people are savvy enough to write completely portable C code, and even they make mistakes, so porting a C program to a new binary platform requires at least a code review and a bunch of testing.
In this C-centric world, binary compatibility remains extremely important even when you have access to source code.
"Very little code is written in x86 assembly"
This is not entirely true. Visual Studio has many intrinsic functions which are close to macros that substitute assembly instructions. These are not portable across architectures.
"porting it to IA64 is relatively easy"
This is false if the code uses anything other than ANSI code and libraries, which almost all performance-critical programs do. On any MMX+ processor, why would a programmer use unsigned short when __m128 provides 8x the throughput? Itanium doesn't have a 128-bit integer pipeline so __m128 isn't available but it does have a 64-bit pipeline so it can use __m64 datatypes and then a __m64_pmpy2l() intrinsic.
It would seem more apt to describe them as reluctant.
Nerd rage is the funniest rage.
Compiling to a VM makes sense in more situations when cpu time and ram are ridiculously cheap (and then porting the VM ports a great deal of other code). I'm not an expert, but I think JIT/interpreted is pretty orthogonal (Psyco is a JIT that plugs into the Python
interpreter, increasing speed by creating native code branches for execution paths; the branching can make code end up running slower, or hundreds of times faster...).
On the desktop, the cost transition happened some years ago (along with many server apps that are io bound).
So really, it seems unlikely that .net is a reaction to such a narrow range of events (and more likely, the easiest first step towards managed code).
Nerd rage is the funniest rage.
The much delayed future Itanium core, Tukwila, will be produced on the 65nm process. Release may come later this year. Since Intel's competitors are planning to use a 45nm SOI eLow-K process for their competing CPUs, unless Tukwila is some super great processor, Intel may want to consider using its newest fab process for the Tukwila follow up. If Intel thought that attempting to recover more money from a fab by reusing it for the Itanium or chipsets for current x86 processors, the low quality of the products produced would seem to indicate that this was a bad idea.
Impersonating Tycho from Penny Arcade since before there was a PA.
have you run any source based distributions?
open office is the largest single program and it takes 4 hours to compile on semi modern Core2 Duo T7100.
Had AMD waited until today to release x86_64, there would be more Itanics out there, but only because there wasn't a better choice for 64 bit. Within a few months, the x86_64 would be trouncing Itanium all over the place.
The x86 and by extension x86_64 architecture have plenty of problems. I'm sure something better can be designed, but IA64 doesn't appear to be it.
Pretty much the only buyers of IA64 would have gladly gone with Alpha instead had it not been killed dead by business decisions.
All recent history and CPU related. There are so many different and interesting failures in chipmaking history. Serial memory. Silicon-on-sapphire. Gallium-arsenide CMOS. The decline of bit-slice designs.
Contribute to civilization: ari.aynrand.org/donate
Well, the idea was more to take a lot of things that were typically done in hardware (such as trying to exploit parallel execution as much as possible) and push those tasks into the compiler. An interesting idea that never really sat well with me though.
Oh it is a great idea IMO. But somebody has to write the compilers first. When you think about it, writing a compiler that automatically arranges any kind of input software into parallel executable threads, is maddeningly difficult task. And much more difficult than merely designing the chip that will later execute the parallel threads. So just putting the chip out there and assuming someone else will do you a big favor and make the compiler is kind of silly. It's like building an elaborate spaceport for interstellar travel and assuming someone else will come up with the spaceships. BTW, playstation 3 suffers from the same problem and thats probably the main reason the Wii is kicking its ass.
iHDL was Intel HDL
And is was legacy code. They used it for Pentium.
I am sure it started before VHDL was prevalent, but it was never left to die.
I forgot to mention the design environment.
Intel would buy a tool (synthesis for example) years before it was popular, and (since we were Intel) pay the developer a truck load of money to fork the code and design a new feature X. Eventually, Intel money would end and the fork would end-of-life.
Now a few years later the developer would add feature X to their code, but it wasn't exactly Intel feature X, it was industry compatible feature Xa.
But Intel had already built a whole system around feature X. So, we ended up with design tools 2-3 generations behind the industry standard. Because switching to feature Xa was not feasible.
And all these design tools were cobbled together using Perl wrapper scripts. And since no one knew how these old Perl wrapper scripts worked (because of non-OO Perl & people leaving), they built more wrapper scripts to fix bugs or add new features. So, working at Intel CPU design you never got experience with a industry tool, only Perl wrapper scripts.
That said the Perl scripts around RCS (prior to CVS and called HRCS hierarchal) were amazing and we should have open sourced those. Really made RCS workable on a project with a cast of thousands.
iHDL was capable of doing all the things (mostly) that VHDL does, but because "we're hand drawing the circuit layout for speed" you had to use gate level macros (e.g., sig_out# = NAND3(sig_in1, sig_in2, INV(NOR2(sin_in3, sig_in4))) ).
They forgot, and then AMD expanded x86 exactly the way Intel had previously done twice: by making something that could work as a fast 80386.
No. They didn't. The Itanium was able to run as fast as an 80386. However, the x86 architecture had long since adopted to RISC ideas such as pipelining and OOE.
The original Itanium even though it "only" ran at 800MHz it was able to by exactly the precise design of the architecture run two instructions at once. That puts it at about 1.6GHz, and since its pipeline was much shorter than the P4, branch misprediction costs were much lower, and since it had predicates, it could avoid branches entirely for short instruction groups.
This whole idea that it was "only" 800MHz or that it wasn't fast, is absolutely bogus, and I expect people on Slashdot to understand that MHz to MHz comparison is only useful on the same core.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Yes, of coarse any multi-million line application solely developed and tested for 32-bit target will compile and run on 64 bit without any bugs.
VLIW is also used in all the modern ATI GPUs. That's one of the reasons they'll never open up their drivers - a lot of the smarts that make the cards run fast are in the shader compiler, and they don't want people stealing their ideas.
I believe that the Itanic wasn't exactly standard VLIW, though - it was something more complex.
It's like building an elaborate spaceport for interstellar travel and assuming someone else will come up with the spaceships. BTW, playstation 3 suffers from the same problem and thats probably the main reason the Wii is kicking its ass.
That's an extremely poor analogy. First of all, Wii is a spaceship when it comes to console games. They went with a novel controller and tried to appeal to casual gamers instead of high-cost, high-performance tech. A more accurate comparison would be between the 360 and the PS3, where the PS3 theoretically has more horsepower but practically doesn't showcase it in games.
"Notice how TFA talks about specific chips rather than architectures?"
Which specific chips? The article does not mention G3 or G5. It only says "PowerPC" which includes 601, 603e, G3, G4, PowerQUICC, Gekko, etc. If you want to get technical the G5 is a POWER4 and not a true PowerPC (it supports things beyond simple PowerPC subset of POWER).
Either you don't know what PowerPC means or you don't know what "specific" means. (or you are trolling)
“Common sense is not so common.” — Voltaire
From, Intel IA-64 Architecture Software Manual page 1-1 "EPIC Explicitly Parallel Instruction Computing. A key feature of the IA-64 architecture is IA-32 instruction set compatibility."
So much for the key feature, they dropped the IA-32 part.
If you can only run 32-bit Windows on your 64-bit chip at half the speed of a new 32-bit chip, do you think anyone will care?
Intel didn't (Itanium)
AMD did (x86-64)
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap. Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat ...
Superior tech or not for Itanium, it sure didn't feel superior at the time. To go with Itanium, you would have:
- been locked back into a single chip vendor, like the days of yore before Cyrix, AMD and VIA hit the scene
- had to put up with sub-par 32bit performance
- bet the farm that Itanium would truly be the future
- spend a lot more
Thanks, but no thanks. AMD came out with Athlon64 and Opteron 64bit, which gave you 64bit future-proofing while giving you outstanding (for the time) 32bit performance. There was simply no short-term (or long-term) downside to going with the AMD chips. You were covered no matter which way the market moved.
Wolde you bothe eate your cake, and have your cake?
You may want to go back to that sight and try again. You're looking at 1 Power6 core against 2, 4 and 8 cores on the procs getting similar scores.
You need to do 2 things, first set the # Cores "equal" to 1 and look at the list so you are comparing apples to apples.
Now set the # Cores "equal" to 2 and do the same thing, just so you can see how the procs scale with multiple cores.
I generally see the Power6 score 50% to 100% higher than others.
W^X is nothing but the name given to a single implementation of using hardware NX bits. Hardly noteworthy and something that depends on hardware implementation.
Randomized memory layouts? I have no idea what you are talking about and it doesn't sound like you do either. Did you perhaps mean address space layout randomisation?
Executing protected stacks, see HP-UX, a commercial OS.
Type inference is a feature, albeit one that only a novice or poor programmer would hold in esteem, not a piece of software. See Ada, a commercially developed language.
Virtual machines were first used by IBM, so yes, commercial.
Unix is commercial and owes its existence to another commercial OS called Multics.
SMTP, UUIC, DHCP and TCP are all protocols, communications standards, not pieces of software.
Since most of your list is completely invalid and/or irrelevant to the discussion, here is one for you. 99.99% of all software runs on commercially researched, produced, marketed and sold hardware.
Yup - and I really miss motherboard reviews (they are harder to find these days it seems). Back when they existed they tended to show significant performance differences - you could often spend $30 on a better motherboard and get more improvement than spending $75-100 on a CPU. They really need to test/price the whole package.
I went AMD with my last upgrade - sure the Core2 is faster but at my price point there were lots of options and I found that AMD looked to be the better deal. It helps that with AMD you get to pick one of about 847 motherboards instead of the very limited Intel offerings.
Agreed. The big changes only tend to happen with platform shifts. If you design a new cell phone and you don't care much about compatibility so you get the best theoretical design possible. If you are building a laser printer or a router or a microwave - ditto.
If you're designing another CPU for the desktop then backwards compatibility is everything.
Depends. DEC sold quite a few 600MHz Alpha systems because they ran x86 Windows software as fast as a 100MHz Pentium or faster, but ran new, native, Alpha Windows software faster than anything else on the market. These systems died in the end for the same reason that Itanium didn't make inroads; that they ran the new software slower as well because they couldn't persuade people to port their code.
When Intel released the Itanium, they needed to send out development models to all of the big software houses and give them toolchains that let them easily build their software for both platforms. If there had been a load of programs that ran on x86 and Itanium, but ran faster on Itanium, then this would have been an incentive to upgrade. There were some, but they were in-house programs that individual companies could recompile for the new system, and the price of having them go faster was all of their other new programs going slower, which wasn't an acceptable compromise.
Compare this to Apple's PowerPC and x86 transitions. They provided emulation layers to run all of your old code. m68K apps would run on a new PowerPC chip, but would be slower than on a new m68K chip, PowerPC apps ran slower on a new Intel chip than a new PowerPC. But they also provided developer tools so that people started releasing fat binaries. Every new program people bought supported both architectures, and ran faster on the newer one. If you went to the new architecture just after the transition, your old apps would be slower, but your new ones would be faster, and that's what most users cared about. The old apps were 'fast enough' already. The new ones were the ones that taxed the system.
I am TheRaven on Soylent News
That's the long-term outlook, but in the short term, most developers are working in an older mindset, using a definition of "portable" that includes C.
Only if your definition of "most developers" excludes anybody working primarily in AJAX, Flash/Flex, Java, Mono/.Net, Perl, PHP, Python, Ruby or Z-Code - an increasingly large proportion (ok, maybe not Z-Code, but I wanted an A-Z).
Not that "real" developers will be going away anytime soon - somebody has to write the runtimes - but I don't think C would be my "tool of choice" for writing applications any more.
The end result for new/novel platforms would be that, rather than needing a critical mass of hundreds of applications to be ported, they'd just need half-a-dozen common runtimes.
As I said - chicken-and-egg. If there wasn't a single hardware architecture that accounted for 90% of the market then the argument for using a scripting or bytecode-based approach would be much stronger.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
They are supposedly going to jump directly to 32nm after Tukwila.
What percent of software installed on a typical Windows machine is written in interpreted language or compiled into "write-once-run-anywhere" bytecode?
Software written in languages you mention is mostly server-side. Even Java failed as a platform for desktop applications.
And no, "most developers" aren't coding web apps. The need for raw speed is still critical (ever tried using Eclipse? How many people have you seen using it?)
Coding etudes
false. you buy one part; that part can execute x86 code. the chip, therefor, has x86 compatibility. your next point even seems to admit it, while pointing out the (correct) fact that the compatibility simply wasn't very good. but that's not the same as not existing.
false, as a sibling has noted. PowerPC's designed happened to make emulation easy, but that was a selection criteria, not a design criteria.
false, for two reasons. first, successful competition does not need to lead to monopoly or monoculture, so your premise isn't any good. second, even if you believe it is, it only holds if you're competing within the same market, and the point is PowerPC, mainly, didn't. further, you entirely (i suspect intentionally) ignore the real point of the comment, was that up the thread the claim was made that PowerPC failed because it didn't have backward compatibility, while it did. you also seem to think PowerPC is dead, which isn't the case at all.
i speak for myself and those who like what i say.
Apple computers is also a tightly controlled market. Their word is the definitive word for the platform. So, when they said their platform was going from x86 to PPC, developers and users had just one choice... accept it or die.
x86 (and servers is general) is a much more open market. It's large and diverse enough that it is it's own toughest competition. It has a LOT more legacy invested in it, and no matter how hard you try, it's going to take a LONG time before the most performance-critical bits of it get ported over.
That's only true when you can force people to upgrade most of their apps. You have NO HOPE of that in the x86 world.
If Apple couldn't force their developers to update, and couldn't stop the sale of compatible (PPC) systems, you'd have seen them having a MUCH harder time with the transition as well. Of course, at that point, their systems had really stagnated, and their latest PPC chips were horrendously slow compared to x86, so their own inability to push their own platform helped the jump to the next one as well.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
What percent of software installed on a typical Windows machine is written in interpreted language or compiled into "write-once-run-anywhere" bytecode?
Well, anything written using .Net/C# (and the current Visual Basic?), for a start. Google maps, most Webmail systems and similar. Ever heard of Slashdot, for example?
Software written in languages you mention is mostly server-side.
So? Its still written by developers.
And no, "most developers" aren't coding web apps.
Actually, "most" developers are probably maintaining in-house applications for the corporate sector, and a helluva lot of that will be Java, C#, Visual Basic, AJAX, SQL stored procedures (and probably more dBaseII than is comfortable to contemplate).
The need for raw speed is still critical (ever tried using Eclipse?
Yes - I like it - is there a problem? Which part of Eclipse (there's an awful lot of it) The last time I tried the visual editing stuff it was slow and buggy but going by the acronym thicket surrounding that I suspect that is gratuitous over-engineering rather than anything fundamental about Java.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
AFAIK, UCD uses a set of massive Sun Enterprise servers to run their backend Oracle databases and mail servers.
"In