Didn’t he bring a developer out to testify about how easy it was to port Mathematica in only two hours?
I don’t think the transition will be nearly as hard as the 68k->PPC shift. I still remember the simplest 68k programs taking 30-60 seconds to load on early PowerMacs (the ones with the startup noise that sounded like brass knuckles on a chalkboard).
You weren’t reading carefully. Cringely acknowledged Intel’s 64bit chips right in the question:
Which does indeed miss 64bit Celerons, but I hadn’t heard that announcement either. And Xeons currently are pretty expensive for desktop use; Apple would need to ship $2-3k machines with current chips (my most recent dual-Xeon box cost $5k). Which I guess works right in with Apple’s target price points. 
A couple of further thoughs:
Well, of course you and I know that. But I think there’s many a Mac-head out there (I’ve known a few) that would spout Apple’s line that a G5 is “twice as fast” as a PC and believe it. Cringely raises an excellent point here: the cognitive dissonance should be palpable surrounding the performance issue reality vs. years of Apple marketing.
Cringely said Pentium was “hardly mentioned”, then used that as a springboard to speculate which Intel CPU chip might be used in a Mac. And he’s correct: we don’t know precisely what chip (other than some flavor of Pentium thing) will be in a shipping (not development) IntelMac, or really a lot of other details about what a customer might purchase.
And there have been others in this thread wondering if Apple might use AMD at some point. Was this also “laughable and misinformed”? Come on, it’s not a bad observation. RXC’s eventual conclusion was silly, but this point isn’t.
I don’t understand what Cringely’s point was here (“a system which apparently doesn’t benchmark very well, either (it’s in the links)”) – I didn’t see a benchmark of the dev system in the links; maybe it was in Job’s keynote, which I haven’t sat all the way through.
As I stated, 90% of the applications should provide no problems. But several of the biggies, photoshop for instance, are going to require MUCH more work than that. And theres simply no chance of anyone moving en masses to a Intel based platform if the major blockbusters like photoshop aren’t availible. You have to be able to see around the SJPRDF (Steve Jobs Personal Reality Distortion Field) for a second to get to the meat of it. According to Steve Jobs, at the same time, apps are going to take a couple of seconds and an extra button click to port to x86, on the other hand, developers need to start early because otherwise they won’t be prepared on time. The reality of the issue is that if the program was written correctly and without using any macintosh specific features and using Apples xcode rather than Metroworks codewarrior. Then it should in theory be easy to port. Any application that runs of a substantial size and doesn’t conform to these constraints is going to be a bit more work. In the worst case for applications that dig deep and access the CPU directly via assembly code, it’s going to be as if you had to re-write the application from scratch. This is why They are announcing a 2 year switch over. While the vast majority of applications on the market should be fine, I bet there are a lot of scientific apps run on clusters that specifically depend on Altivec functionality which would require a massive porting effort.
Cringly Acknowledged the Xeon and Itanium and then dismissed them off the bat. He didn’t even mention the 64 bit pentium 4. The P4, Xeon and Itanium are radically different lines, as SJ said, the new macs will be using a P4 or whatever the incarnation of it is in 2006. Probably a dual core Pentium D. As such, his criticisms about the 64 bit cpus being “too expensive” are completely full of it. The new macs will use CPU’s commesurate with a similar Windows machine. Most likely, the top of the like powermacs will use dual, dual core Xeons or something similar, the bread and butter machines will use moderately high end P4 equivilants and the imacs will use 64 bit celerons. His entire argument is groundless.
Yes, of couse, thats the magic of the SJPRDF. mark my words, in 2 months time, mac heads will be arguing about how archaic and obsolete the Power4 architecture was and how IBM publically made statements about how they didn’t care a whit about Apple and how the new Intel relationship represents an exciting new future. Don’t try to explain the SJPRDF, just embrace it for what it is. The Party loves you, The party cares for you, Do your best for the party.
Did you click that link I provided? It’s a freaking picture of steve jobs and a giant screen with the words Pentium emblazed on it. If that counts as barely mentioned, then World War II was a bit of unpleasantness back in the 40’s.
No, the people speculating in this thread about why Apple wen’t with intel all provide several good reasons why this was a rational decision. Cringly is laughably misinformed because he presented this as an inexplicable conundrum. All of the reasons that were presented could be the reason why apple chose intel, and, indeed, probably all of them are, even maybe cringlys assertion. But the laughably ignorant bit is to completely ignore all the perfectly good reasons Intel was chosen over AMD.
I confess, I didn’t chase this up directly, this was brought to my attention with the slashdot post. The “benchmarks” he claims to link to show the performance of the P4 system running rosetta vs the G5. It’s purpose was to show that the emulation was so good that a P4 could run apps “almost” as fast as the G5. But Cringly is trying to present them as indicative of performance on the P4 for ported apps which is just plain wrong. In all likelyhood, because these are apple benches, the actual rosetta will be quite a bit slower, but that’s not the point. The point is he’s trying to use a benchmark which trys to compare one thing and representing it as comparing another.
I’m not saying Cringly’s wrong, he may very well be right. But I’m saying that his conclusion isn’t supported by his arguments so even if he were right, it would be sheer dumb luck. It’s like bible fundamentalists saying that science proves the bible correct because Genesis said god created the universe and scientists have shown the big bang meant the universe was created at some time. Sure, the two facts agree with each other, but it in no way means that the process behind them was correct.
Yes, Mathematica was apparently an easy port. Of course, most of Mathematica is actually run in the Mathematica language, so the percentage of Mathematica code that would have to be “ported” for binary compatibility is quite small, comparatively.
I don’t think it will be, either. For one thing, the OS will actually be ready. We didn’t get a fully Power Mac Accelerated Mac OS until version 8.5, some four years after the start of the 68k to PPC switch. Mac OS X is going to be Intel-native from day 1. That’s a major step up.
I wonder how much of Photoshop will really have to be reworked. I also wonder if any endian issues in Photoshop can be addressed by bringing over code from the Windows version. In all, though, I doubt that any programs will face as big a hurdle coming from PPC Mac to Intel Mac as they did coming from Mac OS to Mac OS X.
Well, I’d say a majority of Apple’s installed base doesn’t care about Photoshop. They’re the folks buying the low end machines, the ones that are supposedly going to be switched over first. In two years, when Power Macs are going to Intel, Creative Suite 3 will be out – that gives Adobe an entire software cycle in which to do the conversion. I’d imagine that’s very doable.
I think you mean “PowerPC-specific” features. Mac-specific features – ie, ones that tie into the Mac OS – will not be a problem with this port. In fact, if developers have been using Apple’s vector library instead of writing to AltiVec directly, they should be in a good position in that regard, too. Apple’s been pushing XCode hard for a couple of years. We’re now learning why.
Or port over Intel code fom your Windows version, if you have one. I doubt many programs write directly to the metal anymore. Mac OS X makes it hard to do so.
Well, huge chunks of it are using altivec which means that all of that will have to be either brought in from the windows version or re-written depending on which is easier. Either way, it’s a non-trivial port (The windows version might use DirectX functionality or COM for example).
No, but chances are, that there will be at least 1 program that each person uses that would be difficult to port, even if it’s a different one for each person. And even if there was none, people would delay on the offchance that they might eventually one day want to use photoshop. In order to create that confidence about the switch, 99.99 % of applications have to be ready so nobody hesitates.
The reason they are using altivec is probably because they care about performance and a straight API switch isn’t going to work in this case. They will have to retune their algorithms to work more efficiently in x86. Even non-altiveced PowerPC code might need to be rejiggered because cache sizes, memory bandwidth, pipeline sizes etc have all changed.
I’m talking about purpose built scientific apps which aren’t designed to be cross platform. Their sole aim is to run as blisteringly fast as possible and as blisteringly close to the metal as possible and damn the difficulties.
I’d vote malarky. Steve Jobs would have to be dead and buried before he lets himself get ousted as CEO of Apple, IMO. Or, as he has allegedly said, “I left this company in the hands of an idiot once; I’m not going to do that again.”
To be fair, a lot of this is just the same kind of marketing bullstuff every CEO says; try getting Bill Gates to say something negative about Windows, for instance. Jobs just does a better job (heh) of selling the bullstuff than most folks do, via very subtle application of pacing, word choice, and framing.
As for porting Photoshop, my understanding is that large parts of it are already platform-independent, to enable Adobe to keep it feature-identical across platforms (I’ve heard that Photoshop doesn’t make any use of Altivec, for instance). It does have some legacy “cruff” Carbon code in the Mac branch, but I suspect it’ll only take a few weeks to port that for MacIntel-compliance.
Photoshop benefits from AltiVec more than almost any other app. besides those produced by Apple, and this has been true for years. AltiVec optimization is probably the biggest reason why G4 and G5 machines can easily outperform equally-clocked Intel machines on a number of tasks (dual Xeon machines and P4’s with hyperthreading are no match for PPC’s on a cycle-for-cycle basis even on tasks that don’t benefit from AltiVec, but for those that do, they get roundly stomped. P4’s need to be at least half-a-GHz higher-clocked before they can hold their own in head-to-head comparisons using many Photoshop benchmarks).
It’s also easy enough to find benchmarks where slightly-faster Intel chips do very well compared to PPCs. AMD chips are consistently more impressive on a cycle-for-cycle basis than Intel desktop chips; but AltiVec optimization does give the PPC the clear upper hand in some cases. Check out BareFeats for some good tests.
I don’t see any comparisons there between AltiVec and SSE. I’ve heard a lot of hyped-up claims about AltiVec’s advantages, but no real life confirmation so far. SSE plugins for Photoshop on x86 seem to give about the same improvement as AltiVec plugins on PPC.
Mark my words: the PowerBook and iBook will be some of the first lines to get the x86. Apple needs upgraded portables, especially now that laptop sales are bypassing desktop sales. Intel’s Centrino mobile platform is the best mobile solution right now, and so a Centrino-based PowerBook (with the latest Pentium M) will be one the first Macintels.
I’d say the Mini and maybe the iMac will be the first desktops, maybe with the laptops. The PowerMac will be a few months behind, and the Xserve will be last (probably using the Xeon.)
Itanium is radically different. Xeon and P4 don’t differ very markedly; the former is a workstation/server chip, but the instruction set is the same as the latter. I’ll concede the rest of your point – I wasn’t aware that Intel had yet announced 64-bitness on the pedestrian versions of the P4.
[/QUOTE]
I can speak from some experience that much of the Altivec code in Photoshop is in a set of bottleneck functions that already exist as x86 SSE (Win), Altivec (Mac), and straight C (for reference) versions. It shouldn’t be a big deal to just turn the switch for the MacIntel version and use the existing SSE code from windows. There may be some issues with BGRA vs ARGB colorspaces when displaying the output or exporting.
I think you meant SSE. DirectX and COM aren’t comparable technologies to altivec (unless you meant GPU processing via DX interfaces?).
Agree here, although the C compiler takes care of a lot of this if the optimizer is doing it’s job. Well, one can hope. But it can involve trial and error and looking at the dissembled output to see if the code is optimal. You wouldn’t take the time to do this sort of tweaking for anything but very core rendering functions.
Unfortunately, IMHO the vast majority of applications are not using XCode, they’re using CodeWarrior. For small apps, the conversion may be trivial. For large apps it could be a task of some weeks, minimum, to get the app to just build.
This is correct. It was made x-platform probably 10 years ago, although platform-agnostic code is a continual labor, not a goal you reach and are then done.
You’ve heard incorrectly. Sorry.
Off-topic:
“Kill(e)” is Dutch for riverbed or channel.
Good thing they don’t have a plant in Beaverkill! 
Y’all may carry-on. 
I thought most of Altivec’s advantages were on the developer end; it was supposedly a lot easier to tap into, whereas an x86 developer would have to work a lot harder to get the same improvements.
Well, perhaps part of that ease is the fact that Apple includes a Cocoa API directly designed to send code to AltiVec – Vector Framework or something like that. Any developer using this Cocoa API will have no problem with the move – the effort to link that API to SSE as opposed to AltiVec will fall on Apple, who if they’re smart has already done that work.
I’m only responding to this because it kind of bugs me – in your opinion the vast majority of applications are not using Xcode… huh? How can you have an opinion about a fact. It’s either true or it’s not. According to Jobs’s presentation (not necessarily the most reliable source of information), the vast majority of developers were either moving to Xcode or already there.
Most of my apps are Cocoa, and many of them have already been recompiled into Universal Binaries, so I’m not too concerned. I intend to keep my G5 until 2008, in any case. I’ll be buying a Mactel laptop as soon as they come out, but that won’t be my Adobe machine.
To be fair, Jobs’ slide indicated only the percentage of Apple’s top 100 developers that had migrated to XCode. Given that XCode is only a few years old, I’m sure that the majority of extant Mac software — not necessarily the apps people rely on day-to-day, but all the oddball apps lurking in the dark corners of Version Tracker — was built in Metroworks (or RealBASIC, or Hypercard, etc.). It’s likely that quite a few older apps won’t make the transition to x86, but most likely wouldn’t be missed, and would survive well enough in Rosetta anyway.