Apple Secretly Maintaining x86 Port Of Mac OS X

Earlybird writes "According to this eWeek article, Apple has ported the whole of Mac OS X to the x86 architecture and is maintaining it in parallel with the PowerPC builds. Dubbed Marklar, the project is perceived as a fall-back plan, and, quoth the article, 'has apparently gained strategic relevance in recent months, as Apple's relationship with Motorola has grown strained and Apple looks to alternative chip makers.'" Believe what you will ...

Comments

Nope.

[Anonymous Coward]

If it's not on KaZaA, it doesn't exist.

Re:Nope.

[TerryMathews]

While the above comment was made in jest, I would have to agree here. If this port of OS X isn't on KaZaA or some other P2P network, it doesn't exist. Apple builds for OS X for PPC get leaked onto P2P left and right. Short of Apple Security being more ruthless than the SS in WW2 (And since we haven't heard any horror stories like there are about Intel security...), I don't believe this story for a minute.

Re:Nope.

[antijava]

Actually there is an Intel port. There has been for years. Way back in the Rhapsody days there were two developer releases available for Intel. Just because they stopped making them available doesn't mean they stopped building it.

The biggest reason is that maintaining an Intel version ensures that everything they write stays reasonably portable. It they can stay compatible with PPC and Intel in the code, than supporting any other chip that comes along can't be much more difficult.

Internal builds used to always be built fat...they would just be stripped to PPC-only when it came time to press to a CD for external use. I don't know if it's still the case, but I don't see why they would stop the practice.

Also, maintaining compatibility keeps future migration options open to them.

Most of OS X is highly portable already. The kernel is Mach, which was fundamentally designed with portability in mind. Above that is the BSD layer which is regularly synched with the OpenBSD source tree, which is x86 code -- so it's portable. CoreFoundation is part of Darwin, so it already compiles on x86. Cocoa is very high level and used to run on x86 back in the OpenStep days...no big issues there. I see no reason why Cocoa couln't easily go to Darwin as well. Apple had to basically build the Carbon library from scratch after the developer community refused to migrate en-masse to Cocoa. I don't believe Apple would be short-sighted enough to not write it in a portable fashion. Really, Classic is the only part of OS X that would cause a problem with an x86 port. If push comes to shove, Apple could just draw a line in the sand and say that Classic isn't supported...developers have had enough time to move their stuff forward.

Of course, just because the port is possible doesn't mean that Apple will ever make it a product. Support for such a thing would be a nightmare given the huge number of hardware options in the x86 world. Apple is barely capable of keeping up with drivers for there exremely limited set of hardware options.

Stick with PPC

[Microlith]

If they can't stick with Motorola, they should go with IBM.

It's one thing to go from 68k to a more powerful PPC architecture. It's another issue altogether to move from a PPC to an Intel or AMD cpu. The emulation speed would be a hell of a performance hit.

Re:Stick with PPC

[Stephen Samuel]

Nobody said anything about emulation. A port is a native compilation, and therefore no performance hit is taken.

When Mac went from the 68K to the PPC, they included emulation software, do that the PPC could still run the 'legacy' 68K code. Because the PPC was enough faster than the 68K, the emulated code still ran with 'reasonably acceptable' speed.

Intel isn't much (if at all) faster than similarly timed PPCs, so trying to do a PPC emulation on an Intel CPU would probably be a horror story.
(the '386 architecture is also not quite as elegant as the PPC architecture. Most of the registers would have to be stored in RAM, and that would hurt you BIGTIME).

Re:Stick with PPC

[dattaway]

Looking at the PPC instruction set, it looks a little more robust than a "reduced" instruction set to me. They all look CISC, except for the old favorites, such as the 6502...

As far as which is better depends on your assembly language preferences. I prefer accumulator arithmatic of the RISC, but since we use compilers these days, this point is moot.

Re:Stick with PPC

[MaxVlast]

He's thinking about when Apple went from Motorola 680x0 chips to PowerPC ones. The OS had a 68k emulator that allowed it to continue to run old apps. The poster is expecting that if Apple releases an OS on x86 hardware, the OS will include an emulator so granny won't then wonder why her old recipe application doesn't work on her new computer.

As someone who's been if a few multi-architecture operating systems (BeOS, OpenStep, NEXTSTEP), I can say that it isn't as pleasant as everyone says. While OpenStep made it pretty easy to cross compile, there were always apps that just weren't available for your platform (particularly NEXTSTEP for HP Apollo machines.) It's not a good place to be, and it is always frustrating for users. How many PPC BeOS apps were there when the BeOS stopped being something a lot of people did? Certainly not as many as there were for Intel.

My basic point is that it will be a major pain in the ass for all of the users for gains that aren't yet a big enough deal to convince me.

Re:Stick with PPC

[Zero__Kelvin]

"PPC = RISC architecture


x86 = CISC architecture


RISC > CISC


therefore PPC >x86"

Your missing a key element in your formula, even if I grant the mistaken RISC>CISC part. Intel != x86. For example, the intel StrongARM processors used in the iPaq are RISC.

Re:Stick with PPC

[Zero__Kelvin]

"That is classic Ad Hominem to those that know logic and critical thinking class material. Attack this guys point, not him as a person ... it's a fallacy."

This is by no means such a case. I attack his point as wrong. I merely go on to point out what his being wrong, an the manner in which he is wrong, says about him. At no time do I suggest that he is under-informed, and therefore wrong. I state that he is wrong, and therefore under-informed. Will the real Dr. Pascal please stand up .....

Re:Stick with PPC

[mentin]

Another fallacy. RISC chips can usually attain significantly higher clock speeds than CISC chips, but at the expense of doing less per clock. This does not make either one automatically "faster" in terms of total computational power, just different in their approaches to speed.

Absolutely right.

And when you consider current clock speeds (~2.5 GHz P4 chips vs. ~1.2 GHz PowerPC chips) multiplied by PowerPC doing less per clock, you get the picture.

Although situation is not that bad, P4 is somewhat faster than PowerPC now.

Re:Stick with PPC

[mindstrm]

Okay
So let's see
Your 100MHZ PPC chip is faster than my 2GHZ P4 because yours is risc?

This is the #1 most common thing mac freaks say.. that it's better because it's RISC.

RISC is better as a *technology*... that doesn't mean a RISC chip is inherently better than a CISC chip.

That's like saying Diesel is better than gasoline.. so a diesel vehicle is faster.

Re:Stick with PPC

[beebware]

Bit of history. Admittedly the StrongARM is made by Intel now (after they brought Digital who previously made it), but the ARM core technology inside it is still (c) ARM Plc who are a totally independent company selling to a wide variety of chipset manufacturers. ARM, themselves, are NOT owned by Intel.
Apple, IIRC, have around a 25% share in ARM (Advanced RISC Machines, but used to be Acorn RISC Machines when they started out, but Acorn has been 'defunct' for 2yrs+ now as soon as it was realised that the Acorn Group PLCs share of ARM was worth more than the total share value of Acorn :( ).
StrongARM chips were originally used in desktop machines, I've got a 202Mhz SA in my Acorn RISC PC desktop machine - admittedly it's around 7 years old now, but in it's day it was a damn good machine: Acorn themselves (not ARM) weren't very good in marketing...

Re:Stick with PPC

[mindstrm]

You forget that, due to the nature of Apple's solid APIs and the fact that OSX is BSD based...

All the developers will have to do little more than re-target and recompile. Very little work involved, relatively speaking.

Why would a Carbon app need to be significantly modified to compile on an x86? Does an app for Solaris SPARC need heavy modification to run on Solaris X86? No, it doens't, it needs, well, no modification whatsoever, it just compiles.

Same thing here.

Yes, they would need a new emulator for classic apps.. but many of these already exist for x86, they could probably purchase code if they don't want to do it themselves. it would be no harder than writing one for PPC. PPC and 68K do not have any kind of inherent compatability.

Re:Stick with PPC

[zapod4]

Do macs have parallel ports?

Re:Stick with PPC

[rschroeder]

My understanding that Carbon apps contain enough legacy code that recompiling wouldn't be an option.

Cocoa apps, on the other hand, are ready to go.

it's the whole yellow box v. blue box thing.

Re:Stick with PPC

[nutshell42]

The trick is that modern cpus split the data in a number of instruction pipelines where a number of instructions gets processed in line.

a P4 has 4 pipelines with 20-stage pipeline, a PowerPC 7 pipelines with 4 steps afaik.

Long pipelines are better if you want high clock speeds therefore it looks like intel will be able to push the p4 design beyond the 4GHz

but the PowerPC design is more efficient; say the processor is not able to fill a pipeline at one clock cycle, the PowerPC will lose one working step for 4 cycles, the p4 for 20, the same problem occurs if the jump prediction fails.

But as AMD had to learn with the Athlon (which is afaik similar to the PowerPC in this design point) a P4 may be inferior at the same clock speed but that's meaningless if Intel is able to reach 800MHz (Athlon) to 1GHz (PowerPC) more.

Re:Stick with PPC

[dorzak]

This may be an over simplification, but isn't Carbon/Classic essential an emulator on OSX of the pre-BSD based Mac OS's?

Cocoa then being the native OS X/BSD based apps.

Re:Stick with PPC

[bnenning]

No, all PowerPCs that have shipped in Macs have 32 bit integer registers. They have wider floating point and (sometimes) vector registers, but so do x86 processors.

It is true that PowerPCs are faster per-cycle than x86 chips, partially due to having *more* registers.

Re:Stick with PPC

[larkost]

Neither is technically an emulator, in the same way that WINE is not an emulator.

In Classic, MacOS 9 is running, but taking a number of services from the host MacOS X system through a number of special extensions. All classic apps would need an emulator (if the vendor has not rewritten for Carbon.. there is no chance they would recompile for x86).

In Carbon it is a native application, but much of the code (both in applications, and in the equivalent of shared libraries) is very PPC specific, and would probably need an emulator o be commercially viable.

Re:Stick with PPC

[larkost]

1-3 cycles of access time would kill performance. This is one of those huge differences between PPC and x86, an emulator would constantly he hitting this wall... remember things in the registers are a 0 cycle cost.

Re:Stick with PPC

[ncc74656]

Why would a Carbon app need to be significantly modified to compile on an x86? Does an app for Solaris SPARC need heavy modification to run on Solaris X86? No, it doens't, it needs, well, no modification whatsoever, it just compiles.

It depends on the app...if you have any hand-optimized assembly language in your source code (which you will if you're using MMX, 3DNow!, or SSE...or (presumably) AltiVec, since we're talking about code originating on a PowerPC-based machine), you'll need to rewrite that section of the program.

Re:Stick with PPC

[PythonOrRuby]

Actually, as far as I know, hand-crafted PPC assembly is not necessary at all to optimize for the Altivec instruction set. Last I heard you simply used C functions like vec_add() and such.

This is not to say that rewriting the Altivec libraries to map to any of the x86 SIMD units would be easy, but it's easier than if everything were in assembly.

Re:Stick with PPC

[Pig Hogger]

When Mac went from the 68K to the PPC, they included emulation software, do that the PPC could still run the 'legacy' 68K code. Because the PPC was enough faster than the 68K, the emulated code still ran with 'reasonably acceptable' speed.

This is because in any given Macintosh application, some 95% of the code is OS code, and only 5% is application code.

The OS code is, of course, compiled for the PPC chip, whereas the "legacy" application code is emulated. So, you end up with only about 5% of the code being emulated, which explains the 'reasonably acceptable' speed.

Re:Stick with PPC

[RedWizzard]

P4 has 4 pipelines with 20-stage pipeline, a PowerPC 7 pipelines with 4 steps afaik

Pretty much right. The G4e has a 7-stage pipeline, and is able to fetch 4 instructions per clock. But don't get too hung-up about pipeline lengths and execution unit numbers. Pipeline lengths do allow faster clock speeds, and result in higher stall costs, but that's only a small part of the puzzle (comparable to saying the only thing that matters about car engines is the number and size of the cylinders). Scheduling, branch prediction, cache size, etc, are all also important. Ultimately the only thing that counts is user-level performance.

Re:Stick with PPC

[MaineCoon]

Big difference... Especially endianness - that is, byte order of multi-byte words (2 byte shorts, 4 byte longs and floats, 8 byte long longs and doubles).

The 68k was big endian, and the PowerPC on the Mac runs in big endian mode. x86 is little endian. Big endian is when the byte order for a number goes most significant to least significant byte. Little endian is the opposite.

Examples:

1 (0x00000001)
Big endian: 0x00 0x00 0x00 0x01
Little endian:0x01 0x00 0x00 0x00

4096 (0x00001000)
Big endian: 0x00 0x00 0x10 0x00
Little endian:0x00 0x10 0x00 0x00

305419896 (0x12345678)
Big endian: 0x12 0x34 0x56 0x78
Little endian: 0x78 0x56 0x34 0x12

Likewise... if one has a 4 byte integer in memory, and assumes it is within 0-255 (or -128-127), little endian processor, treating that pointer to the integer as a pointer to a single byte, will work properly. Big endian machines requires offseting the pointer. This is, of course, bad coding, but it happens nonetheless.

Suddenly all binary data files need translation to work... any code that makes assumptions about byte order doesn't work (such as optimized code for handling byte streams of data in chunks).

A major part of my job is doing conversions of software from Windows to Mac (games specifically), and handling for endian conversions in file read/write and network transmission, and fixing code that is specific to little endian byte order, is a not an insignificant part of the work.

This means that now a lot of code has to be changed/fixed/whatnot, but also a new testing cycle. And if you think getting a lot of developers to just recompile is a pain (and it would be)...

- Chris Jacobson

Ported all of Mac OS X to x86?

[qslack]

They have ported all of Mac OS X to x86? Not just the kernel?

Let's pool $100,000 (Blender-style) and bribe the guy who runs their internal CVS repositories. Anyone wanna throw in a few bucks for macosx-x86-0dayl33t.iso? :)

Re:Ported all of Mac OS X to x86?

[Ikari Gendo]

One thing that I haven't seen commented on is that the Finder is a Carbon application -- Jobs specifically claimed this as an example of "eating one's own dog food." This means that unless they've rewritten the Finder in Cocoa, or ported Carbon to this alleged x86 build of OS X, the story is as groundless as all other similar stories.

The article strongly implies that Carbon has not been ported to "Marklar," as in the following:

Apple would have to also coax most of its third-party developers to rewrite their applications from the ground up in the company's Cocoa application environment.

But if there's a Cocoa version of the Finder, why haven't we seen it? (Be aware that I'm not a Jaguar user, and don't know if the Finder is Cocoa in the most recent release.) However, given these points:

• The Finder is written in Carbon.
• Carbon is not part of Marklar.

any claim of a fully-featured x86 OS X is bogus.

Re:Ported all of Mac OS X to x86?

[BitGeek]

Finder is both a Carbon application and a Cocoa application. At least the one on my Jaguar install is. Which means technically its a cocoa app (From what I can tell) but it still links in a lot of carbon code.

But then, most programs are. Its very difficult to write a cocoa application that doesn't hit carbon (Even though you don't link against it) and vice versa... for instance printing is done by carbon, even for cocoa apps.

Carbon is part of OSX and is going to stick around (much as I prefer cocoa and objective C)..

I see no reason to believe that carbon can't be (or couldn't have already been) ported to x86. Odds are most of it is C not assembly anyway.

Re:Ported all of Mac OS X to x86?

[bnenning]

QuickTime on Windows is basically very much the same as Carbon. Porting the old ToolBox (Classic part of OS X) to x86 would be fruitless and probably impossible. Porting Carbon to x86 has largely been done in QuickTime as it is. Carbon is just an API - one greatly cleaned up.

Moderate this up, it's exactly correct. The eWeek article is likely wrong on this point; there's no reason why Carbon couldn't be fully ported to other platforms, and I expect it has been.

Leaked Photos of Hardware

[Eravau]

How long 'til we get to see some leaked photos of Apple-specific X86 hardwware?

Re:Leaked Photos of Hardware

[morgajel]

oh, I'd imagine the photoshoppers are hard at work right now:)

Re:Leaked Photos of Hardware

[Anonymous Coward]

Imagine an iMac. Now imagine an iMac being anally raped by an 8" aluminum heatsink. That is what the x86 iMacs will look like.

-- The_Messenger

Re:Leaked Photos of Hardware

[Elwood P Dowd]

How long 'til we get to see some leaked photos of Apple-specific X86 hardwware?

Jesus Christ, give me a minute. Photoshop is a little slow on this 600mHz iBook.

Mac OS X86 and hardware.

[mwber]

It seems like they could still couple hardware and software if they went to x86, just not as tightly. They could keep lists of "recommended" hardware, with some sort of rating or ranking system. Perhaps they wouldn't even attempt to write drivers for more than a couple peripherals and allow open source drivers to emerge if they're needed.

Just a thought.

I'd buy it.

[Junior J. Junior III]

I'd definitely buy it if it were released. I'm all about having choices in the market, and OS X running natively on x86 hardware would be a step in the right direction. Both from the standpoint that I'd have more choices of what OS to run on my PC-compatible box, and in terms of what hardware I can choose to run Mac OS X on.

Come on, Steve -- give me a 2-button trackpad on a Titanium powerbook, that's all I ask for. I'm paying three grand for the thing, the least it could have is the number of mouse buttons *I* want on it.

Re:I'd buy it.

[garcia]

I would only use it if I was actually using Mac hardware. I really don't see any reason that I need to switch other than that.

Why Mac OS X on PC platform makes sense (long)

[eyefish]

Here I'm posting an article I wrote about the Mac OS X on the PC Platform long ago and that I tried getting publish on /.. Well, maybe now is a good time to post it after all

As we all know, with Linux we have the best free (as in beer) operating system in the market. It's fast, it's stable, it's well-supported, it scales, and it has a GUI environment that although very acceptable to the Linux community, it really is not up to par to the elegance and simplicity of the Mac OS/X GUI (and god spare me some flames, even the Windows XP interface feels better than the "stock" KDE or GNOME shipped with Linux).

On the other hand, we have Mac OS/X, the most amazing GUI out today for any platform. It certainly makes our friend Bill G. jelaous. It also has an amazing rendering engine by sporting PDF under the hood. However, even though it has a great backbone in the form of an open BSD system, the truth is that it is doubtfull the apple folks will get the steam, hype, and generally market support that Linux is constantly getting lately in all media, corporations, and geeks alike. Add to that the fact that Mac OS/X runs only on the PowerPC platform (at least officially), and you get a lot of potential market away from Apple.

So how about this, why not have Apple port it's whole Mac OS/X upper layers to the x86 platform, publish some specs for Linux vendors to "plug under", and run it on top of such Linux-based (as opposed BSD-based) systems???

With this we'd get the great support Linux enjoys in the enterprise (even when I'm first to recognize that BSD is just as good technical-wise, but this is a market-driven world folks), it'd also get the support from the millions of geeks who own a x86 machine, it'd get the support of all the OEMs who would almost inmmediatelly start providing hardware/software products for the platform, and just as important it would get the support of the common user thanks to its simple, elegant, and fast GUI system.

As a matter of fact, I'm pretty sure soon after we could start converting all Wintel users to the new platform ("Mac OS/Linux"?), since a new hardware investment would not be needed. Just a software download and a much lower price than a Windows license (say, 50 bucks?).

I know, some will argue that "what makes Macs different is the tight integration of the OS with the hardware" and blah blah blah, but heck, should this that I propose take off, I'm sure that Apple will have enough leverage to publish standards making this integration much simpler and still remain open, while benefiting everyone.

Note that since the Mac OS layer would sit on top of a MacOS-compliant Linux distro, it means that teckies will NOT be forced to use the Mac OS GUI, since they could use their Linux distro as usual, minus the Mac stuff. They could even keep using their old KDE or GNOME GUIs.

So, how does Apple make money? selling the top layer (software services and GUI), and if they want even selling slick custom-built hardware boxes like they do today with the OS pre-installed.

Now, please stop all the flames about "sotfware should be free and I shouldn't have to pay to use the Mac OS/X layer on top of Linux" and all that. Software should be free, but people also have families to take care of, and Apple's effort should be rewarded by paying them. Case closed.

As for Linux, imagine all of a sudden a flood of trully useable applications being ported from the Mac (and even Wintel) world to the new "Mac OS/Linux". This would eliminate the barrier many have when trying to move from Wintel to Mac: "my apps don't work or I can't access my data".

Also imagine the simplicity of installing, deinstalling, and managing applications that Mac OS would bring (do not tell me how debian, RPMs, etc are great, they suck big time if you ever had to use them regularly; yes I have).

This, I think, it's what would really bring a true competitor to the Windows monopoly. I'm sure that *I* would switch inmediatelly.

And BTW, as an example let's take my own case: I do not use Linux regularly because it's just too darn hard to do anything (unless you _already_ knew how to do it). Sure once you get it working it's fine and dandy, but heck, sometimes to get it to work you have to get the sources, read the FAQs, HowTos, set some flags, find dependencies, get extra libraries, etc.

Likewise, I don't use Mac OS/X because I can't go out and afford to buy a whole new machine architecture. I already have my decent 1.2Ghz Celeron, it works fine, why should I switch and spend US$1,700 just to use a nice GUI?

However allow me to keep my machine, give me the stability and power of Linux, and the elegance and simplicity of the Mac, and you can count me in right away.

Now don't get me wrong, Linux is *awesome* for someone that knows how to use it, or has the time to learn it. I think's it's an amazing platform for Apache, mySQL, PHP, firewalling, routing, Java, Perl, etc, but it could be much more if it was easier to administer and use.

You gotta understand that the people in large corporations are afraid of getting into something they don't understand or think it's too complex, this is why Windows NT has gotten such a large market share; People very close to me admit it, they use WinNT even if they have to reboot it once every 2 weeks because it is *easy* to use. And folks, yes I agree that maybe "they're not qualified enough to have such a job", but the reality is that they are here to stay and always will be here to stay, and Microsoft is counting on them.

Add to all this the distressing fact that the Windows OS _is_ getting better all the time (ask a Win95/98/Me user how many times they rebooted WinXP lately, or check out the Windows .Net Server Beta). Eventually (the truth hurts folks), Windows will be as fast and stable as Linux, and yes, they will copy the Mac look and get away with it just as they did with Windows. And they will have a market of several hundred million users who (like a herd) will simply follow Microsoft because simply they're not tech-savvy enough to realize that there are other choices. And developers will continue increasingly target the Windows platform because numbers speak: Do I sell for 4 million Linux machines, 5 million Mac machines, or 500 million Wintel machines?

This is the time folks to trully all come together and trully create a second option to Wintel. Let's combine the best of what we have (a Linux foundation, X86 hardware, and Mac OS upper services and GUI layers), and trully create something we can be proud of a few years from now.

So what's the next step? Someone should send this article to Apple's Steve Jobs, and have Steve meet with the heads of the major Linux distros to define some specs that all would follow to support the Mac Layer. Rally some OEMs to make their products "Mac Linux"-ready (so that they could support the tight-integration features that makes Macs such a joy to use today), and rally the big software developer houses and let them know about this and get them excited, and let's all rally behind this effort and give them all the support the open source community is famous for. This could be the beginning of a trully beautiful relationship...

Re:Why Mac OS X on PC platform makes sense (long)

[mr100percent]

Really? Quartz Extreme rocks in Jaguar. It keeps my CPU usage waay down, and looks crisper and beautiful.

Microsoft announced they're 3 years away. Vaporware as far as I'm concerned.

Re:Why Mac OS X on PC platform makes sense (long)

[be-fan]

The limitations of QE are clearly noted. The PowerPoint they released awhile ago cleared showed that QE was only used for compositing and window effects. QE works by taking windows, software rendering them to textures, and using OpenGL to draw textured quads to the screen. This way they can do compositing by making the quads partially transparent, and they can do stuff like the genie effect by using vertex shaders to manipulate the verticies of the quad. But the REAL work, drawing to the window, is done by the software renderer.

Re:Why Mac OS X on PC platform makes sense (long)

[Arandir]

...and run it on top of such Linux-based (as opposed BSD-based) systems???

Bloody Hell! Why would you want to cripple it like that?

Re:Why Mac OS X on PC platform makes sense (long)

[be-fan]

Dude. I use Linux for 90% of my work. I've gone months without even having it installed. Still, I can recognize a good idea when I see it.

Re:Why Mac OS X on PC platform makes sense (long)

[be-fan]

Umm, drawing to the desktop window is what Quartz is all about! It draws all the scrollbars, buttons, text, etc. The stuff QE accelerates (transparent windows and window effects) is nice, but its fluff, just eye-candy.

Re:Why Mac OS X on PC platform makes sense (long)

[jbolden]

I think OSX is a wonderful OS offering a business desktop almost as good as windows and a development platform almost as good as Linux. It certainly beats the Linux/Wine or the XP/Cygwin combo.

If your point is the Linux kernal vs. the Windows kernal I don't care which one the mass of humaninty runs. If your point is the whole Gnu/Linux suite vs. the XP suite (which includes extended office) then free as in speech is very important. Right now with a fairly portable Linux kernal and the suite of gnu tools (including gcc) as a community we can take any hardware configuration that emerges and produce a modern operating system plus a full suite of application for it within a year or two. That's a hell of a lot to give up for a better GUI.

Stay the course.

Re:Why Mac OS X on PC platform makes sense (long)

[MoneyT]

Question. Why would Apple release a PowePoint presentation of their developments? It would seem more likely to me that they would release it on the Appleworks Presentation or some other form

Re:Why Mac OS X on PC platform makes sense (long)

[MobyTurbo]

However, even though it has a great backbone in the form of an open BSD system, the truth is that it is doubtfull the apple folks will get the steam, hype, and generally market support that Linux is constantly getting lately.

[more explaining why Apple should switch to Linux from BSD deleted]

Linux is OK, but BSD itself is so compatable with Linux that not only do practically all sources recompile without changes, it even can run Linux binaries on the Intel (and maybe others) with almost no overhead in emulation. (Also on some other platforms it has similar binary emulation for the predominant Unix, like NetBSD on SGI platforms emulating Irix)

Why, other than the fact that "more people have heard of Linux", the crux of your argument, should they switch when the BSD API itself already (assuming they haven't made big changes that a simple switch to the Linux kernel wouldn't fix either) has the ability to run tons (well over 5,000 packages ported for FreeBSD) of Linux and Unix software with a simple recompile or, when neccesary for closed-source applications, emulation of Linux?

Re:Why Mac OS X on PC platform makes sense (long)

[ZigMonty]

Yes, if you consider moving a window "fluff".

Quartz Extreme is great but you're right, we need to have *all* of Quartz accelerated.

Re:Why Mac OS X on PC platform makes sense (long)

[jcr]

But the REAL work, drawing to the window, is done by the software renderer.

I don't know where you got the idea that compositing the windows isn't Real Work. If you look at CPU usage on systems with and without QEX, you'll find that without QEX, far more CPU time is spent compositing windows than generating their content in the first place.

-jcr

Re:Why Mac OS X on PC platform makes sense (long)

[eyefish]

MobyTurbo, I agree with your comment on BSD being very compatible with Linux. My point is a marketing point of view. I'd have no problems simply renaming the Apple-supported BSD variant as Linux (of course, after making sure all Linux APIs are supported).

You are right in what you say. My point is "let's play the marketing game". Remember, things are not what they are but what people believe they are.

Business as usual

[brindle]

Of course they have an X86 port.

If they release on intel hardware it will be for a finite set of manufactures to a limited set of specs, so that they can continue to deliver true plug-and-play. Expect to pay more for intel based hardware that runs Mac OS X.

And don't be too disapointed if your current system is not supported.

-b

Re:Business as usual

[mjprobst]

I think everyone is _still_ not thinking far enough outside the commodity X86-box market when they say "it will run on a finite set of specs".

Think rather, "Apple will design its own motherboards from scratch, with the only thing in common with other X86 boards being the presence of an x86-compatible chip".

They could dispense with lots of the legacy bullcrap that way--use something similar to Open Firmware, eliminate unnecessary layers of BIOS bullcrap, leave out any legacy support for ISA in the chipset, support a reasonable interrupt architecture, whatever else they want.

Plus, software like VMWare could still probably be made to run Windows on such an architecture, since these are the kinds of things that can be virtualized, and the things that aren't necessary. I doubt Windows would run out-of-the-box on such an architecture without some virtualizing mechanism to emulate missing things. But you'd still get better speed than with an X86 emulator on PPC.

I think it would be cool, actually, and even useful if VMWare were ported to it.

Re:Business as usual

[SpotBug]

And then, once Windows is running nicely on your x86-based Mac, developers won't need to write Mac software anymore. And then, well, then Apple's in the same business as the rest of the PC makers, and probably dies.

Oops.

And that's the problem with Mac on x86, even in the case where you still have to buy Apple's hardware. You're going to expect that it run your Windows software (it's got an x86 CPU in it!). As soon as that happens, developers start telling their Mac customers, just use the Windows version on your Mac. Little by little, Mac OS goes away and Apple with it.

Re:Business as usual

[g4dget]

Except for the x86, Macintosh is already almost a PC: PCI, USB, IEEE1394, AGP, ATA, etc. Even their BIOS is not homegrown anymore. And the mainstream PC hardware architecture has gotten pretty powerful--it's unlikely that Apple can do any better. PC vendors also have started eliminating complex legacy stuff pretty aggressively--in another year or two, ISA, parallel ATA, and PS/2 will likely be history, and BIOSes (for better or worse) will be based around ACP.

Re:Business as usual

[mjprobst]

Hey, I never said it would be to _Apple's_ benefit to provide VMWare, or even to port to X86. I just said that if it happened I think they're more likely to design something without 20-year-old PC-compatible roots, more along the lines of their existing PPC motherboards.

I also think it would be silly for them to move to X86 for the reason mentioned above; someone would port VMWare to it, and native software would become more difficult to justify.

Re:Business as usual

[mjprobst]

Point taken, but I still think they might have reason to design chipset stuff in-house.

Here's a good question--could they hack Altivec support into a chipset, or license it to AMD, and create an Intel-based platform that can run Altivec instructions? It's mostly a matter of how difficult it is to compile/port those instructions over to another architecture, now that they're depending on them.

This way they would end up creating an almost-X86 around AMD's core. Once again, might not be practical when thinking in terms of commodity hardware, but as a way out of sour deals with Motorola it might do service.

Re:Business as usual

[Gumber]

Apple is going to have to balance the savings of using a standard PC platform with the expense of supporting multiple vendors, or loosing hardware revenue because someone releases a patch that lets MacOS x86 run on their hardware.

You have to consider that Apple's current machines are very PC like in many respects (AGP, PCI, USB, IDE, industry standard memory, etc.) In other words, they are already leveraging major peices of the PC architecture.

I would guess that an Apple PC would look very much like the latest PC hardware spec pushed by Microsoft with, perhaps, a hardware key to tie in with the OS, and perhaps a BIOS that doesn't support so much legacy crap.

Re:Business as usual

[g4dget]

Is there any reason to believe that AltiVec is better than Intel's or AMD's vectorized instruction set? Maybe it's better on the G4 than its equivalent on the P4, but maybe it also has more silicon devoted to it there.

Re:Business as usual

[Matthew Weigel]

Blockqouth g4dget:

Even their BIOS is not homegrown anymore.

That's true, it's not "homegrown," but it's also not crap like the PC BIOS. NeXT went down the road of trying to support regular PCs before, and Sun has made an effort too; I think everyone has learned their lesson about trying to go from a tightly controlled in-house architecture to an open market-controlled architecture.

Apple would die if they tried to pull the same "your hardware is five years old; too bad" games on a regular PC that they do with Macs. Any move would involve not much more, I think, than putting an x86 processor in their Macs.

Re:Business as usual

[Matthias Wiesmann]

Is there any reason to believe that AltiVec is better than Intel's or AMD's vectorized instruction set?

The main difference between Altivec and MMX (can't say for AMD technology), is that altivec has its own registers, so that altivec instruction can run in parallel with normal instructions. There is more info on Apple's developer site.

Performance

[hobbesmaster]

I wonder what type of performance OSX gets on x86 processors; photoshop doesn't count.

To quote Chris Farley

[bogie]

Holy Snikees!!!!

I say bring it on. Of course this would mean a custom bios and only "Apple approved" hardware would work, but this should at least bring the cost down.

Imagine a $600 Imac that you could use your own monitor with!!! My check if officially prewritten.

Oh it would probably be a swift kick in the balls to MS as well :-)

Re:To quote Chris Farley

[MaxVlast]

All of your points are precisely why Apple won't do it:

1. Apple is a hardware company. They get their money from your $1100 iMac, not your $600 commodity iMac.

2. Steve would cringe to see Mac OS X running on your monitor. He'd make the most god-awful face, and we don't want to see that.

3. Microsoft would respond to a kick in the balls by cutting Apple's balls right off. Office X for the Mac? Sorry, it only runs on PPC macs. We had technical issues porting it.

Down the toilet, swirl swirl swirl.

Re:To quote Chris Farley

[PythonOrRuby]

Number 3 wouldn't surprise me in the slightest. After all, Microsoft's Mac Business Unit coded Office v.X using the Carbon API, yet it only runs on Mac OS X, thus negating the one reason to use Carbon rather than Cocoa(except of course for laziness, and an unwillingness to learn something that looks new).

I hope this marklar work out.

[laserjet]

I hope this new marklar really works on marklar marklar. Marklar seems to be the marklar of the marklar, not just another markler off the old marklar. Marklar really does need to marklar another marklar maker in order to be marklar with the marklar. Marklar is just not marlar anymore, and this seems to be a good marklar to the marklar. A small marklar to marklar, really.

Re:I hope this marklar work out.

[joto]

From a space-episode, in which they meet an alien race speaking like the above comment. It's just like smurfs, overusing another word. Hardly the best episode.

OS X is already available for Intel.

[FrankieBoy]

Darwin is the core for OS X and there is a port for it called GNU-Darwin-x86. Aqua is the GUI and I think that there are some people working on this.

Re:OS X is already available for Intel.

[Jeremy Erwin]

The kernel is called xnu. The Darwin operating system (like most *BSD distributions) is comparable to what RMS and Debian call GNU-Linux. MacOSX uses a fork of Darwin-- there isn't a one to one correspondence between a Darwin release and a MacOSX release-- and adds further libraries and services, Carbon, Cocoa, and Quartz being the three most famous.

Believable

[Jeffrey Baker]

I'll believe Apple has an x86 port of OS X. But, the OS is not the main problem. Apple can't switch to the x86 because their app vendors would be in hell trying to port their AltiVec optimizations to MMX/SSE/3DNow!/SSE2. Nevermind that Apple would suddenly be just another PC vendor.

It is much more plausible that Apple is switching the 64-bit IBM Power4 CPU. IBM is presenting this new desktop version of the CPU at Microprocessor Forum on October 15th. The CPU has a mystery vector unit with 160+ instructions, just like AltiVec. There was a post to the gcc-patches mailing list proposing a patch to enable altivec support on the powerpc64 target, and this patch originated from Alan Modra at IBM's Linux Technology Center.

All evidence indicates that IBM will produce a desktop CPU with an AltiVec unit. Apple has hit the wall with Motorola, and are now selling overclocked G4 miracle CPUs just to stay in the game. I think Apple will switch to Power4.

Re:Believable

[Baki]

I don't think Apple would suddenly be just another PC vendor. Porting OS-X to Intel CPU's does not mean Apple would adopt the complete PC architecture for their future hardware. I am almost certain they would make non-PC compatible Intel hardware.

Apple has no reason to stop their excellent strategy of close marriage between non-commodity, thus predictable, hardware and their operating system. I do think they develop the Intel version in order to be able to switch CPU, should the Power PC CPU not work out well, not in order to become just another PC vendor.

And of course they want to keep it highly secret, since it would be very damaging to current hardware sales once people start to think another CPU switch (like 680x0 -> power in the past) making the current hardware obsolete.

Re:Believable

[YeahIThoughtSo]

I totally agree. I program GameCube games, and the PPC chip that IBM has supplied in it is just a wonderful little powerhouse. It's a modified 750 core running at 486 Mhz and has got incredible FP performance and ~ 1.6 GB/s out to memory through a special write-gather pipe. The FP can handle paired-singles (anyone see the altivec connection here?), and the machine as a whole is just stupid fast. (Yes, the memory architecture has someting to do with this too...)

Anyways, it totally makes sense for apple to go with a desktop version of the POWER4 core. The PPC specification is such that any program written that targets the UISA (think it stands for something like user instruction set architecture -- ie, non-privelidged instructions) will move right over to any other PPC core w/o a recompile. And the PPC64 spec is such that all instructions are still 32bit; it's just the data / registers that're 64bit. So binary compatibility is a no-brainer.

Couple in the fact that power4 has multiple cores on a die... and, damn. I'll buy my first Apple machine if they actually do this.

Re:Believable

[Gumber]

Umm, hasn't apple already adopted the PC architecture? PCI, USB, AGP, etc?

Re:Believable

[furballphat]

I find it doubtful that they even have this port, never mind if they are going to use it. If it does exist, then it has done for several years, yet it has only been leaked now (by Think Secret!)

Directly involved in the development of Marklar is 12 or so people, however the article says: "mainstream Mac OS X team is regularly asked to modify code to address bugs that crop up when compiling the OS for x86." This means that all the OS X developers know about it, as do the internal testers. I don't know the specific numbers, but that's a lot of people, and surely one of them would have let the cat out the bag before now.

Re:Believable

[g4dget]

Apple can't switch to the x86 because their app vendors would be in hell trying to port their AltiVec optimizations to MMX/SSE/3DNow!/SSE2.

Without AltiVec or MMX, the G4, AMD, and P4 seem to be roughly equivalent at the same clock speed. And not many applications are optimized for AltiVec--not many can be.

Overall, Apple might well benefit in terms of performance by going with x86, even if a tiny handful of hand-optimized applications possibly gets a little slower.

Whatever they do, Apple should probably go with a 64bit architecture, since 4Gbytes is getting a bit tight. Maybe Itanium is the answer?

Re:Believable

[ZxCv]

...and surely one of them would have let the cat out the bag before now.

Uh, the cat was out of the bag long ago. This has been rumored since before 10.0 was even released. The only real 'news' here seems to be that Apple is still keeping up the Intel version of OS X, not that it ever existed.

Re:Believable

[zapfie]

Well, an x86 port does not imply x86 architecture. Apple's not stupid enough to kill off their hardware sales- after all, it's what keeps them so strong. Using an x86 chip in a custom Apple architecture gets rid of the whole issue with Motorola and IBM, but maintains Apple's grip on the Mac hardware market. Now THAT is more plausible.

Re:Believable

[Jeffrey Baker]

I think you are pointing out only superficial differences. AltiVec has 32 registers. Pentium4 has 8 SSE2 registers. If you wrote a program that exercises 20 AltiVec registers, you have some changes to make to jam it into the Pentium4. Also the PPC74xx has a dedicated unit for AltiVec, which means the programmer can issue instructions on the scalar FP unit and the AltiVec unit in parallel. The Pentium4's FP unit is the SSE2 unit, so any super-optimized AltiVec code needs to change. Nevermind that SSE2 still doesn't have a satisfactory analog to the vec_permute on AltiVec.

My only point is that anyone who took the time to really exploit AltiVec for that nifty iDCT routine is going to have to do it again for SSE2.

Re:Believable

[SPYvSPY]

Case in point: Super Mario Sunshine fucking rules!!! Gamecube, all the way!!!

Lower prices, at least...

[Mulletproof]

I can see one consumer advantage right away-- Lower hardware costs. The ability to take it anywhere for repairs, not just apple certified (or uncertified, for that matter), which are fewer and farther between and generally higher priced to boot. Don't have to worry about those specialized apple motherboards anymore either. Not that they still wouldn't have their own software issues, but it certainly can't hurt...

Recompiling

[Anonymous Coward]

Right. You expect people to recompile for x86?

Do you have any idea how long it took Apple to get everyone to recompile all their software for the 68k software for the PPC? It took years. If apple had started off telling everyone to compile FAT binaries from the time that Mac OS X was released, maybe we'd be okay. But the mac os x developer community is somewhat mature now, and there is a fairly large mac os x software library. Large enough going back and getting everyone to recompile everything would be hellish.

I'm sorry, you need an emulation layer to help people crossgrade gracefully. This isn't linux. Usually, people don't have the source code to apps they install. People expect to install by dragging a package icon from one window to another, not by typing "./configure; make install", waiting 15 minutes, and then poking through your hard drive trying to figure out where the Makefile install script put its junk.

Gee, there's a great line. "Buy mac os x for the PC! But you won't be able to run any classic mac os apps! Or any commercial apps where the CDs were pressed before april of 2003, or any shareware apps, because the shareware developers will be too lazy to configure confusing FAT binaries for an archivecture they don't use! You can run Microsoft Word, IE, and Fink, though!"

I really hope apple has some plan for dealing with this, some kind of CLR-style "partial compilation" VM thing so that one executable can contain machine code for two architectures without having to take the disgustingly inefficient fat-package route. If every single application has to come with two binaries, one for each of the two architectures, and there's PPC-only shareware apps made by lazy ppc users and x86-only shareware apps made by lazy x86 users floating around.. that's just going to be the biggest mess imaginable.

I can't even imagine what it will be like trying to explain to the average iMac owner why their new software comes with two CDs, one marked "x86" and one marked "PPC". And let's not even get into devices, or software that's been written to use Altivec.

Re:Actually, this idea isn't new...

[Etcetera]

This would have been when Windows 3.1 was the best Redmond had to offer, but I'm not sure the MacOS of that era would have been much better.

Geez, are you kidding? System 7 was FAR AND AWAY better than 3.1 ever was. I remember reading a compariason of System 7 to Win 3.1 in a MacUser issue from back in '90. System 7 formed the basis of the Mac's OS for almost 10 years, and though it was showing a little bit of age as it progressed, it was still a remarkable OS.

Re:Wait a sec

[be-fan]

Motherboards.. video cards.. etc.
>>>>>>>>>>
If you hadn't noticed, the current Mac's are basically just PCs with G4s in them. I mean the system bus is PCI, the graphics bus is AGP, they have Firewire and USB, they use ATA hard drives, DDR-SDRAM, and NVIDIA and ATI graphics cards. The only things they'd have to change around are the code hooking into some motherboard/firmware level stuff (Apple-Evil-Proprietory-Boot vs ACPI for example) and they'd be good to go.

I believe it

[drinkypoo]

But I don't think they're going to release it on anything other than their custom hardware, which will be overpriced like their PPC hardware.

Who cares if moto can't provide the chips, they're getting Cu-connect PPCs from IBM now, right?

Once again..

[mindstrm]

didn't we already know this?

Apple maintains this in case they decide to switch the Mac processor to x86.

It's not so that OSX will work on your PC.
It's so that apple can build a Mac using an intel chip instead of ppc.

Makes sense

[lkaos]

Presumably, Apple isn't really "porting" to x86. OS X is based on FreeBSD which was developed for x86. I seriously doubt that they made many assembly level changes that required serious parellel development.

If one thinks about it, maintaining a version of OS X on multiple platforms makes sense. It helps catch bugs since undefined behavior can be more volitale on certain platforms (and hence, easier to catch). One of the best ways to squash bugs out of a program is to have it run on a variety of platforms.

I wouldn't be suprised is OS X ran on a whole bunch of platforms... Of course, that doesn't mean that 1) Apple has any plans to release ports or 2) that there is decent hardware support on any other architectures.

Re:Makes sense

[elmegil]

Which is a damn shame, because I'd be really glad to pay Apple $100 - $150 to run MacOS X + on my Intel hardware, but I cannot convince my wife that it's worth $2000 for an iMac.

Re:Makes sense

[MoneyT]

there aren't any $2000 imacs out there. Just thought I'd clear that up for ya

Re:Makes sense

[sessamoid]

there aren't any $2000 imacs out there. Just thought I'd clear that up for ya

A quick trip to the Apple store shows an iMac with Superdrive and 17" LCD for $1,999. Even before adding memory or anything else to it, that comes to well over $2000 after shipping and sales taxes.

Re:Makes sense

[karlm]

Presumably, Apple isn't really "porting" to x86. OS X is based on FreeBSD which was developed for x86. I seriously doubt that they made many assembly level changes that required serious parellel development.

Much of the userland is NetBSD and FreeBSD-derived. This means stuff like the libraries, ls, top, ps, etc. If you're writing good, well-optimized C/C++ (maybe ObjC), then there should be very little assembly (ideally no assembly) code outside the kernel. (Maybe some AltiVec math/graphics libraries in userspace.)

In any case, I doubt there's much assembly at all in the FreeBSD-derived portions of OS X. Most of the userland is simply a cross-compile. The kernel actually probably required a fair ammount of effort to port (from the NeXT m68k kernel and/or from Darwin PPC).

The monoserver is not a userland port of the FreeBSD kernel. IIRC, the NeXT people had a userland implementation of a BSD 4.3 kernel, from which the Darwin monoserver descended. I just thought I'd point out that calling OS X a port of FreeBSD is like calling LinuxPPC a port of the GNU system. Sure it contains a port of the GNU system, but you neglect the Linux kernel port that came from a totally different group.

I think of OS X as a modernized PPC port of the NeXT system. Cocoa and Darwin are both born of NeXT.

Lose Carbon & AltiVec? 3rd parties not gonna

[mactari]

I've actually been thinking about this a bit, and couldn't decide if I fell on the, "There's no way Apple's duplicating their efforts on x86; it's just not economic. They're already late releasing OS X and its updates as is," side or if I figured that "Motorola and IBM just aren't getting it together with the PowerPC; it might be time to jump ship".

I usually end up thinking that if Apple used x86, the OS would lose all its tricks that are G4 specific (particularly things that used the AltiVec instruction set). These are the things that it's used to make Photoshop run faster -- not to mention iMovie, iDVD, etc -- if the OS swapped over to another processor architecture. If a Mac is slow now, wait until it loses the one ace up its sleeve when it comes to digital video. Seems that'd shoot Apple's new niche (one-stop digital hub) all to heck.

Not to mention what the switch would mean for third parties that would have to recompile (again!) for the new platform. I doubt the Classic environment is making its way to x86! Not a big deal in itself, and a break from Classic would be super, but hang on... That probably means Carbon, the compatibility layer that helps apps written for Classic run natively on OS X, is also out. Now we're talking problems. Legacy 3rd party code is out the window in many cases.

I do wonder if Apple's gone so far as to utilize whatever's the equivalent of MMX in the Pentium 4 and AMD Athlon's instruction set to overcome the problems it'd suffer by switching (pardon the pun). I still can't imagine Carbon's x86 compatible. Cocoa ("new improved NextStep") would probably be all that would make the jump.

I suppose it can't be that tough to port if you limit to Cocoa, though. As people have pointed out before, Darwin's got an x86 version now and NextStep (the OS Apple bought that was supposed to turn into OS X a little more quickly) ran on x86 hardware. I always thought it'd be silly to duplicate all the effort of the tweaks Apple put into Next for PowerPC as they were already way behind on OS X without clear x86 plans, but perhaps those tweaks aren't as fancy or ugly as I'd assumed.

I still don't think this means Apple's leaving hardware, any way you slice it. There will be something, even in x86 Macs if they show up, that makes it so that you can't run OS X without quite a bit of custom hardware that Apple controls.

Re:Lose Carbon & AltiVec? 3rd parties not gonn

[drinkypoo]

I usually end up thinking that if Apple used x86, the OS would lose all its tricks that are G4 specific (particularly things that used the AltiVec instruction set). These are the things that it's used to make Photoshop run faster -- not to mention iMovie, iDVD, etc -- if the OS swapped over to another processor architecture. If a Mac is slow now, wait until it loses the one ace up its sleeve when it comes to digital video. Seems that'd shoot Apple's new niche (one-stop digital hub) all to heck.

Altivec schmaltivec. Yes, it works and it's cool, but the x86 chips have the higher clocks. These companies already have versions of the software optimized for x86 CPUs, because there's more software on x86 than there is on PPC. Not everything is on both platforms, but most software which requires that much CPU is present on both platforms already. They can borrow the highly optimized code from the wintel version.

don't get all excited

[jchristopher]

Don't get all excited just yet. Even if this came to fruition, it would almost certainly be on a very narrow subset of x86 (apple-controlled) hardware - not just something you could buy in a box and install on your existing generic box.

As such, it would suffer from all the current problems of the Apple platform: no 'cheap' (This does hold promise, though. I've been very disappointed with the GUI speed of OSX, and I'd be very interested in how much of a speedup there would be on more modern hardware.

Re:don't get all excited

[zztzed]

I wouldn't be so sure. XPostFacto is still going strong with no threat of legal action from Apple whatsoever, and I gather there are numerous happy users of OS X, running it on their old 7300/7500/7600/8500/8600/9500/9600 series PowerMacs via XPostFacto. Then again, the XPostFacto people (person?) can probably get away with it since they're not directly modifying Apple's code, just distributing an extension (or kernel module, if you prefer) using known APIs. Presumably XPostFacto's theoretical x86 analogue would do the same.

Then again, the situation's not exactly the same -- at least in the case of people running OS X on upgraded legacy Macs, they've already paid Apple's hardware tax.

Re:don't get all excited

[reallocate]

Assuming the Apple would not be so blindingly stupid as to release an x86 OSX that ran happily on PC boxes made by anyone but Apple, it eems to me there are lots of ways to inextricably bind Apple hardware and software together, regardless of the chip that's inside: don't use the standard PC architecture, code key software components to run only on specific Apple hardware components, refuse all online transactions w/Apple and manual software installs if the machine's serial number isn't there, etc.

(By the way, isn't complaining about an alleged Apple "hardware tax" a bit like a Geo owner complaining about a Lexus tax?)

Re:don't get all excited

[DavidRavenMoon]

...they're not directly modifying Apple's code, just distributing an extension (or kernel module, if you prefer) using known APIs.

AND the kernel in question is open source.

Why Mac OS X on PC platform makes no sense (short)

[TellarHK]

You put out a lot of good reasons the Open Source community would want this, or could use it. But you're putting in no reason for Apple to want to do it.

Apple would die the quarter that OSX became an x86 commodity. On x86 hardware, they'd be dealing with all the vendors that make things for Microsoft as competition, and dealing with unhappy traditional Mac developers that just made the switch to OS X on PPC. They'd alienate the entire Apple infrastructure just to gain a few points on hardware speed that they wouldn't even be able to sell anymore. People won't pay Apple's -slightly- higher hardware prices when they can get the exact same thing (technically) for less.

Apple makes money by selling hardware, that's where the support base they have is, and that's where the company excels. The entire user experience as a whole is what drives Apple sales.

If we do see OS X on x86, we'll see it on the same Apple hardware we see today, just with a different chip in the mix. It'll all be Apple branded, no clones, no over the counter OS sales for plain-jane x86 machines.

This is the ONLY way that an x86 port of OS X makes sense to Apple.

Personally, I'm betting that it'll be the new .09 (Or is it .06?) micron fab IBM just built that'll produce the next generation of Apple chip.

I'll beleive it when I see it

[kir]

In other news...

Microsoft has secret internal plans to open source their always changing strangle hold - the .doc format. This, according to "sources", is seen as move to stem growing concern in its customer base that Microsoft really is, as they've been twice found guilty of, abusing its monopoly status in the market.

...and all throughout the world, pigs have sprouted wings and taken to flight.

No.

[mcc]

Hello.. please stop staring at your cock, and please in future read posts before you attack the poster.

Furthermore, your assumption that PPC is automagically more powerful than Intel architectures is a clear indication that you are severiously under-informed.

Note that the poster you responded to never said the PPC was more powerful than intel. They referenced the fact that when apple changed from 68k to PPC hardware, they included an emulator so that legacy apps could be run on PowerPC computers. The emulation he referred to was for third party apps which have yet to be recompiled, not for the ported OS.

All the original poster said was that while it was no big deal to emulate the 68k on the vastly more powerful PPC, emulating a PPC on an x86 would be not so easy, as x86 and PPC are roughly equal. I am not able to see where your rediculous ad hominem attack comes from. They did not even advocate PPC as more powerful than x86.

That being said, it would indeed be extremely difficult to emulate PPC on the x86! This is simply because of the way the chips are designed. The PPC is RISC; it has simple instructions and lots of registers; the x86 is CISC; has few registers and complex instructions. RISC is not necessarily better or worse than CISC, and the x86 is not necessarily better or worse than the PPC. However, it is generally well-known and accepted fact that it is easier to write an emulator that runs on a RISC machine than a CISC one, and it is quite obvious to anyone who is familiar with the emulation scene that the PPC and x86 are good at different things, and one of the things that the PPC really shines at is emulation.

This will become blatantly obvious if you consider that there are multiple, at least three, separately developed programs-- one of which is open source-- which emulate an x86 PC on a PPC Macintosh. There are, however, no extant PPC Macintosh emulators for the x86 PC. None. And it isn't for want of trying; you can see here that there have been a number of macintosh emulators for the PC, just that none of them have done PPC emulation, only 68k. There have been many attempts to emulate the PPC on the x86, it is just that they have all come to nothing-- becuase the architecture of the two machines is simply such that it is relatively easy to emulate x86 on PPC and relatively extremely difficult to emulate PPC on x86.

I suspect i am responding to a troll. I really ought to submit this as AC. Oh well.. ;;winces, hits submit;;

Re:No.

[toddhisattva]

RISC is not necessarily better or worse than CISC

I like your use of "necessarily." I'll need to work that into my daily usage ;-) But I respectfully suggest you're neglecting history.

CISC comes from an age of assembly-language. It got so extreme some had polynomial evaluation as an instruction.

RISC comes from an age of compilers. It is a refinement of CISC, based on observing which instructions actually get used and how.

Please note that I don't mean that compilers didn't exist before RISC, it's just that in the late 70s when x86 was designed, a hell of a lot of stuff was done with assembly. Also, Jimmy Carter was President and the Bee Gees were selling millions of albums a year.

I'm sure you know all this, thus your clever "necessarily." But I'll continue for the benefit of any youngsters ;-)

CISC can have dozens of addressing modes. "Load indexed scaled adjusted and postincrement the index" and every imaginable permutation. Your CPU would suffer as it slogged through all the decoding.

It turns out that to get speed, people just did all the indexing and scaling and whatnot explicitly. The CISC processor was being fed a stream of simple instructions which it didn't have to chew on.

So folks started making chips that ditched all the complex stuff, and we got RISC, which have less than a handful of addressing modes. Effective address calculation was done explicitly, just like all the smart kids were driving their CISC chips anyway.

Turns out that sometimes it's good to have a little complexity. For instance, if it doesn't hurt anything to have a complex multiply+add instruction instead of a multiply followed by an add, and you sell into markets that can use such a tweak, why not?

Motorola's AltiVec is a further example of "enhanced RISC."

Thus was born "Performance Optimization With Enhanced RISC," or POWER. Apple needed a RISC chip, enacted a shotgun menage-a-trois with IBM and Moto, and we got PowerPC.

A POWER architecture is two stages of refinement past CISC. Add to this the fact that x86 is pretty much the worst CISC architecture ever -- 68000 was so superior -- PowerPC is a much better, more refined chip than any x86.

If only Moto didn't suck at building PowerPC! What is wrong with their fabs? There's something seriously bad going on there, such a shame since Moto has proven design genius with 68000 and AltiVec.

In more fairness to the Dark Side, x86 vendors no longer directly execute the crufty x86 ISA. They translate the instruction stream to something that gets executed by a much better architecture than x86, "micro-ops" for a "core." In these cores, they've been able to incorporate a lot of RISC-like improvements, scalar-ness and whatnot.

Re:No.

[tshak]

There have been many attempts to emulate the PPC on the x86, it is just that they have all come to nothing.


It's called business. Millions of dollars have been invested to emulate x86 on a PPC because there is a market for it. I personally have not seen a large investment for PPC emulation on the x86 most likely because there is no market to invest the millions.

Re:No.

[plastik55]

If you claim that the RISC PPC is a cleaner nicer
architecture because its RISC, then in fact to emulate it will be even easier to do than the 68K (a CISC) emulation.

What you're failing to consider is that the PPC has way more registers than the x86 chip. Specifically, 32 general-purpose integer registers, 32 FP registers, 32 AltiVec registers, 16 segment registers, and five miscellaneous others.

Compare with the P4-- 8 integer registers, 8 FP registers, 8 MMX registers, 8 SSE2 registers, and miscellaneous others.

This means that a PPC emulating x86 instructions has registers to spare for decoding operations, while the P4 trying to emulate the PC will necessarily waste a lot of time sawpping register values between chip and cache. Dynamic recompilation can address some of this, but it is not magic.

Re:No.

[photon317]

I think you miss why it's harder to emulate PPC on x86 than it is to emulate x86 on PPC. PPC is RISC - lots of small instructions and lots of registers. x86 is CISC, fewer instructions that do more, less registers.

Therefore, it's (relatively) easy to decompose a complex x86 instruction into a sequence of simpler PPC instructions that get pipelined well. However, in the PPC on x86 emulator, the only way you could be even remotely efficient would be to do some intelligent analysis of the incoming opcodes as "groups" that resemble the function of a single x86 opcode and try to translate it that way, which would be hard to do in the fly in a tight runtime emulator core. If you stick to the standard quick-and-dirty translation, you end up failing to really utilize the x86's complex instructions well, as you're issuing one or more complex CISC instructions per simple RISC instruction, kinda (at least that's one way to think of it). On top of all that, the fact that the PPC has way more registers doesn't help either. The code compiled for PPC will be optimized to make use of all of them, with tight loops assuming register-speed access to more variables than the x86 core can put in registers, so you put them in memory and take yet another hit.

The above isn't really all that correct, but hopefully it conveys the general gist of things.

Think of the fun times

[banky]

You'd have to have a custom BIOS, or you'd lose the "startup disk" functionality. After all, you can boot any number of OS images off any number of disks with Apple hardware. Losing startup disk would be a pain - how to run multiple versions of the OS?

The graphics card issue isn't a big deal. You'll probably have to choose from one of several "approved" GeForce and ATI cards; big deal. Isn't that more or less what Windows power users do these days?

Likewise the rest of the story - Firewire, USB, etc - is no big deal. The average /.'er screams about the "closed" hardware but lately it's more and more PC-like.

Apple would likely lose all-in-one boxes. Most x86 laptops I encounter these days run hot. Crusoe, anyone?

Otherwise, really... the high-ups want Classic gone ASAP, and the important parts of Carbon run on Darwin, right? Cocoa used to run on x86.

I just can't see it happening, though. More of a bargaining chip than anything else.

Re:Think of the fun times

[ImaLamer]

Crusoe, anyone?

Yes please.

No, actually why not have OSX on Crusoe chips, that would rock. That could be their first step into limited pc markets.

Re:Lose Carbon & AltiVec? 3rd parties not gonn

[bmajik]

Altivec isn't worth keeping if you'r emoving to x86.

Case in point ? Photoshop on a run of the mill athlon xp smokes the fastest hardware apple makes. Photoshop is supposed to be "the altivec macintosh app".

PPC hardware, altivec or not, is slower.

Incidentally, iMovie and all that other stuff runs on G3 macs with no altivec at all.

Your good observation is that classic and carbon apps wouldn't run well/at all on an x86 port.

Regarding coca / nextstep on x86, that problem was solved 15 years ago. nextSTEP 3.3 ran on x86 quite well. It was succeeded by OpenSTEP 4.x, which also ran on x86 hardware quite nicely.

Infact, apple didn't throw away 100% x86 compat until they did their quartz +aqua UI peice, and then grafted the legacy mac os 9 shit into the OS.

Howzaabout some REAL conjecture?

[mbourgon]

I'm going to agree with the other people who have mentioned the new IBM Power4. And, provided the G5 ever comes out, it would potentially put Apple back in the game, performance-wise.

That is, of course, if the rumored speeds are to be believed (G5 1.6ghz is supposed to have roughly twice the SpecFP and SpecINT of a P4-2ghz - The Register). Due in January, last I heard. We'll see.

I can see the possibility of them going to another chip manufacturer, and AMD would be the most likely - IIRC, the AMD architecture is emulating the x86 on half the die, with the other half being RISC based. If they could come up with a PPC emulator, it might be doable. That being said, NeXT _was_ running on x86.

As for Marklar being the phrase? Well, this is the company that had BHA (Butt-headed astronomer - one was originally coded Sagan, and Sagan threatened to sue) as a code phrase. And saying Marklar would actually make discussing things in public possible. (aka "So, did you figure out issue X with Marklar"?). But that would also indicate that it's a little under 3 years old (Starvin Marvin in Space airdate: 11/17/99). If they started around then on it, then that might work, but it's starting to sound implausible.

So, like most things Apple: who knows? only time will tell.

Re:x86 port doesn't mean it will run on a Dell

[norton_I]

Maybe not Windows, but I bet 10:1 odds that within 2 weeks of the hardware being readily available, the linux kernel will boot on it and you will be able to install debian with custom boot floppies. Probably sooner, given that it already runs on a bunch of "custom" x86 machines as well as the very PPC systems Apple would be porting from.

However, if I were Apple, and wanted to do this, I would contract with a PC motherboard maker or two to make an OEM version of one of their motherboard series that had an Apple written BIOS, but was otherwise identical to the PC version. Pop that in a custom Apple designed box and put in Apple approved hardware, and you are ready to go.

If they wanted to run PPC code for Carbon/OS9 classic apps, do that on a PCI based coprocessor card, rather that a motherboard integrated system.

As a bonus, the MacOSX/Intel version of photoshop could be modified to use the PPC in parallel with the x86 CPU for an extra performance gain that Jobs could brag about.

Re:Backup plan

[the eric conspiracy]

"wouldn't maintaining a whole seperate codebase "just in case" be a bit much?"

I doubt if it's a 'whole separate codebase". It's probably just an effort to makes sure the existing codebase compiles on x86 + some drivers/patches for x86 hardware specific stuff.

Something to keep in mind...

[ParisTG]

Something to keep in mind, is that x86 != PC. That is, just because it runs on an x86 chip, does not mean it will run on any run-of-the-mill PC. The most likely strategy, if Apple does indeed decide to switch chips, is that they will produce their own x86 processor based boxes. These would NOT be PC compatible, but would rather be Apple computers that just happen to use an x86 chip.

Of course then the only problem is backwards compatibility, unless the x86 has a large enough margin over the PPC that it can be effectively emulated (like what Apple did when they switched from 680x0 to PPC).

Re:Something to keep in mind...

[vandelais]

The really interesting part will be to see which video drivers are chosen to be shipped native with the OS.

Just my humble opinion.

Re:Believable you are wrong!

[paploo]

So now this begs the question: Is the performance loss due to emulating AltiVec outweighted by either the higher clock speeds of the Intel chips?

-Jeff

Why not go with transmeta or IBM?

[Billly Gates]

Remember that the powerpc architecture is not all owned by Motorolla. IBM and Apple also have claims to it. IBM would gain lots of money if it helped apple not to mention it has some the best chip fabrication plants in the world. Both apple and IBM may be able to work some sort of deal with Motorolla and just buy the remaining IP off. Motorolla can no longer afford to keep upgrading its plants and this is why the G5 is so late.

I wonder if IBM could make a low cost version of its Power3 chip and strip out some of the high end features like its 2 chips in one, lower the cache, and simplify some of its fp registers and make the lower end power3 chips using the latest chip fabrication technology so it can clock high. After that, apple could have a nice 2 - 2.5 gig powerpc chip that could run circles around the g4.

Transmeta is also a solution but they do not own any chip fabrication plants.

IBM and Apple would gain everything. It would be very very bad for apple to switch to x86. Infact vendors are struggling to get OSX ports of there apps and many are switching to wintel. Another move like a major chip migration would hurt apple because many vendors would just leave and existing powerpc mac users would feel left out in the cold. After all only some apps have been ported and now the vendors may just switch to OSX/intel totally or leave for wintel.

Re:Actually, this idea isn't new...

[Stephen Samuel]

Back in the early '90s, a PC (Windows) magazine (PC Mag, I think), acknowled that

MacOS has a 5 year software lead on Windows, and this lead is likely to continue for the forseeable future

(or something pretty close to that).

Engineers rule at Apple, so the OS was well designed, but badly marketed. System 7 was stable, consistent, extensible, and -- unlike any version of Windows -- very well thought-out and designed.

Marketers ruled at Microsoft, so the OS was badly designed, but well marketed.

Yes, the marketing people won this war -- but as a childhood saying went:

20,000,000 flies can't be wrong eat shit!

Already done that

[moosesocks]

Actually, apple released an incomplete build of an early development build of OSX compiled for X86 to ADC members sometime around 4 years ago. It was dubbed as the Apple Rhaposody OS Developer Release 3. It was quite intersesting to pick up the similarities between it and OSX. A ton of information, along with screenshots are posted at this site.

It was really a transitional OS which gap between NextSTEP and OSX. It contains both elements of both OSes. Anybody recognize the chess program at the bottom of the page?

Re:Already done that

[GoRK]

Yep! I used it, tried some development with it, and filed bug reports. I was dissapointed that they did not make another public release available.

I have no doubt that they have most of OS/X and it's components running on X86 internally.

Re:you don't even know what you're talking about

[be-fan]

Prove it. I'm getting my info right from Apple's released info. Read this document. Note, especially, page 10, where it shows the data flow diagram. Note how Quartz "Extreme" simply takes the place of Quartz Compositor, and the Quartz2D drawing to window buffers is still done in software (read the legend). Now, beg for forgiveness.

NEVER (or) I HOPE NOT

[Eric_Cartman_South_P]

Listen... I'll all for more competition, etc, but MAX OS X is going to run like CRAP on your Dell Boxen, or whatever it is you have, because of NO QUALITY CONTROL of what parts are in you little box. Crappy video cards, horrific sound cards, hell, half of the stuff Creative Labs puts out is junk, and their drivers are worse. How is an OS supposed to work with all this? Answer: It doesn't (see Windoze and Linux compatability problems). If you want to spend hours inside playing with vi to get sound working, have fun! Use Linux. We don't need Mac OS X on Intel.

All we will have is problems, on the side of the vendors, who either make bad hardware, or bad drviers for their hardware.

Re:NEVER (or) I HOPE NOT

[gerardrj]

You're missing the point. Apple would not release OSX for Wintel systems, they would put the AMD or Intel chips in Apple designed systems. Without the Apple proprietary ROM code, Mac OS would not boot on another vendor's system.

Re:NEVER (or) I HOPE NOT

[be-fan]

This is the biggest load of crap I've ever seen. Apple PowerMac parts are consistantly of mediocre quality. Only the very highest-end Macs have real GeForce4 cards, while most have cut down cards like the GeForce4 MX (actually a souped-up GeForce2 for you morons who actually believe Apple's marketing department) and Radeon 9000s (slower than a Radeon 8500, for those same people). Apple used to use crappy crystal chipset sound cards, now they use some USB DMA crap with absolutely zero hardware acceleration. Compare this to a nice Sound Blaster Audigy (or even an SB Live! which goes for chicken feed these days) and the Mac dies in embarrasment. Then you have the Apple "Pro" speakers, which are a joke compared to a comparably priced Logitech 560 setup (or Klipsch, if you wanna spring for a little more change). And the stuff that isn't crap in a standard Mac is just PC hardware. What, you thought Apple made their own hard drives? As for Linux driver quality, that's bull. I've been using Linux for years on Dell machines, and the only driver issue I've ever had is a WinModem not being supported. Linux uses every single piece of hardware on my laptop (including my QuickCam) just as well as OS-X uses any piece of (much inferior I might add) hardware on an PowerBook.

Re:NEVER (or) I HOPE NOT

[Eric_Cartman_South_P]

Wow... you got me. That is actually a good idea. If I could get the new 17inch iMac with an AMD +2600 chip, that would be sweet like suga.

Now I'm hoping it happens. Guess I should read more than the first paragraph of an article, eh? :)

Re:NEVER (or) I HOPE NOT

[be-fan]

Whoops. I meant the 540s (2 channel). They're about $80, less on pricewatch. Being a Klipsch bigot, I'd never come near speakers made my a mouse manufacturer, but I hear they're quite good if you like the whole 2.1 thing...

Marklar? Marklar

[sielwolf]

"Isn't it difficult to tell everyone apart when everything is called Marklar?"

"Oh, no. Hey Marklar?"

"Yeah?"

"You see?"

Re:Lose Carbon & AltiVec? 3rd parties not gonn

[Wesley Felter]

Apple would lose AltiVec, but they'd gain SSE and SSE2 which are almost the same thing.

Why wouldn't Carbon work on x86? It's just C code.

Reminds me of "The Blackmail Pads"

[Ungrounded Lightning]

Back when PC boards were designed with red, blue, and black tape on mylar sheets, and UARTs were the cutting edge, there were two vendors of UARTs who had somewhat different designs. A small manufacturer of terminals had designed for one of 'em. But they were new and cutting edge, and the plant capacity was limited. So the vendor was being obstinate about giving them sufficient allocation to make their production targets.

Well the alternative chip was about the same side and functionality but had different pinout. And there was some extra room on the board. So a few days before the salesman was due to visit they hauled out the mylar master for the PC board, laid out the pad pattern of the alternate chip, and started taping up something that looked like reasonable circuitry.

Sure enough, the salesman saw the work in progress, concluded that the terminal was being designed so it could be built with either UART, and paniced. After that there was never a problem getting allocation.

I think the circuitry was never finished and tested. The pads made it onto the final PC board (no point in ripping the tape back off the master) but weren't even dirlled (at 1/2 cent per hole per board). And they came to be known as "The Blackmail Pads". B-)

Of course - the evidence is there to see...

[ducasi]

Of course Apple have a x86 port of OS X. They want to keep their options open, and even if they don't move to x86 they will benefit by having an operating system that is already portable between architectures.

As for the evidence - it you do a "strings /Applications /DVD Player.app /Contents /Frameworks /DVDPlayback.framework /Versions /A /DVDPlayback | less "
(i've added spaces before each "/" to keep slashdot happy - you need to take them out again!)

Now, search for "Debug", and look at the three next lines:

DisablePIIISupport
DisableATHLONSupport
Disabl ePIVSupport

Now why would Apple's DVD Player have code concerning itself with PIII's, P4's and Athlons if they didn't have a version which ran on those chips???

Personally, I don't see Apple making the switch, but they've survived by surprising us time and time again...

Re:Of course - the evidence is there to see...

[geek]

The DVD player if I'm not mistaken was software aquired through an aquisition. Then ported to the mac. Its probably a remnent of the old application.

Re:Of course - the evidence is there to see...

[TH4L35]

Are you sure that that particular portion of code isn't some how related to the quicktime frameworks? Quicktime, of course, is concerned whether or not it is running on a pIII, p4, or athlon.

Re:Actually, this idea isn't new...

[MaxVlast]

System 7 kicked butt.

The project you're talking about is Star Trek. It happened at the same time as Taligent and Pink. Any idea where all of those things are now? Find me a Dylan programmer and we can ask him together. Or we could send him an RTF e-mail with Cyberdog. Running in Copland.

Re:what i wanna know is...

[MaxVlast]

"BTW, wont it be cool when you can set up a dual boot for mac osx and windows 2k/xp."

No.

Re:Wait a sec

[bnenning]

(Apple-Evil-Proprietory-Boot vs ACPI for example)

Macs boot via Open Firmware, which is neither evil nor proprietary.

Re:Believable you are wrong!

[DavidRavenMoon]

Corel Bryce has the code in both ports windows and mac.. on windos the library is called becasue the ativec is not there and they need to use a virtual ativec..

I don't think Bryce uses AltiVec at all.

I run Bryce in OS X, and I can attest that it's not all that fast.

Barefeats.com posted this comment:

"Although Corel claims it has been carbonized for OS X, but the rendering code does NOT take advantage of the G4 or multiple processors."

Even Apple has admitted to this before.

[Blaede]

Apple employee Vince Garcia once mentioned he had OSX running on an Intel at home back in 2000, nothing new here. And remember all those stories on Macworld of the old Mac OS ports running on Intel? Heck, I'm running OS7 right now, albeit via Basilisk.

Re:Even Apple has admitted to this before.

[Xenex]

"Apple employee Vince Garcia"

Who?

I can't find him, or anything in 2000 refering to him running OS X on an x86.

Do you have any stories you could link to?

All the 'cheap hardware' idiots, save your breath.

[phillymjs]

Apple will NEVER (read: NEVER, NEVER, NEVER) sell a version of the Mac OS that can be run on any cheap POS that you cobbled together from parts you bought in Target for $5 each. Wake up and smell the coffee, okay, because I'm getting tired of reading all your posts.

Apple sells the experience of using tightly-integrated hardware and software. They can't do that if they suddenly have to make sure their software will work with every home-built x86 whitebox on the face of the earth. What Apple does is something that Microsoft can never do, unless they start selling their own brand of computers and restrict Windows to only run on Microsoft PCs.

Even if Apple ever were to switch to making x86-based Macs (and you, the reader, are significantly more likely to bang Anna Kournikova than to see an x86-based Mac for sale), they would put something proprietary in those machines, maybe even in every component of those machines, and change the Mac OS to refuse to boot if it doesn't detect that proprietary something. That's the only way they'll be able to preserve the 'it just works' aspects that are a major part of their success.

Personally, I think Apple will,very soon, tell Motorola to go piss up a rope (and I say, it's about time!). The new IBM chip has something close enough to AltiVec, and IBM actually gives a shit about improving their products. Now that Mac OS X is truly ready for prime time with 10.2, all Apple needs is to be able to produce machines that will impress the MHz/GHz-obsessed, cock-measuring crowd.

~Philly

Trump card

[vlad_petric]

More important than the relationship with the chip manufacturer is, IMHO, the relationship with Microsoft - the direct competitor. An X86 Mac OS X is nothing but Microsoft's biggest nightmare in terms of what it can do to the PC market.

So I strongly believe that such a project would serve as a trumpcard in negociations with Microsoft more than with the CPU manufacturer.

The Raven.

Re:Trump card

[bnenning]

Precisely. Microsoft has the threat of terminating Mac Office; this is Apple's counterthreat. Things will get very interesting if either of them pulls the trigger.

Re:All the 'cheap hardware' idiots, save your brea

[CrosseyedPainless]

I sure hope you're wrong.

Mmmm.... Anna Kournikova....

Re:Wait a sec

[be-fan]

A boot standard based on Forth? How can that NOT be evil and proprietary? Yea yeah, I know, I stuck my foot in my mouth. I didn't know they changed it awhile back.

The x86 OS X Success Strategy

[Winnipenguin]

Quote:
By making an x86 version of OS X to coincide with the release of the G5, Apple could save face by showing in the inevitable side-by-side processor comparison that its computer is the performance leader. At the same time, it could appease PC users' demands that it be more open with its computing solutions.

Not only would the speed leader be obvious and indisputable, but Apple's mind-share would increase a thousand times over.

Suddenly, those OS companies that support only one processor family would acquire the unfriendly aura that hung over Apple's head for so many years."

Article here:
http://www.osopinion.com/perl/printer/17176 /

Re:Please!

[Halo1]

Do you really think Macs cost more than most PC's just because of the processor? The G4 isn't that expensive, most of the extra cost comes from the fact that Apple sells less boxes and ass such needs higher margins to be able to fund its R&D (Dell doesn't have 28% margins on its products, believe me). An Apple 80x86 box would probably still cost as much as the current PPC Macs and you'd stil be bitching...

Switch? Perhaps, but not to x86

[gerardrj]

As others have mentioned, the x86 platform is all but end-of-life. Intel is pushing ia64, well as much as they can when they have to fight their own megahertz matters campaign.
If Apple where to jump ship from the AIM PPC alliance they would almost certainly not use x86 class chips.

Some options for Apple if they need to leave Motorola in the dust:
1. The ever popular IBM option. Either continue the PPC roadmap, or start using the POWER series.
2. Start their own fab and take over development themselves, licensing AltiVec from MOT.
3. License AltiVec (or clone it) and farm out fab to a third party like they do most other components.
4. Purchase the now very dead Alpha technology from HP. The Alpha EV8 chip design was almost completed before canning, and would scream past probably all other microporocessors currently in production or design. Of course Alphas are known for their heat output as much as their processing power.

Of all the things Apple could do as far as microprocessor choice, switching to x86 seems to make the lest amount of sense both technologically, and from a marketing perspective. After all, how will Steve do those glorious "shootouts" on stage if both platforms are running the same speed and type of chip?
Apple: Our 3GHz P4 runs Photoshop 20% faster than Dell's 3GHz P4.
It just doesn't work does it? Will Apple somehow cut a deal with Intel or AMD to get the newest high-speed chips 6 months before everyone else? Doubtful.

Apple keeps it's marketing edge by focusing on performance of end-user tasks, not joining the MHz train.

Is Apple maintaining an x86 port of OS X? Very likely. Does Ford keep a fleet of GM, Toyota and other vehicles around? Very likely. Apple isn't planning on making x86 based Macs any more than Ford is going to start building and selling vevicles with GM frames or parts.

Re:Switch? Perhaps, but not to x86

[be-fan]

Apple: Our 3GHz P4 runs Photoshop 20% faster than Dell's 3GHz P4.
>>>>
Yeah. That's the real reason an x86 OS X port would never happen. It makes it harder for Apple's marketing department to lie.

Re:Switch? Perhaps, but not to x86

[gerardrj]

There is no lie. In the tests Apple puts forth (and others verify), the PPCs at lower clock rates regularly keep up with, or surpass the performancof a P4.

I have yet to see objective test of real-world tasks where a P4 at 2x the clock speed will significantly outperforma PPC.

Re:Switch? Perhaps, but not to x86

[be-fan]

Ha ha, that's a good one. And I bet you believe that A G4 smokes an Alpha just because it gets higher RC5 scores? Don't make me laugh. The G4 get's killed in the SPEC benchmarks (which are real world, btw, gcc and mesa are part of them, among others) and most importantly, gets hammer in Quake III. I'm not going to dignify this post with a further response, except to quote my favorite ArsTechnica post:
>>>>>>>>>>>>>>>&g t;

"MHz Myth"

Def: When faced with a computer that is significantly faster than a Mac.. simply scream out "MHz Myth" and wave your hands frantically. This will magically make the languishing G4 faster than the current fastest Intel or AMD Chip.

See "Up to Twice as Fast as any Pentium PC" for more details..

Re:Switch? Perhaps, but not to x86

[gerardrj]

RC5 scores are not a real-world benchmark, neither are SPEC. The first is a highly specific, CPU/cache intensive algorithm the other two are artificial benchmarks designed to test particular parts of the sytstem. By real world benchmarks I mean, launch an app and perform some common tasks, much the way Steve does with the PS tests on stage or the BYTEmark system and media suites. Many CPUs are faster than the PPC at particular tasks, just as many CPUs are slower than the PPC at particular tasks. In particular, RC5 relies heavily on an instruction that PPC, AMD and Intel happen to impliment. Alpha, MIPS, and most other CPUs don't have this particular instruction and hence must execute many others to emulate it, slowing down their performance in this endeavor.

I didn't state that the PPC "smokes" any other chip, just that I've yet to see a real-world performance test where a 2.5GHz P4 ran 2.5x faster than a G4 at 1GHz (single CPU). Yes the P4 will win some benchmarks in any test suite, perhaps all. But not by a factor that equates to the ratio of clock speed differernce between the chips. In fact the best I've seen is that in some tasks a P4@2.5Ghz is 30% faster than a G4@1Ghz. Not very impressive for a system that has 150% more clockspeed to only run 30% faster at some things, and up to 50% slower for some things than its lower clock speed competitor. Please... point me to a relatively broad-based benchmark that shows a P4 outperforming a G4 by a factor proportional to their clock speed difference.

Saying the PPC is slow because it runs at much lower clock speed is like saying that an F16 should be slower than a 747 because the 747 has more and larger engines. Yet, producing 200,000lbs of thrust, the 747 reaches less than half the top speed(~mach .9) of the F16(~mach 2) that only produces 15,000lbs of thrust. In simple terms, despite having 13 times the thrust of an F16, the 747 only goes 1/2 as fast.
Some numbers just aren't meant to be compared, and you need to look at the whole picture to understand what's going on.
Thrust != speed and Mhz != performance

Re:Switch? Perhaps, but not to x86

[be-fan]

Don't be ridiculous. Of course Mhz != performance. But the PPC loses in clockspeed by something like 2.5x. At that disparity, even if the PPC could keep its pipelines full 100% of the time due to its great architecture, it STILL wouldn't be as fast as the fastest P4. This is getting old. Go to ArsTechnica's forum, and look up G4 vs P4. Read the posts. A lot of people a whole lot smarter than you or me have put up some good info there. As for SPEC, go here. Yep, GCC and PERL sure sound like artificial benchmarks to me!

Re:Switch? Perhaps, but not to x86

[gerardrj]

How can you state that Mhz != performance, then in the very next sentence argue that Mhz = performance?
The PPC can keep up when it requires fewer instructions to process any task, and when vector processing allows massive scaling of clock cycle to work performed. Also note that there's nothing inherent in the PPC design that is limiting clock speed, it's Motorola's corporate issues that keep the speeds down.

The benchmarks in SPEC are artificial. They test particular oddball functions of a system. How often does an average user cross-compile pre-processesed C code files into Motorola 88100 processor machine language? When was the last time you needed to process the "lithography artwork needed for the production of microchips"? Never would be a reasonable guess. Of course, the point is moot as I can't locate a single PPC chip test result, never mind a PowerMac system.

A real-world benchmark in my opinion (for general use desktop systems) is using a program/code compiled and optimized for a given CPU to test some complete task that is commonly performed by the average user.
Ex: Rip an audio CD to .mp3 format, make some alterations and burn out to CDR. Load an image and perform some editing and convert it to a web suitable size/format.
Frame rates of games are pointless benchmarks. What's the point of having a graphics subsystem that can do 200FPS in quake when your monitor can only refresh at 120Hz max, and your eye can't see anything above 80hz anyway. It's like comparing the top speed of a cars when they'll never go faster than 80mph anyway. The speed becomes insignificant compared to other aspects of the system or car.

Re:Switch? Perhaps, but not to x86

[be-fan]

How can you state that Mhz != performance, then in the very next sentence argue that Mhz = performance?
>>>>>>
No, is said that MHz is a factor in performance. Performance = Instructions_Per_Cycle * Clock_Speed. If the Clock_Speed of a processor is 2.5x as much as that of another processor then the Instructions_Per_Cycle must be at least 2.5x as high to balance the difference. Even theoretically, the PowerPC chips cannot hit that kind of IPC.

The PPC can keep up when it requires fewer instructions to process any task,
>>>>>>>
Wrong! The PowerPC is a RISC chip. RISC chips, in general, require more instructions to perform a given task.

and when vector processing allows massive scaling of clock cycle to work performed.
>>>>>>>
True, but the Pentium4 has a vector unit as well. Not as good as the AltiVec unit, but in the current G4 the AltiVec unit is severely limited by the bandwidth of the PowerMac system bus. Thus, SSE2 is in the same performance league even at the same clockspeed, and on a P4, the floating point units (that processes the SSE2 instructions) have the advantage of running at 2.5x the frequency. Again, Performance = IPC * CLOCK, and with the clock being 2.5x as fast, IPC must be 2.5x as high, and AltiVec is nowhere near that much faster than SSE2.

Also note that there's nothing inherent in the PPC design that is limiting clock speed, it's Motorola's corporate issues that keep the speeds down.
>>>>>>>>>>
Actually, there are two things keeping the clock speed down, both technological. First, the G4's pipelines are short, which makes each pipeline stage more complex, which makes it harder to clock them faster. Second, Motorola's process technology isn't as good as Intel's.

The benchmarks in SPEC are artificial. They test particular oddball functions of a system. How often does an average user cross-compile pre-processesed C code files into Motorola 88100 processor machine language?
>>>>>>>>>>>>
For most of a compiler run, the source code is represented as a processor-independent parse tree. This what the optimizers work on, and this is what that SPEC test tries to measure. Only final instruction scheduling actually uses the specific architecture to be compiled, and the 88100 was used in this case because GCC's algorithms are optimized to various levels for generating code for the most popular architectures. Testing with something like x86 or PPC code would be unfair because the x86 instruction scheduler most likely has optimizations the others don't and vice versa. The 88100 is obscure enough that this isn't a problem.

When was the last time you needed to process the "lithography artwork needed for the production of microchips"?
>>>>>>
Read the whole thing. Its an optimization problem, and people in scientific computing do these sorts of things all the time. Hell, people running Quake run these sorts of optimization problems (in the AI routines) all the time.

Never would be a reasonable guess. Of course, the point is moot as I can't locate a single PPC chip test result, never mind a PowerMac system.
>>>>>>>>>
http://www.heise.de/ct/english /02/05/182/

A real-world benchmark in my opinion (for general use desktop systems) is using a program/code compiled and optimized for a given CPU to test some complete task that is commonly performed by the average user.
>>>>>>>
Apple does real world benchmarks, right? Like Photoshop (only 6.0, though, because in 7.0 Adobe added SSE2 support in addition to AltiVec and Apple loses now)? The way Apple pushes Photoshop benchmarks you'd think all those people with iMacs ran photoshop all day long! Okay, but I'll bite, here are compilation benchmarks: http://homepage.mac.com/nopea1/benchmark/ Guess what? They show a G4 running about 20% faster than a PIII at the same clock speed. That equates to about 30-35% faster than a P4 at the same clockspeed. Where is the 150% difference that's needed here to make up for the difference in clock?

Ex: Rip an audio CD to .mp3 format, make some alterations and burn out to CDR.
>>>>>>>>>>
Umm, you're mostly testing the speed of your CD drive here.

Load an image and perform some editing and convert it to a web suitable size/format.
>>>>>>>
Kinda like PSBench? Guess what, the G4 loses here too! (See ArsTechnica forum, search for PSBench)

Frame rates of games are pointless benchmarks.
>>>>>>>>
Uh, how? A 3D game is the perfect test for new media applications. The geometry transformation algorithms (a lot of 3D matrix multiplies) can take real advantage of stuff like AltiVec and SSE. Plus, the AI algorithms stress non-linear code performance (something the P4 is bad at) and the heavy use of textures really stresses memory bandwidth.

What's the point of having a graphics subsystem that can do 200FPS in quake when your monitor can only refresh at 120Hz max, and your eye can't see anything above 80hz anyway.
>>>>>>>>
Because when Doom3 comes out, a machine that can get 200fps in Quake III will be able to run it with full detail at playable speeds, while a machine that only gets 100fps in Quake III won't.

It's like comparing the top speed of a cars when they'll never go faster than 80mph anyway. The speed becomes insignificant compared to other aspects of the system or car.
>>>>>>>>
Other aspects, like how transparent it is? Seriously, though, this thread was never about transparency (or easy of use, or fludity of the GUI or workflow or whatnot) or other aspects of the system. It was about performance, an area in which Apple is sorely lacking.

Re:Switch? Perhaps, but not to x86

[gerardrj]

Lets stop making this a platform war and look at Intel's own designs:

The P4 Intel sells to consumers is designed such that is runs at high clock speeds with long pipelines.
The Xeneon and ia64 chips they market for performance in servers and professional workstations are all lower clock speed, shorter pipeline chips than the P4. Seems to me that Intel themselves are the best evidence that you get more real-world work completed with lower clock speed, more efficient chips. The last I recall is that at about 1/2 the clock speed an Itanium outperforms a P4 by a sizable margin.
AMD is also proving this with chips that run at lower clock speeds, yet provide the performance of Intel's clock speed gobblers.

Re:Switch? Perhaps, but not to x86

[be-fan]

The Xeon chips are exactly like the P4 chips except with more cache. They have only slightly lower (usually a 100Mhz or so behind) clockspeed but a lot more cache. The pipelines and such are exactly the same length.
As for the Itanium, the P4 outperforms the Itanium by a good margin, about 15% in SpecFp and 100% in SpecInt.
I don't disagree with you that a lower clocked CPU can't outperform a much higher clocked CPU. Happens all the time. A 1Ghz Alpha 21264C is just as fast as a 2Ghz P4 in floating point, and 75% as fast in integer (which is a more important measure, btw for most desktop programs like compiling or whatnot). How is this possible? Well, the Alpha has 4 integer execution units and two fully independent floating point units. In comparison, the Pentium 4 has three integer units and a single floating point unit. All things being equal (they aren't, the P4's floating point unit is stack based, which makes it slower clock-for-clock than the Alpha's) the performance figures make sense! The P4 is faster in integer because the additional integer instruction that the Alpha can do per clock doesn't make up for the clock speed. The P4 is the same speed in floating point because the Alpha has twice as many (better) floating point units. Great example of a lower clocked CPU performing as well as a higher clocked one. BUT, the G4 is no Alpha. It simply does not have as many execution resources as the Alpha, and simply cannot hope to compete at its level, much less the level of a P4. The G4 has four integer units, and a measly one floating point unit. On top of that, the integer units aren't fully independent, three of them can only do simple operations like addition and subtration. The P4, in comparison, has two simple integer units clocked at TWICE core clock (5Ghz in a 2Ghz chip) and a single complex integer unit. Note, that the P4 has quite an advantage here architecturaly. Not only can it (theoretically) complete 25% more simple integer instructions per clock cycle, but because it has only two highly-clocked units rather than four lower-clocked units, it isn't as burdened with inter-instruction dependencies as the three units in the G4e. So even architecturally, the P4 has an advantage here in terms of integer performance. Now, the P4's floating point unit is slightly slower than the G4's clock for clock, but not 2.5x as slow. When all this is factored together, the end result is that the P4 is a great deal faster than the G4 running regular integer code, and a little bit faster running regular floating point code. Now, let's take SSE2 and AltiVec into account. Theoretically, AltiVec blows SSE2 out of the water. The G4e can theoretically issue 2 floating point instructions per cycle, and be crunching on 4 simultainously. The P4, meanwhile, can only do 1 per cycle. BUT, and there is a huge BUT here. Altivec's 4 excecution units are all different. 1 is a permute unit, 1 is simple integer, 1 is complex integer, 1 is floating point. In any given application, it is highly unlikely that more than two (or even that) will be usable at the same time. Thus, being generous, AltiVec can do 2 vector ops per cycle. But there's another catch: 2 vector ops per cycle = 32 bytes of source data per cycle. Running at 1 GHz, assuming full throughput from the vector unit, that equates to 32 gigabytes of data per second! But the processor bus (running at a mere 167 MHz and 64-bits) can only deliver 1.3 GB/sec! Now there lies the problem with AltiVec. The unit itself is great, but the current G4 implementation doesn't have nearly the bus-speed necessary to feed it. Now, with its 533Mhz 64-bit bus, (4.2 GB/sec) the P4 can feed its vector unit much more data, and thus crunch many more numbers, even though its actual vector unit is slower. But how, then, can the G4 ever come close to equaling the P4 (because it does, occasionally). The answer is whenever Apple can make up benchmarks that utilize the unique quirks of the G4. The G4 has a large L3 cache, running at 500MHz (4GB/sec with 64-bit bus). On benchmarks where the dataset fits in the 2MB of L3 cache, and where the data consists of integer values, the L3 cache will be able to feed the two integer pipes in the AltiVec unit quickly enough to get some serious performance. Guess what does this? Certain Photoshop benchmarks! Of course, its use in reality is rather limited. If the dataset is small (less than 512K) then the dataset fits in the L2 caches of both chips and the P4 wins because of the clock-speed advantage. If the dataset is bigger than 2MB, the data spills out of the cache of both chips, and the P4 wins by even more because of its greater memory bandwidth. If the data-set consists of floating point data, then the AltiVec unit can essentially do only one per cycle, and the P4 wins because of the clock-speed advantage.

There you have it. A veritable treatise on why the G4 is a CPU weakling. Again, let me note that I'm not trying to say that people shouldn't buy Macs, or that they aren't nice machines in other ways ("she has a nice personality!") merely pointing out that Apple's marketing department is fully of bull.

PS> If you want to understand CPUs at some level, a good place to start is ArsTechnica (www.arstechnica.com). They are one of the only websites that actually give technical detail in their articles, much more so than you'll find in any Slashdot thread. Much of the info in this post can be found in their article "An architectural comparison of the P4 and the G4e."

Re:Switch? Perhaps, but not to x86

[gerardrj]

You keep calling the PPC a weaklink, underperformer, etc yet continually fauly to provide a link to any benchmark that shows a P4 syatem beating a PPC system by anything close to the ratio of their clock speed difference.

Your "treatise" is littered with opinion (apparently mostly quoted from Ars Technica). I prefer fact to opinion, and at this point, fact is that no-one can show me the benchmark results that show what I'm asking for.
Noplace has anyone shown (that I know of) that at 2.5 times the clock speed, that a P4 system is even twice as fast as a PowerMac.
My opinion remains that Intel builds CPUs, support shipsets and mobos that are designed soley to achieve higher clock speeds with actual real-world performance being far less than should be expected for that transistor count and current draw. AIM designs chips that are overall well balanced, and efficiet, Apple is now designing systems that are fairly well balanced and remove many previous bottlenecks (many with still exist in P4 systems).

I don't know why you say Itanium is slower than the P4. HP's testing shows that cycle for cycle the Itanium outperforms the P4 in the SPEC tests you like so much. Ex: a 1GHz Itanium is 2.1x as fast in FP than a 1.6GHz P4 Xenon.

Re:Switch? Perhaps, but not to x86

[be-fan]

You keep calling the PPC a weaklink, underperformer, etc yet continually fauly to provide a link to any benchmark that shows a P4 syatem beating a PPC system by anything close to the ratio of their clock speed difference.
>>>>>>>>>>
I pointed you to the ArsTechnica forum. They sum up the benchmarks much better than I ever could. There is a specific thread full of benchmark results. But if you want:
http://www.digitalvideoediting.com/2002/05_ may/fea tures/cw_aeshowdown.htm
http://www.digitalvideoed iting.com/2002/07_jul/fea tures/cw_macvspc2.htm
http://www.heise.de/ct/engl ish/02/05/182/

Go to the ArsTechnica site for mroe info.

Your "treatise" is littered with opinion
(apparently mostly quoted from Ars Technica).
>>>>>>
Like what? The G4 has 4 integer units? That's opinion? To feed the AltiVec units at full power you need 32GB/sec of bandwidth, while the Mac system bus only provides 1.3GB/sec of bandwidth, that's opinion? You have yet to give me a single factual statement that might confirm that the G4 is competitive with Pentium 4s. Point to some aspect of the architecture that indicates that might be the case. G4 proponents seem to believe that there is something magic in the PPC architecture that allows a G4 to process twice as much data in a given clock cycle than a Pentium 4, to make up for the clock speed difference. I'm showing you exactly how the G4 not only has no magic in it, but in many ways, its architecture is not as good as the P4's, clockspeed aside. Architecture aside, clock-speed aside, its not even theoretically possible for the G4 to be competitive with a P4. Most code doesn't have nearly enough parallism to feed an instructions per cycle number much higher than current x86 chips. In those special cases where where code does have that level of parallelism, the G4's memory bandwidth issues prevent the CPU from taking full advantage of its architectural good points.

Noplace has anyone shown (that I know of) that at 2.5 times the clock speed, that a P4 system is even twice as fast as a PowerMac.
>>>>>>>
Its not twice as fast as a PowerMac. Its more like 50-75% faster. In some cases its much closer to 100% (where memory bandwidth comes into play) and in same cases (much rarer) where the G4's L3 cache or vector permute unit becomes useful, the gap is much smaller. But remember that 50-75% is about the same as x86 chips with similar clock-speed differences. In this era of 2.5 GHz P4s, I consider a 1.5 GHz P4 to be a weakling/underperformer/etc, just as I consider a G4 to be an underperformer. And if you'd just go to the damn Ars forum, you'd see them.

I don't know why you say Itanium is slower than the P4. HP's testing shows [hp.com]that cycle for cycle the Itanium outperforms the P4 in the SPEC tests you like so much. Ex: a 1GHz Itanium is 2.1x as fast in FP than a 1.6GHz P4 Xenon.
>>>>>>>>
You're link pointed to an article about an Itanium2. I was talking about the Itanium-1. Read up on the architecture of the Itanium2 sometime. The thing has 6 integer units, 2 floating point units, a vector unit, megabytes of cache, 328 registers, can issue 11 instructions per cycle, and has 6.4 GB/second of bus bandwidth. OF COURSE ITS TWICE AS FAST AS A P4! But a G4 doesn't have all those things. What makes it faster? Nothing, because its not! Lets look at this mathematically. Well judge the performance of the G4 by making some relationships (see spec.org for benchmarks). The fastest P4 is more than 50% faster, in integer, than the fastest Alpha (1GHz). In order to be competitive with the Alpha, the G4 has to be faster than an Alpha at the same clock-speed. Both CPUs have 4 integer units. Both are RISC. However, the Alpha has twice the internal cache, 4x the external cache, many times the bus bandwidth, and is recognized as being one of the best CPU architectures ever built. Are you still going to tell me the G4 is faster clock-for-clock?

My opinion remains that Intel builds CPUs, support shipsets and mobos that are designed soley to achieve higher clock speeds with actual real-world performance being far less than should be expected for that transistor count and current draw.
>>>>>>>.
Nobody's arguing about which CPU is more efficient. But in the world of desktops, 40w vs 14w really doesn't make a single ounce of difference. That's the difference between one-sixth a lightbulb and one-half. What counts is ultimate, wall-clock performance.

AMD designs chips that are overall well balanced, and efficiet,
>>>>>>
Hah! Shows how much you know about CPUs! The AMD chips run hotter and draw more current than their Intel counterparts. Only for a short time (0.18 micron Willamette) did AMD draw less current. In terms of transistors, they're maybe 20% smaller, but that doesn't mean much.

Apple is now designing systems that are fairly well balanced and remove many previous bottlenecks (many with still exist in P4 systems).
>>>>>>>>
What kind of bottlenecks? Apple systems have some terribe bottlenecks. The measly 167Mhz bus being one of them. Everyone else and their mother has already moved to double and quad pumped busses, and Apple is stuck with technology slightly better than PC133. P4s currently have 4.2 GB/sec of memory bandwidth. AMD (with Clawhammer) is moving towards 6.4 GB/sec. Apple has 2.7 GB/sec (theoretical) and 1.3 GB/sec (actual). What bottleneck's does Apple fix? If you mean the stupid architecture "documentation" they've got on their site, its bull. Its a standard NorthBridge/SouthBridge architecture, and despite their claims of a "DirectPCI bus" its a standard PCI bus setup as well. In fact, the vanilla NorthBridge/SouthBridge connected via the PCI bus setup is quite dated. All modern x86 chipsets use either the hub architecture, or connect their North/South bridges together via dedicated high-speed busses. The only "bottleneck" breaking Apple does is add the L3 cache. Sure its significant, and allows the G4 to do well on certain benchmarks, but it only runs at 4GB/sec, slower than the main memory on modern P4 systems.

Re:Switch? Perhaps, but not to x86

[gerardrj]

I never said AMD makes well balanced efficient chips, I said AIM makes well balanced efficienc chips. If you knew much about the PPC you would know AIM stands for Apple, IBM, Motorola, the three companies that set the design standards for the PPC lineup.
Apple's system bus problems are not a limitation of Apple's design, but part of the issue of Motorola's lagging behind in keeping thing up to date. That is what lead to the initial discussion of moving to another chipset.

As for current draw I thought I'd read the P4s take something more like 65W, not 40W. IF I get ti right, Intel's own specs pin the P4 2.8 at a max draw of 75W.

The benchmarks you referenced are interesting but I must say I am troubled by comments like this in the text: "And, as expected, the Mac dual 1GHz G4 could not even come close to keeping up". While I don't dispute that the Mac looses many of the benchmarks (never said it was faster than a P4, just that the MHz gap doesn't provide as substantial a gap as one might think), I will state that it isn't soundly trounced. Many of their benchmarks are entirely too short running to be useful for comparison (1 to 5 second run times). Most of the longer ones show the x86 machines to be 60% faster at most. So again I state... 2.5 times the clock speed, and only 60% better performance?

Re:Switch? Perhaps, but not to x86

[be-fan]

You're right about the wattage, I was using older numbers from the 2.2 GHz P4. But, I'd also mention that the 1 GHz G4 draws a maximum of 30 watts, not 18. Either way, as long as its less than 100w, who cares? I mean most monitors use > 150w, so is the processor really an issue?

I will state that it isn't soundly trounced.
>>>>>>>>>>
60% is soundly trounced, especially considering the cost of the machine and the fact that when moving to even more data-heavy benchmarks the slow bus speed of the G4 will probably hurt it even more.

2.5 times the clock speed, and only 60% better performance?
>>>>>
Yes. Performance doesn't scale linearly with clock-speed, even among chips within the same architecture. A 2 GHz Athlon XP is not 100% faster than a 1 Ghz Athlon. Its closer to 50-60% faster. But that's still very significant, even $800 HPs are being sold with 1.5 GHz Athlons these days.

As for the runtimes of the comparison, 1-5 seconds is 1 - 5 billion clock-cycles. Short, yes, but entirely sufficient for CPU benchmarking.

Now, there is a lot of talk about benchmarks not being important. Is 60% faster really sufficient to brand one processor a slowpoke and another one wickedly fast? I contend, yes. Its not necessarily to say that one system is better than another just because of the processor, but the processor itself should cry itself to sleep at nights in shame. 60% (or more given data heavy benchmarks) will let you finish your work quicker, and spend less time waiting for your computer to respond to things. Personally, I noticed a very visible improvement when I moved from my 1.5Ghz Athlon to my 2GHz P4. In reality, the P4 is probably 20% or less faster, but my machine feels less unusably slow. /. isn't for average users who putter around with email and Word. Its for power users, and until every conceivable operation can be done in less than 0.3 seconds (human response time) then its still too slow.

This != Mac Clones

[feldsteins]

There are really two things to consider:

First, that Apple will solder proprietary widgets to the Macintosh motherboard which the OS will look for before booting. No widget, no boot. Simple as that.

Now you might say, "someone will reverse engineer it and then there will be rampant Mac clones," which brings us to the second point...

Second, even though it's totally possible to reverse engineer these types of widgets it's not realistic to do so. This is simply because Apple can change it willy-nilly any time they freakin' want to. Who is going to continue to invest in reverse engineering in order to remain compatible? Nobody. Don't believe it? Consider that you can buy G4 processors and you can buy all the standard Mac motherboard stuff...and absolutely nothing is stopping you from reverse engineering the proprietary widgets in use right now...and thus making your own Mac clone business...and yet nobody is doing it. I see no reason to believe that this will be a more attractive prospect just because Apple switches processors.

Re:This != Mac Clones

[Reality Master 101]

The difference is that it's a lot easier to add a widget to a commodity x86 board than it is to completely reengineer a G4 board.

This is the same argument as "Microsoft will just change the APIs". Apple can't just willy-nilly change things, because they break backward compatibility with all the existing widgets. Apple is obnoxious about making everybody upgrade their hardware, but they can't do it every operating system release.

Re:This != Mac Clones

[BitGeek]

You see this said alot but it doesn't make sense. IF Apple moved to the x86 platform (which I don't think they are going to do in the next 5 years) then there would be no "widgets" on the mother board that the OS looks for in order to boot-- that would be impossible, without close-sourcing OSX.

Remember darwin is open sourced. Its there at anonymous CVS on the opendarwin.org site. OS X just runs on top of this, so it would be trivial-- in an x86 version of the OS-- to have the OS report that "Yep, I found the widget, this is genuine apple hardware!" even on a typical not-going-to-keep-working-for-more-than-six-months -because-of-solder-burrs-and-bad-joints PC Motherboard.

IF Apple moves to the x86 platform, it would mean they are giving up the hardware strategy and are going software only-- or that they have some magical hardware that they think will be compelling enough to get people to run OS X on Apple hardware even though it runs on clones. The latter I think is a lot less likely than the former.

I won't rule out Apple going to x86, but it won't happen soon, and if it does, there *will* be a "clone" market... or apple will be software only.

And the world will be a sadder place. Apple's hardware is wonderful. ITs especially nice to have a computer that keeps working after 6 years, let alone 6 months.

Negociating with microsoft?

[jmv]

That way, Apple can tell M$: "If you don't release Word for OS X, we'll release OS X on x86"...

Re:Negociating with microsoft?

[G0SP0DAR]

That's interesting, but would that be why OS X 10.2 still doesn't play nice with SMB servers? You'd think they could at least get WINS addresses via DHCP...of course that may be reading into the M$ thing a little too much

A good way to flush out the bugs...

[Spoing]

Apple already used a cross platform OS as the core of OSX; BSD.^

As we've seen with the other software from applications, services (Apache...), and operating systems (*BSDs, Linux, ...), porting to different hardware cleans up quite a few bugs -- from system design mistakes to simple coding errors that 'work' mostly by accident.

Even if there's zero reason to release an x86 port of OSX (or later), the benifits for the PPC OSX still exist.

^ - Corrections & clarifacations apprecated.

Question for OS X users.

[FreeLinux]

Can an OS X user copy an object from one application to another? Specifically, can you right click an image in your browser choose "Copy" and then past that image into your word processor or Photo Shop?

Re:Question for OS X users.

[RAVasquez]

Sure. But we prefer to drag and drop them.

Re:Question for OS X users.

[be-fan]

I've never understood drag and drop. Its so inefficient. I tend to run my web browsers full screen and my word processors full screen. I'd bet that this is something most people do. Thus, drag and drop becomes a very exacting process, where meanwhile right-click->copy and right-click->past is so much more efficient! Perhaps the real reason OS-X users prefer drag and drop is that they have to go all the way to the keyboard to "right-click."

Re:Question for OS X users.

[geek]

Traditionally Mac users have more than one monitor (being graphics people etc) so it's very nice, especially with dual 23" flat screens :)

If you run a browser in full screen on one of those you are wasting a whole lot of screen real estate.

Re:Question for OS X users.

[Slur]

Yes. In fact we've been able to do this since System 7, not to mention lots of other things that Windows users would have considered "cutting-edge" had they been aware.

Here's one use...

[MrIcee]

All the posts about how such a move might alienate apple from it's customers and vendors...

There is one use of X86 hardware that would not alienate customers and vendors... embedded systems. Similar to the iPod (but probably more capable... such as iPhones, or iWear etc...) X86 port might make very much sense. The hardware is faster, cheaper and better supported from the chip makers. If programming is not an option from the user/developer view than that will not alienate very many people.

The one thing Apple is king of is packaging and beautiful designs.... closed system owners won't care what processor is under the hood, and it might allow Apple to create systems with more choices (chip wise) and potentially at less cost.

Re:Why Mac OS X on PC platform makes no sense (sho

[Tokerat]

Do you know where detailed information can be found about the Power4 chips? I've heard a lot of buzz lately around this and would like to see for myself.

It's really sad that Motorola is delivering as poorly as they are. I wished for the longest time that they where just "stalling" with the incremental upgrading because they had somrthing cool in the works that needed refining...however now I have lost hope. I was really looking forward to the period in time when the "G6" would be seeing the light (2005? 06?), because by then I'd have the money to buy a new top-of-the-line Apple, which, for a full, decent system-of-my-dreams, would set me back a good $12,000 or more (note: including a complete Dolby Digital 5.1 reciever and speakers, audio card to go with it, dual head 23" Cinema displays, etc :-) ). Now I wonder if I'll buy buying an Apple Macintosh Power5 or something....

...whatever, as long as it's fast and fundementally still Mac, I'll be alright.

Re:Backup plan

[cant_get_a_good_nick]

Darwin is already x86 compatible, not that hard since it essentially a Mixed BSD and Mach core. OS X is based a lot on NeXT which in later years ran on x86 hardware. The Classic environment would be the biggest problem, thogh there were some aborted ports to x86, and remember that it's already been "ported" (and rewritten probably) going from 68K to PowerPC. Some important tools (eg QuickTime) already are on x86, so they have experience across chips. I doubt if many parts of the tree are "x86 only", they cut their teeth already on porting issues, I doubt if much is dirty, and they don't have a totally separate tree, maybe a branch or two. Look at Linux, they don't have an Alpha source tree. Isn't even the mainframe stuff part of the main tree now?

As to why, you need to keep your options open. Look what happened to Be, they swapped chips. Didn't help them much, went from competing with Mac hardware to competing on Microsoft's home turf, and they were hurt by that (though there were many times they shot themselves in the foot). If Iwas a shareholder, I'd expect this, haivng soemthing ready for a switch if it ever became necessary.

I think your analogy to a game developer is flawed. I personally thnk Apple's situation is more complex than can be summed up in a simple analogy.

• Apple sells hardware. Though as most said, Apple probably wouldn't make this available on general PC hardware, just on Apple branded x86es, they still have to start making the boxes. x86 margins are razor thin. By being essentially the only PowerPC hardware maker (they killed the clone market, pissing off Motorola) they have more to say about their hardware margins than say, HP.
  
• They'd need an infrastructure of apps and developers. PowerPC was so much faster than the long in the tooth 68k series that emulation was acceptible. Not fast, but acceptable. Things got better as more of the core got ported to PowerPC. The Pentium series isn't an order of magnitude faster (some would debate if it's faster at all, but thats not my flamewar). Old apps running a PowerPC emulator on the x86 would be slow.
  
• They can't piss off their chip supplier, not yet anyway. Luckily they have IBM in the wings. Motorola and Apple have been fighting for years. it's definitely a marriage of convenience now, but there's still that dependency.
  
• They'd be seen as tougher competition for microsoft, which still controls the most important apps to most MacOS users, Office. I'd never expect an MacOS X x86 native office suite. Maybe using the WINE will be good enough then for using Win32 Office on a mac, but without Office, this is a pipe dream. I don't follow the legalities of Microsoft and WINE, but I'd be interesting what MSs lawyers have to say at that point. They may allow a non-corporation, the Linux community to run WINE, but if it's a default install by a corporation? Even if Apple won, it would sap them of capital and time.
  If it did have WINE, it may bring up the irony of having x86 MS apps running much faster on x86 OS X than MacOS apps (emulated PowerPC).
  
• It would require 2 versions of apps. Even without source changes, it doubles your test matrix (maybe more, more variation in PC hardware) and doubles your shelf space requirements in the stores. See WinNT on Alpha, or PowerPC, or Solaris on PowerPC for examples of why this isn't a very workable idea.
  

Re:Support

[SoupIsGoodFood_42]

You seem to be under the impresion that if Apple went Intel, that they would start selling fully PC compatible Macs. I doubt that will happen. The only thing that they want to change is the chip, they will still make their own motherborad. In other words, they will still have control over their hardware.

Re:Oh really?

[DavidRavenMoon]

you're spelling is also astounding ... :)

YOUR spelling isn't so good either ;)

Re:Oh really?

[DavidRavenMoon]

Waitaminute -- Microsoft beat me to the punch last year. Bummer.

Microsoft put Apple out of business? When did that happen?

Re:Support

[DavidRavenMoon]

support costs will kill them.

Yep. Look what happened to Be after they switched to x86.

It's A Bluff...

[Shuh]

The x86 architecture is where old proprietary operating systems go to die... OS/2, BeOS, Novell, NeXT, etc.

Nevermind the illusion of "openness," the proprietary-by-way-of-monopoly-power P.C. standards (and OEM's) are all controlled by Microsoft, so anything that isn't given away free (e.g. Linux), will be squished like a bug in that space.

Apple's Trump Card against MS.

[cryptochrome]

I think the advantages of actually putting out an x86 version of os x (which by the way went by the name "Star Trek" before, IIRC) are outweighed by the various (mostly hardware-revenue related) disadvantages.

However, it's an invaluable asset to have anyway, because you can blackmail microsoft with it. Remember when MS bought all that Apple stock? Remember what dire straights Apple has been in in the past? Despite all that, Mac OS remains to this day the only consumer OS besides windows that has managed to gain and hold onto a significant userbase versus Windows. And it has a lot of software. So pretend you're Bill Gates, and Steve Jobs gives you a ring and says "If we start to go under, for any reason, we're releasing our x86 build of Mac OS X... as open source." There's not enough TP in Redmond to handle that kind of threat. Or any of the lesser ones they could make too.

Re:Actually, this idea isn't new...

[Etcetera]

Oh come on Windows had premeptive multi tasking and nice true type fonts by late 94.

Not sure if that's a joke or not, but...

System 7 introduced TrueType in 1990. True, true preemptive multitasking didn't arrive on the Mac until OS X (unless you count Copland), but some would argue that in a single-user environment, pre-emptive multitasking isn't all that it's cracked up to be in terms of real-world uses. Sometimes you WANT apps to "self-coordinate" their process time.

I wouldn't want my school's 30,000-user Solaris box running in cooperative multitasking, but a personal machine won't be getting that kind of use anyway.

Article on Artificial Cheese

[batobin]

It's kind of late, but I wrote my 2 cents about the article on Artificial Cheese. Here's a link.

And here it is pasted: http://artificialcheese.com/story/2002/8/31/161044 /348

But imagine the damage to MS an OSX XBOX Port ...

[NZheretic]

... could do.

Re:Debian packaging is actually quite good

[jbolden]

> On another note, why isn't it possible for outside people to port JUST Aqua over? I don't
> care if the install programs can't detect my hardware in a snap (I can do that myself), but
> I'd sure love to have the pretty GUI on my desktop... It'd be a step in the right direction.

Well there is an X11 window manager called oroborosx which is based on oroboros window manager (available on x86) which looks look Aqua. So the mac crowd has already ported a Mac look a like to their X11. You could probably do a reverse port of the skin in now time.

Think different, think LinuxPPC

[axxackall]

just to complete the picture: Yellow Dog is not the only Linux distro running on PPC. I've tried successfully: LinuxPPC (now dead, last distro is 2000'Q4), Debian and Gentoo. And I heard about some success of porting of FreeBSD and NetBSD to PPC platform, partiuarly into Mac/PPC.

Why am I telling it? I think Mac OS (including Mac OS X) users should use the same formula as was driving users from PC to Mac - "Think different, think Apple!", but now with a small change: "Think different, think Linux/PPC". Mac/PPC world should not be and is not limited by the dictated choice of the sector monopolist (Apple). And Linux is doing the same great job is it's doing on the PC sector - it's giving the choice for people. The choice of OS.

Seriosly, think about it. What kind of choice Mac gives to people? To spend another $1K for more expensive hardware and then to stick with Mac OS after discovering lots of Mac OS (even OS X) problems? With Linux/PPC people can buy Mac/PPC and use same skills as they have with Linux/x86.

I think that Apple, instead of porting of Mac OS X into PC/x86, should officially support (and contribute!) Linux/PPC. Eventually Apple should either port Aqua to Linux/X11 or to give up Mac OS at all.

Re:Think different, think LinuxPPC

[castanaveras]

For most people, it's worth $129 to not have to waste days fucking around with kernel modules every time they want to add new hardware.

Personally, I use Linux and FreeBSD for my servers, but I'm a geek. Joe Consumer just wants to be able to open M$ Office documents, use Photoshop and Dreamweaver, play games and mess around with their digital camera and DV camcorder, and OS X lets them do that without hassles.

Joe Consumer is never going to want to figure out how much of a swap partition to make, what kernel modules to compile in, how to tweak X Window to get a different resolution, or any of the other geeky things we can^whave to do with Linux or BSD.

What, exactly, do you think running Linux instead of Mac OS X will do for you? Other than keep you from running commercial applications, I mean.

You can basically build any unix app that runs on BSD on Mac OS X, but if you run Linux or one of the open source BSDs, you won't be able to run things like Photoshop.

Or InDesign.

Or Illustrator.

And forget commercial games.

Or watch QuickTime movies.

Don't bother bringing up GIMP until it does 4 color separations. Or proper color correction.

As irrelevant as these things may seem to you, they're what Joe Consumer wants to use their machines for.

You really think Apple is going to give up Mac OS for Linux? Get a grip. What makes a Mac special is that it just works for what most people want to use it for. They put in a second video card, reboot, and the second display just works, without spending an afternoon fucking around with X Window. They want to capture video, they just plug in their DV camcorder and it just works. No fucking around building a new kernel with 1394 support and trying to figure out how to get it to actually see the camera. Etc, etc.

What makes this possible is that Apple controls the software and the hardware, and the software doesn't have to deal with a hundred different 1394 cards, or hundreds of crappy old video cards that someone picked up at a garage sale. They built the hardware, they can be sure what is going to be there.

Re:Backup plan

[be-fan]

whole seperate codebase "just in case" be a bit much?
>>>>>>>>
Well, let's see. Darwin, the core, already runs on x86, and thats where all the hardware dependent stuff is. The high-level stuff should be completely portable (just like KDE is mostly a recompile away from working on PPC, for example), with only some optimized AltiVec routines needing rewriting.

Re:Lose Carbon & AltiVec? 3rd parties not gonn

[jbolden]

> The PPC vendors obviously don't care too much about putting enough development money into their
> products to compete, so it's time to switch to a vendor that does care.

IBM cares, they've based their whole RS/6000 (pSeries now)line on PPC. I don't think they want to get knocked out of that market. Its the 32 bit PPC which is having trouble.

Just look at the author's name

[hoytt]

One of the authors is Nick dePlume, editor-in-chief of http://www.thinksecret.com. This site has a bit shaky reputation when it comes to rumours. The have a few hits, but most of the things they publish are blanks. In the past this site has had various rumours about OS X on x86 hardware. None of which turned out te be anything. Just because they publish and article on eweek doesn't mean it's more credible.

According to sources, the Cupertino, Calif., Mac maker has been working steadily on maintaining current, PC-compatible builds of its Unix-based OS.

This doesn't shed any light. Unless they come with a more reliable thing than 'sources' I think it's a miss.

Re:pentium pro first to have risc-ish core

[leviramsey]

Starting with the 486, Intel had begun to incorporate some RISC ideas (first pipelines, then superscalar design, culminating in the P6's RISC core).

I always laugh when I read the late-80s/early-90s FUD (which some continue spout to this day) about RISC vs. CISC. Neither style won: they merged.

Re:OSX on cheap x86 hardware would be great!

[be-fan]

For most retailers, you can't even configure a machine that matches a low-end iMac. The closest I could find is this an $1120 Dell vs this a $1433 Apple iMac. Even then, its not a fair comparison because the Dell is using an UltraSharp flat panel (vs the regular flat panel in the iMac, which has more ghosting and less contrast) hooked to a GeForce4 MX (vs the GeForce2 MX in the iMac) and with a vastly superior 1.8 GHz Pentium 4 (vs the 700 MHz G4 in the iMac). That's $200, and at the low end, thats a huge chunk of change. At the high end, I can configure a Dell Precision Workstation with dual 2.4 Ghz P4 Xeon procs, Quadro4 graphics, 2GB of RAM, 120 GB of disk, DVD-RW, 20" flat panel, etc, to compete with Apple top of the line machine with comparable features, but vastly slower procs, a non-workstation graphics card (regular GeForce4) and a 23" flat panel display.

Re:Oh really?

[be-fan]

You could build a couple AMD boxes with quality assured hardware, tested and retested to make sure its bug free, that included Gigabit Ethernet, Firewire and a host of awesome applications such as iTunes, iMovie etc.... for 1600?
>>>>>>>>>>>>..
Yes. As for the gigabit ethernet comment, who gets gigabit ethernet into their desktop? How is this a feature? Its Apple's bullshit again. Besides, a gigabit ethernet card is $50, so I don't think it counts much towards the $1600. I built a machine over the summer (Athlon XP 2000) for about $850. I'd be willing to put it up against a low-end G4 any day.

Re:you don't even know what you're talking about

[MoneyT]

An "Apple Document" without the 3 pages of legalize that accompanies every Apple document? I DON'T THINK SO. Show me proof from Apple's web site, not from somewhere else

Re:you don't even know what you're talking about

[be-fan]

If you took a look at the URL, you'd see that that's a document from Apple's Siggraph 2002 presentation. Do you think Apple would put all the pure technical detail (heavy sarcasm) in that PDF on their website where the Mac users go? They don't even tell you what kind of sound card the machines you're buying comes with! If you still don't believe me, the the article is on OSNews.

Re:Why Mac OS X on PC platform makes no sense (sho

[MoneyT]

I personaly woul dbe less interested in seeing processor improvements (since they really don't do much for me any more) and more improvements elsewhere. What good is a 3 Ghz processor and 5mhz memory when the PCI bus is still slow? Or the AGP slots are slow? What about HDDs? Those things haven't seen a significant speed increase in a long while, and SCSI is still too expensive to make it a viable alternative. Or instead of working on upping the processor speed, let's work on improving the current processors. Let's take our 15 and 20 stage processors and work on developing them so that they maintain their speed while running with shorter pipelines. Let's see some real innovations.

CISC on RISC is easier than RISC on CISC.

[neurojab]

It's pretty easy for me to see why emulating cisc on risc would be easier than the other way around... I mean easier as in easier to make a usably fast emulator. The emulator needs to do its work at the opcode level. Think about it this way (overly simplified): let's say I need to do a chunk of work on each. The cisc architecture can do the chunk in N instructions. Each of those instructions takes X clock cycles, so the chunk is NX in work. On RISC, I take M instructions, and each instruction takes 1 clock cycle, so my work is M. Let's say that we have performance competitive machines so NX=M. My emulator is going to need a certain number of native instructions to emulate each foriegn one. Now I'm lazy (but still write in assembler), so I'm only going to emulate one opcode at a time. When I use RISC to emulate CISC, my minimum unit of work is NX, because I can use a certain number of RISC instructions for each CISC. When I go the other way around (because of my assumption that I'm too lazy to intelligently combine opcodes), however, I need at least one CISC instruction for every RISC. This puts my minimum unit of work at MX!
MX >> NX because of my earlier assertion that NX=M.

Re:CISC on RISC is easier than RISC on CISC.

[neurojab]

And on the PowerPC architecture you're going to have more instructions to do the same work (that's fundamental to RISC)... 10-20% better performance at the same clock rate, and more instructions to process...It seems like the RISC chip really is getting a lot more instructions through for the same number of clock cycles. Couldn't you generalize that to a multiplicative factor (perhaps more than 1 and less than 2)?

Re:Why PPC is a lower form of life

[MoneyT]

Funny, IE loads in 1 second on my 300 Mhz iBook as compared to 2 seconds on my Athon XP 2000+

My mac can easily handle me opening 4 applications at the same time and open them all in a reasonable amout of time. My Athon on the other hand has a heart attack when I try to open AIM, IE, Outlook and WinAMP at the same time.

Did I mention that the mac is just a hell of a lot easier to use, and hence faster on the user end?

Re:All the 'cheap hardware' idiots, save your brea

[Jay Carlson]

Even if Apple ever were to switch to making x86-based Macs (and you, the reader, are significantly more likely to bang Anna Kournikova than to see an x86-based Mac for sale), they would put something proprietary in those machines, maybe even in every component of those machines, and change the Mac OS to refuse to boot if it doesn't detect that proprietary something.

In the world I come from, proprietary hardware gratuitously inserted into a system to control where software can be run has a name.

It's called a dongle.

Apple's in a funny position. What they sell is hardware, but the core value provided to customers is software.

(Don't believe me about the software? Look at how well the Mac clones sold, and how many people here are drooling over the possibility of inexpensive, non-crippled hardware to run OS X...)

Re:All the 'cheap hardware' idiots, save your brea

[tshak]

And here we go with an uniformed Apple elitist droning on about his superior hardware quality. I will commend Apple's recent efforts and say that they offer the most elegent package for the home user, however, they could do the same with x86 hardware. Just because you can but cheap x86 hardware does not mean that you can not build a very high quality x86 box. As an x86 OEM, apple could still build their funky cases, still design a proprietary motherboard (which most OEM's do currently), and still tightly control the hardware.

Now that Mac OS X is truly ready for prime time with 10.2, all Apple needs is to be able to produce machines that will impress the MHz/GHz-obsessed, cock-measuring crowd.


Actually, since Apple is so focused on the multimedia segment, they are really hurting on the hardware side. My $1000 Athlon box is out rendering $3000 G4 boxes. Why? Mainly because of Apples very slow FSB, and relatively slow chips. And no, I'm not just talking about clock speed, even Carmack admits that PPC's are slower then x86's for Doom, and that optimizations for Altivec only have significant value in a limited number of situations. This isn't to say that PPC's are awesome for certain tasks, especially where raw performance is not required. As you said, coupled with OS 10.2, Apple has a very good consumer product.

I'm not saying as a business decision that Apple should do this, but I'm saying that from a purely technical standpoint it would not affect the quality of Apple products.

Re:This is B.S.

[MoneyT]

You don't even have to look that deep into it. Look at the code name. After nearly 5 years of code names like Copland, Rhapsody, Jaguar, Tempest, Wall Street, Nitro, Tsunami, Trident, Cyan, Titan, Allegro, Tempo and the like that Apple would generate a project code named Marklar?

OS X on Crusoe?

[Tumbleweed]

OH MAMA, if I could have OS X running on a Sony PictureBook, I...I don't know how I'd take the ecstasy!

To quote Wayne and Garth: "*Schwing!*" :)

Re:Why Mac OS X on PC platform makes no sense (sho

[PythonOrRuby]

Actually, the prices for an Apple-branded x86 machine would likely be higher, as processors from Intel and AMD are quite a bit higher than prices for PPC chips.

I'm not an expert on this subject, and this might be nothing more than uninformed speculation, but I'm guessing this is the price OEMs pay for having lots of frequent updates in processors. Intel and AMD spend a lot on R&D for these things, then have short, relatively low volume production runs leading to lower marginal profits on each unit sold.

Re:Wait a sec

[moof1138]

Apple-Evil-Proprietory-Boot = IEEE 1275. An open standard used by Sun, IBM, and Apple.

Re:All the 'cheap hardware' idiots, save your brea

[phillymjs]

I will commend Apple's recent efforts and say that they offer the most elegant package for the home user, however, they could do the same with x86 hardware.

Show me in my post where I said they couldn't. I think you were so excited about hitting "Reply" and calling me an Apple elitist, you saw things that I didn't write.

From a technical standpoint (software developer alienation issues aside), I believe Apple certainly could pull off switching to x86 from PPC. Look how seamlessly they moved from 680x0 to PPC. It would just be a bad idea to move to x86, IMHO, because Intel, etc can't keep wringing additional cycles out of it forever. The architecture is old and tired, and it's time to take it out back and shoot it. Not time for another major comptuer maker to adopt it.

Just because you can buy cheap x86 hardware does not mean that you can not build a very high quality x86 box.

I know that. I've built several PCs in the last few years, and I know that quality components can be had for reasonable prices. But I'm in the minority who is willing to pay for quality. My post, on the other hand, was railing against the majority, who expect to run Mac OS X on a $299 PC from Wal-Mart or their home-built shitbox made from components they found in the dumpster behind CompUSA.

You can't have it both ways. You can't build a system yourself for pocket change, out of components chosen by lowest price, from hundreds of different manufacturers, and have everything work 100% seamlessly. If it were possible, Microsoft would have done it by now.

~Philly

It's a fallback position

[artemis67]

Apple is just keeping their options open, they don't have a serious desire to switch. If their relationship with Motorola totally falls apart, and IBM isn't an option, then Apple has a fallback position. They don't have to scramble and spend a year or two trying to port OS X to Intel.

However, remeber OpenStep? Jobs was never terribly successful with NeXT, and determined to ride it out to the very end. He ditched the hardware and ported OpenStep to x86. Unfortunately, NeXT continued to decline; selling a shrink-wrapped OS for x86 was not the solution.

I guess it might be a viable alternative for Apple, though, in about 5 years, when most of the new apps are written in Cocoa and can be easily transferred. It would also require that Apple have a string of successful software titles that generate the bulk of their revenue, much as Microsoft has, because Apple wouldn't be able to rely on generous hardware margins anymore.

Re:OSX on cheap x86 hardware would be great!

[be-fan]

Yes, the cheap Dell is better in some ways then the cheap Apple. But then again, you forgot to add the video editing bundle and the CD burner, which bumps the price up somewhat. Besides, I'd pay $200 extra to use OS X.
>>>>>>>>
Sorry, the link was bad. Dell order-form doesn't allow deep linking. I priced in a CDR at the $1120 price point. And you might like to use OS X, but Windows XP is pretty damn good for the average home user, and they would probably take the $200.

As for the high end - dual 1.25Ghz G4s aren't "vastly slower" than dual 2.4Ghz P4s. For your average office app or game, you won't notice a difference.
>>>>>>>
Oh please, that's bull. The Office app will be slower because OS X's GUI is slower. The game will be slower because G4s are nowhere near as fast as P4s. PC World did some benchmarks awhile ago that showed that Quake III was 50% faster on a P4 1.5 Ghz than on a G4 733 MHz, using EXACTLY THE SAME GRAPHICS CARD. That meant the the CPU on the P4 was a good deal more than 50% faster. Assuming for a moment that this scales with the different CPU types here (which it doesn't, because the Xeon has a much larger full speed cache as opposed to the G4's external, fractional speed cache) that still puts the dual P4s at more than 50% faster. And this doesn't take into account that the G4 doesn't effectively utilize DDR-SDRAM, and as games become more memory-bandwidth limited (Doom III) the effectivly PC-133 performance on the G4s will be blown away by the 3.2 GB/sec of bandwidth on the Xeons. And if you go into apps besides games and office (like gcc and whatnot) then you're covered by the SPEC benchmarks, and we all know how poorly the G4 does in those.

For multimedia purposes, the G4s are probably at least as fast, due to Altivec. Yes, I know, Altivec isn't an omnipotent silver bullet, but it still kicks ass.
>>>>>
Ha. There is a lot of talk on this (one giant 1200 post thread on ArsTechnica) and the general conclusion is that given the limitations of Apple's platform (namely memory bandwidth) AltiVec really isn't that much faster than SSE2 except in a few special cases where its permute instructions are useful. Otherwise, the P4s smoke the G4.

And if I have the choice between a Dell 20" flat panel and an Apple 23" flat panel, I think I know what I'd take.
>>>>>>..
I wouldn't be too sure. I know Sharp makes some LCD screens that look noticibly better than Apple's, and are cheaper to boot. Since Dell rebrands them, I wouldn't be surprised to see one of these panels show up somewhere in its product line.

Processor-driven decision?

[Reziac]

The article points out that Apple is less than thrilled with Motorola's "slow rate of development" of upcoming CPUs. Occurs to me that unless Apple *does* have a credible threat of being able to jump ship to Intel/AMD, Motorola pretty well has Apple over a barrel.

Mac OS on Intel? Fuggedaboudid!

[crovira]

Why would Apple try to push into a confrontation with M$? They get far more press NOT doing it and make M$ look like the trailer-trash it is while winning a battle not fought.

Things come to Windows only once M$ finds ways to enfold and embrace (choke the originality out of,) somebody else's work.

The ONLY persons who think that M$ has a loyal customer base work at M$. These idiots conveniently forget how they themselves got to to the plate in the first place. By being cheaper that IBM.

Now Linux is cheaper than M$.

The handwriting is on the wall and the defections are entire governments and large institutions with multy-K seats.

Meanwhile, Apple is laughing all the way to the bank. They are NOT going to be drawn into as fight with anybody. Fights have winners and losers. Apple is winning by default since its not fighting.

They have much more interesting things happening than Linux can ever aspire to until the Linuxen get away from wasting energy, talent and resources fighting with M$. M$ fight dirty. They use FUD, they use lawyers, payents, collusion, coercion and tactics Tony Soprano can only wish he had the balls to try.

The best way to fight M$ is to embrace and enfold Windows and cut the fiscal legs out from M$ by even a dollar per seat. M$ has NO friends. Not in government, not in the military, not in business. They are utterly vulnerable with respect to security. They are utterly vulnerable with respect to price.

Their dirty tactics have come home to roost and clients are filing class action suits. M$ can't "divide and conquer" and screw their clients one at a time anymore.

Make a Windows work-alike GUI and M$ won't last out the decade in the computing marketplace.

Re:Oh really?

[DavidRavenMoon]

When Microsoft bought Apple's compliance by forcing them to do anything M$ wants as long as Apple wants M$ Word and Internet Explorer.

But that deal was part of an out of court settlement, along with the 150Mill, for MS ripping off Apple patents.

The deal came to an end this month...

Lately Apple has been pushing Mozilla over IE

IA64 Would be another Possibility

[herbierobinson]

IA64 would be another possible target for OS X (assuming Intel ever makes one that's fast enough to matter). It would be much better because it can be run big endian -- That would make application porting (including Carbon apps) pretty much a recompile -- Most developers wouldn't even know.

It's also a great machine for emulating other architectures (huge register set).

dont be silly

[fferreres]

Apple makes money by selling hardware

They don't make any money selling hardware, they make money selling complete systems, the Apple way to computing.

Nobody really cares what hardware is inside the box as long as everything works and there is not uncompatibilities or special configurations like with x86 hardware.

The part that makes the hardware sales is their software and way of making computers usable and stylish.

Re:All the 'cheap hardware' idiots, save your brea

[fferreres]

Who says the Apple hardware doesn't cost more or less than a quality built x86? It may be indeed cheaper, but you'd be required to pay a system price (bundle price) that doesn't reflect hardware costs.

The OS and applications are the expensive, non-commody things here. Locking you to a different hardware than x86 makes sure you can't later switch to Windows if ever need.

Why would they go with x86 over Itanium?

[Rudolf]

Why would Apple want to go with x86, instead of a 64-bit processor, such as the Itanium family? It has (according to Intel) the support of Microsoft, Hewlett-Packard, and Linux. If Apple did a port to this architecture, then they could switch from PPC when the time is right.

Doesn't this make more sense than investing time and effort in the 32-bit x86 platform?

Collect them all!

[phillymjs]

Moderation Totals: Flamebait=1, Insightful=1, Interesting=1, Informative=1, Overrated=1, Underrated=1, Total=6.

Whee! All I need is "Funny" and "Troll", and I will have hit for the cycle. Will two moderators please oblige and mod my parent comment accordingly?

~Philly

marklar defined

[charnov]

marklar: A noun standing in place of any noun you have temporarily forgotten. Synonym of thingy, thingumbob, whatsit. Also may be used deliberately when the meaning is abundantly clear anyway. Derived from its use by space aliens in an episode of South Park
Example: On Marklar, everyone and every thing is referred to as marklar. We come in marklar. Take us to your marklar.

Re:All the 'cheap hardware' idiots, save your brea

[Alien Being]

Apple won't go after the x86 market because MS would never agree to build "MSOffice for MacOSX x86".

In MS marketing parlance, it would be "Where the hell do you think *you're* going?"

Re:x86 port doesn't mean it will run on a Dell

[nitehorse]

Boot floppies?

Apple hasn't shipped a Mac with a floppy drive in years, man.

A boot ISO, maybe. Boot floppies? heh. I'm still laughing. :)

Thanks for that.

Another 'back when'

[Cato]

Back in the days when computing revolved around IBM mainframes, Amdahl was a plug-compatible mainframe manufacturer. There was a saying that just having an Amdahl mug on your desk was worth a significant discount when the IBM salesman came calling.

I see the x86 version of MacOS X as just a bargaining chip - given the huge hassle of converting to x86, and the danger of commoditising Mac hardware, I think this is really a way of getting a better deal out of Motorola and IBM.

Re:Another 'back when'

[Ungrounded Lightning]

Back in the days when computing revolved around IBM mainframes, Amdahl was a plug-compatible mainframe manufacturer.

Still is. I worked for 'em a couple projects, the last just before Fujitsu sucked 'em in.

There was a saying that just having an Amdahl mug on your desk was worth a significant discount when the IBM salesman came calling.

B-)

I see the x86 version of MacOS X as just a bargaining chip - given the huge hassle of converting to x86, and the danger of commoditising Mac hardware, I think this is really a way of getting a better deal out of Motorola and IBM.

Sounds right to me.

A secondary goal might be to keep the rust out of the multi-platform build environment and processor-independence code, in case they ever need to port to some THIRD archetecture. Having your code working solidly cross-platform between a Power PC and something as hysterically asymmetric and other-endian as the Intel archetecture should make it a breeze to port to any other chip - or any future variant of either.

A few corrections

[0x0d0a]

Nobody said anything about emulation. A port is a native compilation, and therefore no performance hit is taken.

This is a quarter-truth. However, you're ignoring a fair number of issues:

* A port would likely be less tweaked for the architecture (run out of registers more likely, cause cache misses, whatever) for some time.

* Apple didn't port all of the MacOS to the PPC for *ages* (actually, I'm not sure the entire OS ever went native). They just ported critical chunks, and emulated less used bits. If you want to avoid emulation, you're looking at a much larger porting task in a short period of the time.

* Apple could port the OS -- but 99% of applications won't be recompiled for the x86. That means a lot of apps need to be emulated.

Furthermore, your assumption that PPC is automagically more powerful than Intel architectures is a clear indication that you are severiously under-informed.

Actually, he's right, though he simplified things a bit. The PPC has far more registers than the x86 architecture. Any emulation would involve extremely expensive swapping of registers very frequently. I'm don't remember what L1 fetch time on the x86 is, but it's at least one cycle. That means that your PPC code is going to run, at best, at half speed a fair bit of the time.

The reason the PPC could emulate the 680x0 so efficiently is because it had so many registers and didn't have to execute many instructions to handle any single 680x0 instruction. Also, the PPC was a faster chip, so running slow 680x0 code still seemed reasonably peppy to the user -- trying to port PPC code to the x86, a *competitive* line, means looking at some serious slowdown issues.

I won't go so far as to call you a newbie, but your bias suggests that you have a ways to go before you become a seasoned professional. Keep on plugging though, and try to be more open-minded. Consider doing research before forming conclusions, for example.

I think that you owe it to the parent poster to do the same yourself.

It's not OSX on a PC that I want ...

[EnglishTim]

... it's Windows on a Mac.

It would be perfect - a dual boot Mac. My reason for not buying a Mac is that when I get to the point of buying a new computer, I generally can't afford to go and buy *two* new computers - and I have enough reasons for needing to have a Windows box that I get a PC. If with my next computer purchase I could buy a Mac and dual boot it with Windows, then that would be great for me - I'd be able to try out the platform without the cutting myself off from the Windows world. And their computers are might purdy, to boot. (Although I'd have to get a mouse with a sensible amount of buttons for it... )

what a crap.

[Otis_INF]

Sorry, but you don't know a lot about the x86 world with their OS-es. When you buy a system from, say, Dell, with OS, say, Windows XP, you get hardware and software that is thouroughly tested to work together well, on par or better than Apple's hw with their software. Where's the el cheapo x86 stuff you're referring to? Nowhere in sight.

Oh, and the Dell box with OS from a different vendor is way cheaper than the Apple solution. True, you're then not owning an Apple product, but not every person on this planet gets a woody by touching an apple keyboard.

Re:what a crap.

[phillymjs]

When you buy a system from, say, Dell, with OS, say, Windows XP, you get hardware and software that is thouroughly tested to work together well, on par or better than Apple's hw with their software. Where's the el cheapo x86 stuff you're referring to? Nowhere in sight.

Here's another brainiac so anxious to take a potshot at me for preferring Apple, that he sees something in my post that wasn't there.

Where did I mention Dell in my post? The "el cheapo x86 stuff" I was referring to, are commodity parts bought from places like CyberGuys, Directron and Access Micro, and used by the buyers to build their own PC. The 'cheap hardware idiots' are the people clamoring for the ability to run Mac OS X on such home-built, no-two-exactly-alike boxes. This is a pipe dream, and always will be. Even Microsoft can't make an OS that will run seamlessly on all of those machines, and they've been throwing money and programmers at the problem for years.

~Philly

Re:OSX on cheap x86 hardware would be great!

[damiam]

Lies, damn lies, and benchmarks. Maybe the Reality Distortion Field has gotten to me and distorted my view completely. But I still think you're wrong.

Anyway, for what it's worth, the last issue of Consumer Reports rated Apple flat panels as the best monitors available to consumers.

Re:Why Mac OS X on PC platform makes no sense (sho

[PythonOrRuby]

I don't know. I think if Apple were to go down this road, it'd be a distinct product alongside PPC machines, targeted at a market that can afford to primarily use Cocoa apps.

I don't think they'd be ordering millions of CPUs, and not at one time. More likely they'd place the CPU on a daughtercard and update it to keep pace with the rest of the x86 world.

Re:Actually, this idea isn't new...

[rnd()]

System 7 had a way better UI than Win3.1, however it also crashed a lot more. Thus, for me it would be a near-tie but I'd probably choose MacOS 7 and learn to live with the crashes.

BTW, Win95 is without a doubt superior to system 7.

On the other hand...

[mblase]

Apple is currently a hardware company. There's no reason they should have to stay one forever.

Think of what a fully-compatible x86 release of OS X could mean for Apple: massive consumer adoption. A new copy of WinXP costs $200, but a new copy of Jaguar costs $70 less. Apple gets to benefit from the "Megahertz Myth" instantly as non-techy computer buyers run their OS on 2.4GHz Pentiums. Consumers who honestly don't care about getting the latest games for their PC can be convinced that all the commercial software they really want is OS X compatible, and get a good package bundle to prove it.

And of course, this only means Apple gets out of the hardware business if they refuse to make Apple computers with x86 processors. They can do that, you know, and people who have come to trust in Apple's reliable hardware and slick design (think the hinged door which you can open while the computer is still running, not to mention the G4's unique external style) will continue to buy Apple's computers, knowing that any Apple software will be designed to work first and best on Apple machines and Apple drives.

At least half the reason Apple hasn't switched to PC hardware is the gazillions of configurations they'd have to support, something even Microsoft has trouble keeping up with. But if OS X gets widespread, or at least wider spread, Apple can start to count on third-party vendors developing the drivers themselves, just as Microsoft does.

Apple will lose money from the hardware, of course. But it's possible that the widespread adoption of a new, more usable Mac OS will be worth it to them.

OS X is NOT based on FreeBSD!

[Builder]

Damn, I'm tired of hearing that OS X is based on FreeBSD. This is just not true. One very small part of OS X is based on a fork of FreeBSD, but that is only one part. Not even the kernel is FreeBSD.

Getting Quartz to run on another platform with the performance that it currently delivers would be a non-trivial task!

For anyone who actually gives a damn about accuracy, check out the architecture diagram at developer.apple.com/macosx for more information.

CISC/RISC

[ehiris]

They ported a x86 OS to Apple hardware and now they are porting it back.

Does this mean that the RISC/CISC battle is over with CISC winning?

Other then that, it would be nice to have an user friendly Unix based modular OS for x86.

Re:CISC/RISC

[Tune]

> Does this mean that the RISC/CISC battle is over with CISC winning? ...Or does it mean that contemporary Operation Systems are becoming more and more architecture independent? (...And this might kill Microsoft, eventually...)

Anyway, hasn't the RISC/CISC-war been fought through hardware marketing rather than software all along?

If I had a beer...

[Orbital Sander]

... for every time someone describes the relation between Apple and either IBM or Motorola as 'strained', I would have no liver.

I'll believe it..

[Suppafly]

I'll believe it when I can download it from IRC.

Hardware

[SkewlD00d]

Apple could get on the ball and make a line of sleek, pimpy PCs, pre-loaded with OS X interchangeable with commodity hardware (remember Macs, LOL), and they could use any chips they want, Transmeta, Amd, Intel, Motorola, MediaGX, etc. That way, they leverage against the chip mfgrs by having multiple vendors.

Apple and Palladium

[RobertFisher]

Even if Apple ever were to switch to making x86-based Macs (and you, the reader, are significantly more likely to bang Anna Kournikova than to see an x86-based Mac for sale), they would put something proprietary in those machines, maybe even in every component of those machines, and change the Mac OS to refuse to boot if it doesn't detect that proprietary something.

The "dongle" which some posters have referred to is already in development -- it is called Palladium. In principle, if MS does indeed open the specifications to Palladium, and if Palladium turns out to be a workably secure platform (two big assumptions, which we will make for the sake of argument), Apple could in principle authorize their x86-based OS only on Apple hardware. Somone going out and buying a cheap generic Intel box would not be able to run the Mac OS on it. This would allow Apple to bundle an x86-based hardware box with their OS, while still maintaining a large profit margin. In addition, although the /. crowd may not like to admit the possibility, Palladium DRM may turn out to be quite successful, and may indeed be the only way to (legally) download media from the major media providers in a few years. Running an x86-Mac OS, Palladium-enabled box, will allow Apple to dodge the DRM bullet (more like a cannon shot) as well.

Perhaps Anna will need to prepare for a big /. gangbang...

Bob

Why *parts* of Mac OS X on x86 makes sense

[Saint Fnordius]

Instead of becoming a full-widget PC architecture, Apple may be playing with strengthening the open source Unix derivatives like *BSD and Linux with partial ports and APIs. Why would they do this?

It's all about getting more developers into the boat. If they write their apps on Mac OS X, then Apple could be promising them a painless port to BSD and Linux. That way, they can also suggest that Windows is less important (more apps for Linux helps weaken Microsoft's biggest lever).

I think Apple would *love* to see Linux/BSD win on the x86 front. Then they can compete on the merits of their widgets, and worry less about fighting Windows software lock-in (and let's be honest: that's what scares a lot of people away from Apple).

Re:All the 'cheap hardware' idiots, save your brea

[sql*kitten]

Personally, I think Apple will,very soon, tell Motorola to go piss up a rope (and I say, it's about time!).

Well, if Apple hadn't screwed Motorola on the whole Mac-clone issue, they'd be a lot friendlier today. What goes around, comes around.

Don't Get Your Hopes Up

[kalidasa]

Just because Apple has an OS X port for x86 hardware, that doesn't mean that it works on more than just their reference hardware. See http://www.opensource.apple.com/projects/darwin/1. 4/x86_install_notes.txt , the install notes for Darwin for x86:

IDE:
Only the PIIX4 IDE controllers have been found to work.
Attached devices must be UDMA/33 compatible or better.

Ethernet:
Intel 8255x 10/100 ethernet controllers are supported.

Video:
You must have a VESA 2.0 compliant video card. Almost all modern graphics cards are VESA 2.0 compliant. However, emulators such as vmware do not have VESA 2.0 compliant emulated video cards.

Successfully tested hardware:
All 440BX motherboards tested have worked with their internal IDE controllers.
IBM ThinkPad A21m (with onboard Intel ethernet)

Known to not be supported:
All AMD and VIA based systems.

I would imagine that any version of OS X for x86 has only been tested on the supported hardware. This does not an x86 product make. Apple is just letting Motorola know that if they have to make the switch, they can.

Re:Oh really?

[DavidRavenMoon]

Irony ... You're American right? :)

Yep. But still, "you're" is a contraction for "you are" not a the possessive form of "you." Not in any language... sorry.

The post you referred to had no misspelled words.