Intel PowerBook Rumor Mill

catdriver writes "AppleInsider has an article guessing about Apple's new Intel portable offerings in early 2006. 'With the initiation of the Intel Power Mac project last month, all five of Apple's Intel Macintosh projects are now said to be underway and moving at an exhaustive, yet fruitful pace. It should come as no surprise that Apple chief executive Steve Jobs is reportedly leading the charge, with his heart set on making 2006 the next 1984.' With Mac OS X for x86 now catching up to its PPC sibling, is Apple ready to take the plunge?"

Apple Intel Switch

[BWJones]

I am sure that there have been some issues, that I have written [utah.edu] about before, notably the porting of hand coded Altivec instruction sets to equivalent Intel specific instructions. However, the code bases between Intel and PPC have been pretty close to one another going back to the NeXTstep days. You do remember that NeXTstep ran on Intel, right? At any rate, the next step, no pun intended :-), should be interesting indeed. I am hoping for additional professional plans that Intel specific chips should allow, particularly at the subnotebook (or even Newton formfactor) level. I have been travelling more and even the 12in Powerbook, which has been the best laptop I've ever owned, is starting to be cumbersome.

Re:Apple Intel Switch

[Anonymous Coward]

i'm sure you read TFA, but maybe you missed the part where the the powerbook line will only have 15 and 17 inch models?

Apple wants to use the dual-core "Yonah", not...

[Harry Balls]

...the current "Pentium M Dothan".
Yonah is scheduled to arrive in January 2006, and will be followed in Q3/2006 by "Merom".
Most "Yonah" models are dual core, but a low-end model with only one core will be available. Apple will most likely opt to use the dual core "Yonah".

Merom will add 64 bits - yes, Yonah is 32 bits only.

Re:So THAT'S the reason?

[lababidi]

No, wrong logic. The fact that IBM could not pump out enough PPCs and could not keep down the G5 power consumption (getting too hot) was what prompted Jobs to switch to intel.

Altivec

[0xC0FFEE]

"Altivec programs" really aren't coded against Altivec instructions directly. For example, for doing a vector add, you'd use vec_madd() which, if you have Altivec, maps to the vmaddfp altivec instruction. If you move to SSE, you'd probably code against the same vec_madd() but the compiler would generate the correct instruction for SSE. So, if you've followed Apple's instructions, conversion should be relatively easy. Furthermore, most people simply use Apple's higher level libraries (ie, vecLib, etc) that embeds most of what numerical people would need (like blas or lapack).

Most importantly, Altivec, while really fast, only support single precision computations. This is sufficient for improving multimedia playback, applying image filters on photos or compressing music, but lacking for high-precision computations. SSE supports double precision, a big improvement for the scientific market.

Re:Will it cost more than a Dell running Windows?

[treerex]

Why does Apple still want to control the hardware? Why don't they just port to Intel and let vendors sell Intel machinces with licensed versions of Mac OS. It'll be cheaper.

Because they then control the drivers and save themselves from the driver compatibility hell that Microsoft has been going through for years. One crappy driver reduces the "experience of Macintosh," and that is not something Jobs would want to do.

No more 12"?

[intmainvoid]

Looks like the 12 inch Powerbook is disappearing from the lineup as well (and the 12" ibook is set to become a 13"). It hasn't had a proper update in ages, so the writing's on the wall, but it's a shame, and leaves Apple without a mini-notebook style product. Unless they've got something under wraps...

Re:Will it cost more than a Dell running Windows?

[zwilliams07]

> Why does Apple still want to control the hardware? Why don't they just port to Intel and let vendors sell Intel machinces with licensed versions of Mac OS. It'll be cheaper.

1. Because Apple is a Hardware and Software Business, unlike Microsoft. 80% of Apple's profits come from their hardware.
2. Increased development and debugging time to try and make it run on a vast selection of hardware which in turns makes it buggier, slower, and more driver failure prone.
3. Apple doesn't like the idea of Mac OS X, which is beautiful, running on ugly ass hardware.
4. Apple doesn't want to have to try and support everything under the sun, which is what Microsoft tries to do, but often never goes well.
5. Apple doesn't have any form of anti-piracy software in any of their current builds of the consumer level OS. Only the Server editions get that.
6. People would pirate OS X and take a huge chunk out of that measily 20% of their profit intake, take into consideration that already 80% of their profits would be gone, because of supporting other computers.

> I've often heard it said that Apple has priced itself out of the market. If they want a bigger market share they'll need to take advantage of cheaper prices that come through competition. My guess is that if Apple is allowing only specific hardware to run their OS it'll envitably be more expensive.

And those people that say such stuff are about as bright as a lightbulb in a closed fridge. Steve has repeatly said they have no interest in garnering a huge marketshare. They are happy with what they want. Take into consideration what would happen if all of a sudden they had a huge marketshare.

1. Suddenly troubleshooting and technical help services would have to multiply in their size exponentially to keep up with the market mass.
2. Suddenly they'd have to start supporting every piece of hardware under the sun that Windows does, because customers will whine.
3. Suddenly the OS will have a lot more attention from the cracker community, yeah cracker, not hacker. While OS X and all *nix systems are far superior in their security model than Windows, its still not crackproof.
I'd also like to point out if you looked at any of Sony, VoodooPC, Alienware, or other vendors... outside of that discount bargin crap stuff like Dell. You'll see that Apple's hardware is more than reasonable pricing.

I doubt that prices will rise. One of the biggest reasons Apple went with Intel is because Intel is the 800lb gorilla of the market. They can give HUGE discounts on their CPUs that AMD and IBM/MOTOROLA/FREESCALE just can't match. Not because of some "performance lead on the competition." Anyone that can put 1 and 1 together knows AMD clobbers Intel in the gaming, 64-bit, server, and price market.

Right now there is virtually no difference in hardware between OS X and the average run of the mill PC. Outside of the processor and motherboard, which will soon not be there at all. I'm pretty confident that the prices will either stay at their current level or drop down a bit.

Re:Will it cost more than a Dell running Windows?

[M. Baranczak]

Why does Apple still want to control the hardware?

Off the top of my head: One, because they make a good profit on the hardware. Two, because the limited hardware choices simplify OS development, and allow them to make the overall package more reliable.

I've often heard it said that Apple has priced itself out of the market.

This is business, not sports. Just because you're not the top dog doesn't mean you "lost the game". Apple is a niche company in the PC market, and they seem pretty comfortable in that position. 3% marketshare (or whatever it is) doesn't sound like much, but don't forget, it's 3% of a very large number. Apple has been making shitloads of money for the last five years, and will continue to do so in the near future.

Re:Altivec

[Pius II.]

That's very very dependant on your actual code. The gcc intrinsics mostly cover stuff that is also nicely optimized in Accelerate.framework: vector operations. But there are a few Altivec instructions which are impossible to map to SSE, yet they are widely used (IIRC, shifting by a variable amount is one of them). If you heavily depended on such instructions, you're basically SOL.

And Altivec is really fast. Keep in mind that OSX86 still uses the brain-damaged 32-bit mode, so the algorithms will be totally register-starved. That may be less relevant if you've designed for the architecture in the first place, but porting specialized assembly from an architecture with, what, >64 registers (r0-r31, f0-f31, plus Altivec), to one with 8 sounds like pure hell to me. Good thing I always used the frameworks (actually I just figured that Apple would be better at optimizing than me :-) ).

Re:It's so obvious when you put it like that

[coolgeek]

According to Apple's most recent quarterly results portables are outselling desktops. This is the actual (non-drug induced) reason why we'll see Intel-based PowerBooks before we see Intel-based PowerMacs. And I'm pretty sure we'll see the PowerBooks before iBooks, but that's just a hunch.

Re:could backfire

[funkcicle]

First glance you may say, good for apple, they still get the money. However, what that starts to do is move mindshare for apple to a premium hardware supplier, not a platform supplier.

But apple is a premium hardware supplier, not a platform supplier. OS X, in essence, is their loss leader that sells their premium hardware. Apple is a hardware company, period..whatever sells their hardware is good for the company, and good for OS X.

Re:Altivec

[jizmonkey]

porting specialized assembly from an architecture with, what, >64 registers (r0-r31, f0-f31, plus Altivec), to one with 8 sounds like pure hell to me.

If you're going to count the FPU and SIMD registers on the PowerPC, you need to do the same for Intel.

Re:Altivec

[Anonymous Coward]

Sorry, it isn't that simple. AltiVec is all about serious optimization, and the compiler isn't going to map the intrinsics for you -- Apple isn't even trying to do that, and it would be pointless for them to do so. These algorithms will need to be recoded from scratch. The lack of (2-way) double precision isn't as much of a burden as you think, and the 970 series has a pair of FPUs which matches it in a more flexible manner anyhow.

Re:No more 12"?

[Smurf]

Interesting wishlist. This one caught my eye:

4. Or, the ability to tell the OS to only encrypt certain files/directories, rather than have the loop-AES hack of FileVault -- I don't care if my ~/doc tree is encrypted, I do care that my ~/work tree is.

How's this for a workaround?:

• Create an encrypted disk image with Disk Utility. The size, whether it's a sparse image or not, putting the password in the keychain, etc, that all depends on your needs.
• Create a work folder in the encrypted disk image.
• Make an alias of the folder, copy the alias to ~/, rename the copy to work.
  

That way, you can work with what appears to be a ~/work directory, but in reality it will be encrypted. If you store the password in the keychain, you're set. If not, the first time you need to access that directory after logging in you just need to double click on the alias and enter the password. An added benefit is that you can unmount the disk image whenever your paranoid mind tells you that your laptop is in risk of getting compromised.

Re:So THAT'S the reason?

[DECS]

Short answer: The reason there is no G5 Powerbook is the same as why Dell isn't selling Xeon laptops.

Rant answer:
"G5" alphabetically follows "G4," but that does not automatically mean that a given processor architecture, hidden behind a simplistic marketing name, is appropriate for all uses.

The designation of G3/G4/G5 were arbitrary marketing simplifications for consumers. Each G# referred to a family of chips, some of which are appropriate for mobile, some of which aren't. Demanding a "G5 Powerbook" is one of the simplest knee jerk, ignorant battle cries I've heard in a while. Apple could have called the latest rev of Powerbooks the "G5 series" and been done with it.

Hell why not play like Netscape (or iTunes) and skip 5.0 entirely, and call the current band of anemic Powerbooks G6?

WHO THE FUCK CARES WHAT NUMBER IS ASSIGNED TO A MODEL?

Silly answer:
Having the current PowerMac G5 CPU bolted onto a PowerBook would provide 30 minutes of lap scorching fun.

Re:Should anyone be surprised?

[xjerky]

You're speaking future tense though. AMD *could* easily meet Apple's projected demands, they are *in the process of building another huge fab*, and that may very well turn out to be the case, but do you think Apple want to rest their entire future on what *could* happen?

Granted, Intel's new notebook-level chip is not out yet either, but past performance has likely shown Apple that Intel can be relied upon to not screw up the supply chain at least. Plus I would imagine that Apple's already seen this not-yet-released chip in action, so they have even more reason feel more confident about going Intel instead of AMD.

Re:Altivec

[ravyne]

All the production Intel Macs will be 64bit capable. Theres absolutely no reason to support a 32bit code base on intel when its on its way out. Bet your bottom dollar that the consumer Intel OSX will be 64bit, which has 16 registers. Eight might be a little tight for some programs, but I'd bet that most programs don't even make use of more than 16, let alone all 32.

Microsoft and Adobe have already committed.

[Anonymous Coward]

The CEO of Adobe and the manager of the Mac division of Microsoft were both at the Apple event in person, to assure everyone that they have committed to making universal binary (PPC and Intel) versions of all of their Mac products. I watched the keynote, it was cool seeing those people standing beside Steve Jobs.

Re:What about applications?

[Anonymous Coward]

You seriously underestimate the power of a G4.

Re:What about applications?

[Anonymous Coward]

hmm -- remember "fat binaries"? This was the same concept as universal binaries -- both 68k and PPC code in one file.

Re:What about applications?

[Anonymous Coward]

Uh ... You realize that Rosetta only emulates a G3 [apple.com], right? And that it's painfully slow?

The reason the apps seem to run quickly is that the nibs only need to be translated once. On a 3 GHz P4, you could hope for the performance of possibly a 900 MHz G3. It'd probably be closer to 750 MHz.

Re:1984?

[Baricom]

They keep their DRM in place, and they get access to sell the music in the catalogs. No other online music seller has said access.

I think you forgot [napster.com] a [yahoo.com] few [rhapsody.com].

Re:A laptop for all your work? Blech.

[Scudsucker]

My primary work machine (which costs less than any half decent laptop you can buy) is a desktop class system with 4 GB of ram, 2 CPU's, plenty of fast SATA drive space and a comfortable keyboard and mouse.

So what? You'll be able to get all of that with a Mactel Powerbook if it's a dual core, with the possible exception of the 4 gigs of ram. You can plug your mouse, keyboard and monitor into your laptop just fine...in fact some companies made docks for those periphreals so you could plug them in at the same time. You can buy external RAIDS for Firewire 800, or you can use the gigabit ethernet to connect to a fileserver.

Re:I don't understand

[hr raattgift]

SBCL w/ Threading on OS X!? Dare I dream!?!?

What are you writiing in Common Lisp that is processor-dependent?

Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL [clozure.com] you'll find it has a kick-ass compiler as well as a fully preemptive thread [clozure.com] scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"

In fact, I'd almost reverse your wish and dream for cross-platform OpenMCL Cocoa Programming support [clozure.com].

But then again, I'm one of those evil Schemers...

I think my wish is a little more likely, despite little things like the register model [clozure.com] and other implementational "details" that are compiler-specific. There have been enough good x86-targetting Lisp compilers to borrow ideas from that I don't think the compiler itself is the critical path.

As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.

While the free CL developer community is small and gets along reasonably well, and ideas (and people) seem to leak back and forth among the various projects, I think OpenMCL has it a bit easier because of the familiarity with SBCL and its antecedents and their compilers to Gary Byers and company, as well as being able to do a port with knowledge of how to use modern x86 chips' register handling. Starting with a thread-safe accurate generational collector makes many aspects of a CL implementation much easier, and not targeting the most primitive 386 ISA will also help with performance.

Underlining my thinking here is that according to the SBCL wiki [cliki.net] PPC-port threading is wating on the port of the conservative collector. This is probably the shortest path to threading, but when you could use register-to-register tagging, boxing, mask-and-match against most-common-values, and other goodies that having lots of registers support, it doesn't seem anything like the optimal path.

However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?

If the peculiarities of SBCL favoured its use for a performance-sensitive application, I'd use it under that app. (This could happen easily enough... lots of non-consing/non-recursive arithmetic on |big| integers, for example, would obviously favour implementations where |big| is fixnum over implementations that robbed bits from fixnums to provide an accurate rather than conservative GC). If another CL implementation ran it faster or better, and it mattered, I'd use that under the app.