AMD Rumored To Announce Layoffs, New Hardware, ARM Servers On Monday
MojoKid writes "After its conference call last week, AMD is jonesing for some positive news to toss investors and is planning a major announcement on Monday to that effect. Rumor suggests that a number of statements may be coming down the pipe, including the scope of the company's layoffs, new CPUs based on Piledriver Opterons, and possibly an ARM server announcement. The latter would be courtesy of AMD's investment in SeaMicro. SeaMicro built its business on ultra-low power servers and their first 64-bit ARMv8 silicon is expected in the very near future. However, there's always a significant lag between chip announcements and actual shipping products. Even if AMD announces Monday, it'd be surprising to see a core debut before the middle of next year."
There is no justification in this world for such crazy massive generalization of power hog Intel CPUs in servers: Intel's CPUs are only justified for per-thread maximum performance. And that is unnecesary for 99.9% server applications.
I've worked for a few very large companies who have made huge redundancies amongst engineering staff just as soon as projects are completed and ready to ship.
The logic is pretty simple: there are great new products ready to go and the cost base can be instantly reduced by letting go thousands of staff making profits might higher as a proportion of the cost base in the very short term (next 1 to 4 quarters).
The trouble is, you have to skate to where the puck is going, i.e. you have to be constantly developing new and better stuff to come out in a year to 18 month's time. If you don't have the R&D staff, you are in a tricky situation.
I suppose the logic is that you can hire people back when you're out of the economic hole, but I've never seen that happen. What does happen is a continuation of the company's decline until it eventually gets bought out.
Many of the people can't be hired back anyway, because they've moved on with their lives (retired, retrained, got new jobs). Do CEOs think that us little people sit around on our backsides all day worshipping their corporations and doing nothing except waiting for them to offer us jobs?
When you let your institutional knowledge leave the building, it goes for good. MBAs don't understand this.
Stick Men
Wait for the newer products coming out from CalXeda, Marvell, etc. Their newest chips are strong contenders for the server market, featuring multi-cores with extra core for management, and fail-in-place capability. If they're any indicator on performance and capabilities, mean that they'll ultimately make their way into data centers and the emerging cloud. This is a good thing, since ARM is less power-hungry, and thermal output is a prime concern for data centers.
CHANGE is good - finally, we'll see the Intel x86 goliath defeated. Remember, if it hadn't been for AMD/Opteron putting the heat to Intel's feet at one point, then Intel wouldn't have taken the trouble to improve its chips soon after. Likewise, ARM is injecting new and intense competition into the marketplace, which the rest of us will all benefit from.
Your comment is on target given that ARM systems have a history being both lightweight and worse yet, inconsistently equipped with floating point hardware. The consequence has been that application and package developers face a choice between being able to run on lots of hardware by avoiding dependency on FP, or to provide good performance by limiting their applicability to systems with that hardware. I do not know whether ARM can overcome that history in a bid for a place in the server marketplace.
I expect that ARM architects recognize the need for consistency, with the result that the ARMv8 64-bit spec is way more specific about what developers can count on, so they can use high performance compiler settings consistently, while still being sure their applications can run on all servers.
This is a very important place where the Intel IA32 and AMD's x86-64, won. Beginning with the i486 (not SX), developers had a consistent set of compiler optimization choices providing "really good" performance. Anyone wanting really kick-ass, custom-optimized performance is welcome to go with tightly customized, processor-specific compilation, as one might be able to justify in HPC.
So the question is whether ARM's history of support for giving silicon implementers major freedom in selecting from among many options, will leave a legacy of inconsistency or whether they can get past that to enter the marketplace where consistency is required for success.
BTW, as an embedded developer, I've found the flexibility of choosing silicon that's well-tuned to my device-specific needs to be very important.