Slashdot Mirror
AMD Lures IBM Veteran to Lead Chip Design
Rob writes "Computer Business Review is reporting that Advanced Micro Devices yesterday said it had hired Jeff VerHeul away from IBM to
lead the direction of AMD's future silicon design. VerHeul's most recent post during his
25-year stint at IBM was head of engineering and technology services. Now, he will lead
the development of all future AMD computing products, including silicon roadmap design
across all AMD's engineering sites worldwide."
The Cell's core CPU is a PowerPC processor. And the PPC is a very good chip - the problem is that IBM decided that it should focus on Power5 and Cell, and neglected the G5 (and had some scaling issue, IIRC). The G5 wouldn't sell nearly as many units as Cell does, and the Power5 probably has a high margin (and is for their own server products). Again, IIRC, IBM tried to sell Apple on the Cell (so they could continue to fulfill their obligations to Apple without keeping up the G5), but Apple felt that the Cell wasn't really a good choice for general-purpose computing.
Athlon wins the prize for brute CPU power, but the real strength of PowerPC is that IBM can design custom chips based on combining PowerPC cores with additional processing elements. This technology is behind Deep Blue, Blue Gene, the PS3, and the Xbox 360.
This kind of chip is hard to program for, but can deliver unbeatable performance per dollar, square centimeter and watt when software is codesigned with the hardware.
AMD and Intel are going in this direction with dual-core, but IBM is already way ahead. For instance, BlueGene is based on a special chip that has two PowerPC cores with an incoherent cache (tricky to program but cheap and fast) and adds an enhanced vector processing unit. IBM is a leader in higher-end SoC solutions (really, anything that gets power from the wallplug instead of a battery.) Lower-power applications are using MIPS and ARM cores instead...
One thing that has been interesting me lately, after reading a series of Anadtech articles on current and near-future processor tech is the possible inclusion of SMT (oft marketed as Hyperthreading by Intel) on AMD cores.
The article mentions the POWER5 chip and it's implementation of SMT and how it behaves with multi-core chips (i.e. how it can devote all threads on one core to a single task, with the other core(s) sharing the workload via SMT) and how it's rather more impressive that the HyperThreading[TM] on Intel P4's, although I'm not a microprocesor guru.
Whilst I can understand AMD's decision not to put SMT in their current processors, with the recent focus on multi-core and multi-threading I think they'd be foolish not to think about it soon, and (as someone not very up on non-x86 chips) it seems IBM's POWER5 is a good base to emulate. Does anyone have any information on SMT implementations in POWER other chips like Sparc and Itanium?
Moderation Total: -1 Troll, +3 Goat
Your silver bullet is no real solution. You would still be dealing with algorithms, you are just pushing them somewhere else and calling them by a different name. The signal based synchronous software model would not (in and of itself) make any improvents to the relibility of software. You state in your paper that hardware flaws are physicial flaws rather than design flaws, which is completely untrue. The hardware world has seen more than it's fair share of design flaws as well. The reason is that QA for hardware is typically much higher than it is for software for three reasons:
1) hardware typically is designed to have longer life cycles than most software. Many chip producers are still actively manufacturing and selling five year old designs, while (for example) Microsoft has not only stopped selling windows 2000, they've also stopped actively supporting it.
2) hardware is difficult to patch after it has been deployed, so they can't just ship a product and then release patches when they find bugs after the fact.
3) hardware is usually much easier to test than software because it is much simpler (in that it is usually designed to perform a much smaller number of tasks in a narrower range of conditions), and a finite series of tests can be designed that achieve full or nearly full coverage.
the real problem with software instability is twofold.
1) marketing pressures in the software industry are such that software tends to be released without bing properly tested, released with known bugs, and more emphasis is put on getting things quickly rather than getting things done well.
2) unlike in other industries, consumers have come to expect that it is normal for software to be buggy or to have numerous patches released after the product. they would never accept this in consumer electronics, cars, public transportation, home appliances, or anything else that they purchase, but somehow this is normal for computer software, so they shrug and go on with their lives.
number 2 is the primary cause, because if it wasn't for number 2, number 1 wouldn't happen. the companies that rush products out the door that are buggy and incomplete would go out of business as people refused to buy their products or returned them en masse for being faulty. (which is another problem with the software industry- people can't return software that doesn't meet expectations like they can in any other sector)
which, by the way, is what happens to just about any non-software company when they release products with the same level of quality control as most software companies.
If I don't put anything here, will anyone recognize me anymore?
"ex-IBM Engineer sued for violating non compete agreement"
Very unlikely, IMHO. I've worked for IBM for the last 10 years, and I've seen firsthand how IBM handles these sorts of situations -- with kid gloves. Although IBM employees sign an employment contract that includes a non-compete clause, IBM almost never tries to enforce it. For example, I know a former IBM executive who violated his IBM non-compete agreement by going to work for a client, as CEO. That's not at all unusual, of course, though it is very bad form. What makes this situation unique is that this guy didn't bother to notify IBM of the fact that he'd taken another job, and simply drew both salaries for several months until he was caught.
IBM did nothing other than record the incident in his record and mark him as a person never to be hired by IBM again in any capacity. However, even that is less severe than it sounds... I know another guy who was fired and marked unhirable, and he's working for IBM right now.
I'll be *very* surprised if IBM does anything. IBM is very afraid of looking like a big bad company who picks on defenseless individuals and smaller companies (and how many companies *aren't* smaller?). In most cases IBM would rather eat a loss than sue and take a PR hit. Depending on the size of the loss, of course.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.