Apple Hedges Its Bet on New Intel Chips

Corrado writes "The Mercury News is reporting that Apple is still planning to use PowerPC chips well into 2008 for its low end and portable systems. Does this increase the "warm fuzzes" for the Intel move? More information from TheStreet and lots more links from Google News."

Comments

Re:All or nothing

[E-Lad]

The contract into 2008 is likely because Apple needs current and future PPC processors to fulfill support agreements.

You didn't actually think that Apple would cut off PPC users the moment that the last Mac model is moved to Intel, did you?

Registration-Free Link to article

[autojive]

Google Link and just click on the url that shows up on that page. Worked for me :)

Supply for support

[Novajo]

Apple has to support current computers with their Applecare program. Applesinsider has discussed that these go into 2008. So really, this is probably nothing more than the winding down period.

http://www.appleinsider.com/article.php?id=1248

Re:fat binaries forever . .

[remahl]

That is more than a rumor. That is exactly what the Xcode that was released on the day of the announcement back in July does.

Slightly OT

[TubeSteak]

But I'd like to give the /. ed's kudos for including a link to google news.

Its amazing how most news articles will not give you the full story, or worse, you get their slanted version of events.

Reading multiple articles (not something /.'ers are likely to do since we can't even get them to RTFA) lets you get all the facts so you can draw your own conclusions.

Just my 2 pennies

Re:They won't change from PPC

[Dominatus]

Heat? What the hell

The number one reason you havent seen a G5 laptop is heat issues. I don't see any problems running newer and newer x86 CPUs in laptops.

Hell the G5 towers need to be *water* cooled.

Furthermore, while the CISC/RISC business is correct every single report Ive read about the dev OSX86 machines (which are just regular P4s) are that they boot faster, perform faster, and are overall considerably faster than a G5.

Drop the argument, even Apple realizes it's dead.

Re:Hello bloat

[TheRaven64]

Here's one:

#!/bin/sh
ditto --arch i386 $1

That wasn't too hard, was it? Of course, fat binaries will only add a tiny bit to most programs, since the non-executable resources for most pieces of software are significantly larger than the executable portions.

Re:They won't change from PPC

[altan]

The Pentium M is lower voltage and has a lower power dissipation than the current line of mobile G4s. I too wish the PowerPC would continue, because it seems like a really elegant architecture, but Intel currently has the PowerPC beat in terms of mobile efficiency.

Re:They won't change from PPC

[Junks Jerzey]

PPC is one of the best platforms ever for both sound, gfx and of course heat production.

Is this based on more than just personal feelings about the architecture? Honestly, I like the PPC. It's a great implementation of the classic RISC principles: lots of registers, simple and fast instructions, no hardware stack, etc. But, really, this is just geeky fawning over a pretty design. The x86 is certainly ugly in some ways, mostly in terms of the huge legacy instruction set, but it's not so bad overall. Having hardware stack support is very nice. The limited number of registers makes function call overhead very low. If you disassemble code for typical PPC applications, you may see dozens of instructions for entering and leaving a function. And with each of those instructions being 4 bytes, that's a big deal in terms of instruction cache usage. So it's not entirely clear that in the modern world a classic RISC architecture is better.

and another

[fracai]

lipo -remove i386

Re:no need to panic...

[altan]

If you went to the trouble of optimizing your scientific/engineering/math/multimedia processing application to use Altivec, not only is it going to be a pain to port it to use vDSP or direct SSE instructions; Rosetta won't even run Altivec code.

Re:Hello bloat

[nsayer]

twice as much code

Actually, since we're talking about CISC vs RISC architectures, you should find that the x86 binaries will be a bit smaller than the PPC ones. So perhaps the code portions will wind up being 175% the original size. But a sizable portion of a typical Cocoa app consist of the NIBs and other non-executable resources, so you might find that a fat executable may take only an additional 50% or maybe even 25% on the disk.

Of course all of this applies only to Cocoa (will they even support Carbon-based Intel binaries? I believe they've already said they won't support Classic on Intel). Java apps won't care at all what CPU is running them.

Nearly all applications have a G3 code path

[diamondsw]

Thanks to G3's holding down the low-end of Apple's line for so long, nearly every app on the market has a G3 code path (otherwise you'd be dumping an awful lot of relatively recent iBooks, iMacs, eMacs, etc). Rosetta simulates a G3; the application will simply take the G3 instruction path and run fine, just a tad slower. Emulating a vector instruction set like that across platforms would have been hell, and likely slower than the G3 codepath in the first place.

Only applications that are G4-only will have any trouble (damn few outside of Apple, and theirs are already Intel optimized).