re Pixar
Pixar has supported MacOS X with things like Rendereman, and I'm betting they have a cluster node client for doing networked cluster crunching, and maybe it's even built on Apple's XGrid. The only reason I was talking loudly about Pixar going to Macs in the future was that I saw credits to Sun in an early Pixar flick, and heard Jobs gritching about signing a PO for a Dell purchase.
I never saw the evidence Pixar had gone Mac, or evidence against it, and by now that's Disney's problem. Whether folks with cluster computation issues go with Macs will depend in the future on things like energy-efficiency issues (which may not have a lot of variation if folks all use Intel parts, but who knows what clever use of heat sinks or coprocessors or load-sharing with GPUs might yield), price issues (a place Apple might have an edge on a MSFT solution, but maybe not a Linux solution, if everyone is building machines from similar parts), and sheer performance. It's this last place that tech like Grand Central may be able to help Apple saturate cores better than MSFT solutions. Serious users will probably be able to build implementations that can saturate cores on Linux, though making it easy to ensure it's done version after version may give some weight toward a systematic approach offered by Apple.
I think that looking at the credits of the movies is likely the best idea I have short of breaking into Pixar with a camera. I know it'd Disney now but the acquisition promised Pixar its own campus, name, etc.
It's gonna get very interesting if this multi-core advantage is substantial - can Microsoft come up with something similar, or are they just too bloated to turn fast enough? With rising energy costs, this *could* be big (if we are talking *big* improvements in performance/watt).
Microsoft may be trying to retool the guts of the kernel to solve performance problems in Windows 7. My concern for them is that the APIs -- on which the installed app base depend and on which upgrade traction will depend -- were designed in an era in which Microsoft was trying to build a high-performance UI in the age before big GPUs, and has a bunch of UI stuff in the kernel (for example). Thus the kernel is involved many places where it'd not be involved in a Unix/Linux system, and bottlenecks get exposed. There's a tradeoff between granularity (the number of different kind of things you can safely try at once in the kernel) and performance (all the stuff you do to make the locking and resource-sharing happen between parts of the kernel eat processor cycles), and Microsoft may have a hard time getting the balance "right".
When Apple wanted to move forward, Apple basically told folks the old MacOS 8 API was going to be replaced with a subset, and retooled in a way that would enable future growth. Microsoft has given folks dotNet, but it hasn't warned folks off the old API that I know. And Microsoft hasn't seemed to give people a clear migration to 64-bit, either -- there's 32-bit, there's 64-bit, and there's 64-bit OS that gives 32-bit code an emulation experience (that I read works pretty well regardless its theoretical drawbacks). Migrating people to 64-bit, and the future, might be a trick from where Microsoft now stands. Microsoft may have to do what it's long fought doing: tell people their code is going to be broken by an upgrade in the name of future development.
When Apple dished out this bad news, it softened the blow with Carbon, but there was still griping if you recall -- and it took Quark and Adobe a long time to deliver Carbon apps (MacOS X versions).
Honestly, we could be making a mountain out of a molehill. There may be such power and performance in future hardware that Microsoft can offer a huge array of compatibility modes, ancient APIs for needy applications, and pretend-kernel-calls for applications that still expect 1995 behaviors -- and yet still make it look just fine to Joe User. Microsoft does have a lot of smart folks. I've wanted to count the days the firm had to survive on its nasssty evil plans for some time, but the near term doesn't show evidence of it.
And MSFT can keep dotNet a moving target just like it kept Win32 a moving target, and prevent things like dotGNU from accomplishing today what IBM tried and failed to accomplish in 1995 (easy migration from Redmond to the Blue Team). Just like Microsoft hasn't yet released a file format specification that will let third parties do with MS-Word documents what Microsoft's applications can do.
Take care,
--Tex.
News 
Market Data 
Discover 
AI
