on PA Semi
I think the answer is in this pair of paragraphs:
The lack of any obvious application of PWRficient in Apple’s products has already spooked PA Semi’s existing clients. EETimes reported that just two days prior to the announcement of its purchase by Apple, “PA Semi informed its customers it was being acquired and it could no longer guarantee supplies of its chips. The startup did not identify the acquiring company but said that company may be willing to supply the chip on an end-of-life basis, if it could successfully transfer a third-party license to the technology.”
The report then flatly reiterated that “PA Semi customers were told the acquiring company was not interested in the startup’s products or road map, but is buying the company for its intellectual property and engineering talent.”
After saying Apple won't be supporting PA's customers as Apple customers, the article suggests Apple would use PA chips as accelerators to provide performance advantages. Honestly, I wonder at that. The trend in speed seems to be to reduce silicon: putting the RAM controllers on the CPU silicon to reduce latency and throughput, adding instructions to the CPU instead of depending on separate coprocessors, etc. GPUs' apparent ability now to handle flexible programming seem to be a counter to this, but GPUs have been a special case for a long time: folks depend on very sophisticated and specialized processing for graphics, and hardware acceleration of this type of calculation is a shining example of a very broadly-demanded high-yield place to add silicon for good return. Years ago I used to read a lot about audio processors, sound cards, and so on, but I sense most of this has ended up back on the CPU, with only conversion to analog likely depending on special hardware now (though I am happy to stand corrected -- or to hear that serious gamers or professional audio folks still use separate hardware I don't see advertised heavily to the masses any more).
Would Apple really want to invest in coprocessor development when the development of the CPU is likely to be more likely to solve the "problems" a coprocessor would address? By the time the coprocessor got out of testing, would the bottleneck not have moved? What is really stopping performance now? And isn't the PPC another general-purpose processor? Would Apple seriously ship both PPC and Intel in one case? What about the margins advantage Apple now gets by using the same chips as its competitors?
Because Apple now sells millions of Macs per quarter, adding highly efficient hardware acceleration chips across the board would add only minimal cost while delivering a significant and tangible advantage that would be expensive and complicated for other PC vendors to match.
This is where I would need to see the math. I suspect that folks can easily buy more computer than their needs require, with the possible exception of the notebooks, so perhaps adding some energy-efficient coprocessor hardware in pro notebooks might be worthwhile. The Cocoa apps might really benefit from multiway machines with different processor types with different strengths. The non-Cocoa apps would never code for this stuff, in my view. And Lord knows what a compiler would do with a request to compile for a platform with discordant processor architectures -- would it be possible to custom-tweak an app that didn't have runtime decisions on what libraries to link? Would Apple's fork of the gcc have to go really crazy to support this?
Apple certainly is the only major vendor that could get away with something like coprocessors, but a serious coprocessor is a cost item. Would performance really shine enough to make folks see the value? Apple is selling to the masses -- not to an elite of hardware geeks. What, exactly, is Apple's incentive to complicate its products and add to costs?
I'd imagine there'd be a lot more return buying vendors of software for medical practices, real estate offices, and law firms. These guys shell out, buy support, and give repeat business and upgrade revenue.
Coprocessors? For real?
Cocoa makes this plausible -- Apple can add hardware-specific code to already-shipped software because of Cocoa, so the whole "re-coding to take advantage of the new [dual processor | GPU | sound card | I/O interface]" isn't a problem for existing apps, and benefit is immediate unlike the "benefit" people got when Intel launched MMX Pentiums -- but will the hardware really offer the zip Apple promises? On costly pro rigs, there may be a serious differentiator there, or on lightweight low-power systems without a dedicated graphics card, but ... I would need to see the math.
It's certainly an interesting road to take, and one nobody else will be able to follow. If it works, it'd be very interesting.
On the competition front, I am better persuaded by this kind of reasoning in the mobile sector:
Kaelin pointed out, “On the inside, the Zune is remarkably similar to the iPod Nano. Many of the parts are exactly the same. The difference is that the interface chips and software in an iPod are made by Apple. I know some die-hard fans will protest, but the insides don’t lie. The Microsoft Zune is a few Apple chips from being an iPod.”
By developing more its own integrated components, Apple could potentially save money, support new proprietary features, and throw copycats off its trail and force them to develop their own devices from scratch. As Apple blazes into uncharted territories by accelerating its iPod line into a new series of WiFi mobile devices, cost savings, differentiated features, and difficult to copy designs will all become increasingly important. PA Semi’s hardware expertise can help in that regard.
Driving up development costs for competitors is a lot more plausible in the commodity music player market, and in the market for handhelds in which slight price differences really add up. The idea wouldn't be to have coprocessors, but to replace the whole enchilada with hard-to-replicate tech, forcing competitors to build from the ground up, blind, using parts full of IP they don't own and for which they would pay a premium.
Take care,
--Tex.
