Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OS X on x86 Prototype Boxes
- Thread starter MacRumors
- Start date
- Sort by reaction score
One Reason: Lawyers
One good reason Apple needs to keep the OSX on x86 alive, is that if they don't, and they achieve a more signifigant market share, they will be in danger of the monopoly rules in the US.
As it is now, if you want to run Mac OS, you must buy Apple Hardware. And if you want Apple Hardware to run fully, you must by Mac OS. This is called a monopoly. The only reason Apple hasn't been called on it, it that they have too small of the market share in PCs. Now I realize that some Linux Distros can run Apple Hardware, however they are still only partially functional when it comes to new hardware. Also, Apple does it's level best to defeat this approach.
Now there is talk of an iBrowser? Isn't that what got MS in trouble? What about all the Free Built in iApps, could that not hinder compitition in the software market?
Again, Apple fits the textbook definition of an economic monopoly, only they don't have the market share. If Apple did ever grow, as we would all like it to, they would have to open up some things, or risk a lawsuit.
One good reason Apple needs to keep the OSX on x86 alive, is that if they don't, and they achieve a more signifigant market share, they will be in danger of the monopoly rules in the US.
As it is now, if you want to run Mac OS, you must buy Apple Hardware. And if you want Apple Hardware to run fully, you must by Mac OS. This is called a monopoly. The only reason Apple hasn't been called on it, it that they have too small of the market share in PCs. Now I realize that some Linux Distros can run Apple Hardware, however they are still only partially functional when it comes to new hardware. Also, Apple does it's level best to defeat this approach.
Now there is talk of an iBrowser? Isn't that what got MS in trouble? What about all the Free Built in iApps, could that not hinder compitition in the software market?
Again, Apple fits the textbook definition of an economic monopoly, only they don't have the market share. If Apple did ever grow, as we would all like it to, they would have to open up some things, or risk a lawsuit.
Re: Re: Re: Re: Whatever...
But they still had to buy Apple hardware at some point to run it on. If, (or when) hackers found a way to make an x86 version of OS X run on Wintel hardware Apple might as well fold up their hardware shop.
Mac/RISC fans have been saying "CISC will hit a wall" for *years*. Still hasn't happened. Meanwhile, the G4 was stalled at some pretty pathetic clock rates for quite some time. Maybe this time you're right, and Intel will hit a wall. But I wouldn't count on it, judging by their past performance.
Also, there is no such thing as the P5. The chip you're thinking of is the Itanium, and it's not a CISC chip. Intel might be mucking up the transition to 64 bits pretty badly, and PPC might be able to pick up some market share via a smoother transition plan, but that remains to be seen; The advantages of going to 64 bit are not nearly as great for most users as the advantages of going to 32 bit were, and it may be the case that only users with certain applications (think large datasets) move to 64 bit in any hurry.
No. What you're describing is product bundling. While product bundling might be used as a tactic by someone who has a monopoly in one area to (illegally) acquire a monopoly in another, it does not, by itself, make anyone a monopoly.
To have a monopoly, Apple would need to have either the vast majority of the personal computer hardware market, or the vast majority of the personal computer operating system market. They have only a small fraction of each.
Didn't I say that in my post?
and
Please read the whole post before you make comments like that.
I read the whole post. You wrote:
Apple is already a monopoly, you said, you said, by virtue of the fact that you need Apple hardware to run MacOS. This is simply wrong. The fact that you later said that they might be sued as a monopoly if they gain significant market share doesn't change the fact that you were wrong to characterize them as a monopoly in the present.
Apple is already a monopoly, you said, you said, by virtue of the fact that you need Apple hardware to run MacOS. This is simply wrong. The fact that you later said that they might be sued as a monopoly if they gain significant market share doesn't change the fact that you were wrong to characterize them as a monopoly in the present.
Monopoly
From Dictionary.com
There is only 1 seller of Apple Hardware, and OS. While there are distributers, they all get thier stuff from Apple. Again, you want to run an Apple computer, you must us a Mac OS. You want to run a Mac OS, you must have Apple hardware. With the notable exception of some talented programers that have disected Apple hardware so they can run Linux on it. This is actively discouraged by Apple.
To get back to the topic:
If [and that is a big if] Apple does resort to running on x86 processors, and opens up the market, say taking 25-50%, they might be open to litigation. If they maintain, in the background, a project allowing OS X to run on a non-propriatory Intel/AMD box, they can always release it and aleviat their legal questionability.
From Dictionary.com
There is only 1 seller of Apple Hardware, and OS. While there are distributers, they all get thier stuff from Apple. Again, you want to run an Apple computer, you must us a Mac OS. You want to run a Mac OS, you must have Apple hardware. With the notable exception of some talented programers that have disected Apple hardware so they can run Linux on it. This is actively discouraged by Apple.
To get back to the topic:
If [and that is a big if] Apple does resort to running on x86 processors, and opens up the market, say taking 25-50%, they might be open to litigation. If they maintain, in the background, a project allowing OS X to run on a non-propriatory Intel/AMD box, they can always release it and aleviat their legal questionability.
Re: Altivec, vector processor units??
No, they are not RISC-only. Intel has MMX and SSE and SSE2, and AMD has 3d-Now! and 3D-Now XP or Pro or something like that, all of which are vector processing instruction sets (aka SIMD, for "Single Instruction, Multiple Data").
But, like with processors in general, there are useful/fast SIMD's and there are less useful/less fast SIMDs. If I remember correctly the Intel/AMD SIMD sets all share processor registers (AltiVec has a dedicated set of registers and cache) and have generally higher latencies than AltiVec.
An application ships in machine code (aka binary). This is specific to the specific processor family for which it was compiled, and sometimes to a specific processor within that family. None of the PPC instructions will work on an x86 without a performance-sucking translation layer (which, to be quite frank, would be silly ... P4s already have a hardware translation layer (in-chip) from the old x86 instruction hodge-podge to an internal RISC instruction set (which, of course, is not the same as the PPC instruction set, so you would never be able to use PPC instructions on a P4 core directly, but if Apple were to do this they might be able to talk Intel or AMD into adding a PPC translation unit in hardware ... I know, dreaming ...
) )
Sorry, got off on a tangent within a tangent. In any case, you could do instruction set translation in software, but that's quite expensive. I'd be very surprised if a 3GHz P4 could software-translate+execute PPC instructions faster than a 1GHz G4.
Moving to an x86 or x86-64 (AMD Hammer) architecture would require a long-term shift to using those native instructions. A software instruction translation layer would ease the transition, but you'd see performance skyrocket when you upgrade each application from PPC to native code.
Apple has in place the framework to handle another machine binary within an app package (and to selectively install such a machine's executable in the installer package). But, of course, "legacy" apps might never be recompiled for the x86 architecture.
If it's that easy to switch from one architecture to the next, why do companies spend so much money porting applications over? Because "porting" is not so much dealing with the underlying CPU instructions (your compiler takes care of that in 99% of the code), but dealing with different APIs, libraries, and UI paradigms. This is why a Windows app will not run on Linux without a large reverse-engineered support library system (Wine), and why Linux x86 apps will not run under Windows, even though both OS's use the same underlying processor. It is also why moving an app from Linux x86 to Solaris SPARQ to Linux PPC is little more than a reconfig/recompile, despite the different underlying CPUs.
So, four things should be clear:
1) Will I run Windows apps on an x86 Mac: No. At least not without a third party solution like Wine (Virtual PC would also work, but 90% of its complexity - the software instruction translation - would be thrown in the trash).
2) Will I run OS X apps in Windows: No.
3) Will I run OS X PPC apps on an x86 Mac: Possibly, if Apple puts in a software instruction translation layer for legacy apps.
4) Will the "switch" be incredibly expensive, far more so than what I'll save in hardware: Undoubtably. You'll have to replace all your software, and possibly throw away a bit of no-longer-supported hardware (which will have Windows/x86 drivers and OS9/PPC drivers and OSX/PPC drivers, but not OSX/x86 drivers). If we imagine we might save $250 in hardware costs (which is debatable), we can equally well imagine having to spend at least twice that in software upgrades. Assuming such upgrades are available.
No, they are not RISC-only. Intel has MMX and SSE and SSE2, and AMD has 3d-Now! and 3D-Now XP or Pro or something like that, all of which are vector processing instruction sets (aka SIMD, for "Single Instruction, Multiple Data").
But, like with processors in general, there are useful/fast SIMD's and there are less useful/less fast SIMDs. If I remember correctly the Intel/AMD SIMD sets all share processor registers (AltiVec has a dedicated set of registers and cache) and have generally higher latencies than AltiVec.
Sorry, I'm ranting, but my point it, I always liked the though of a reduced instructionset chip with a vector processor... but if there were such a thing as a 3.0Ghz x86 with a vector processor unit... which would take advatage of all the "Velocity Engine" code in current OS X apps, I'd like one of those... of course I'd have to rip or saw off any "intel inside" or "AMD" insignia on the front of my mac....
Sorry if this is long, but also... the IBM 970 chip says it could run 32 bit apps on an OS modified for 64 bit operation wihtout a problem, call me a dolt, (or tired, it's almost 4am here) but could an OS run regualr cocoa or carbon apps on an OS modifed for an x86 chip?... there logic floating around my head that says it couldn't, but at this hour, I cant grasp it...
Help an iBrotha (refference intended) out, and fill me in
An application ships in machine code (aka binary). This is specific to the specific processor family for which it was compiled, and sometimes to a specific processor within that family. None of the PPC instructions will work on an x86 without a performance-sucking translation layer (which, to be quite frank, would be silly ... P4s already have a hardware translation layer (in-chip) from the old x86 instruction hodge-podge to an internal RISC instruction set (which, of course, is not the same as the PPC instruction set, so you would never be able to use PPC instructions on a P4 core directly, but if Apple were to do this they might be able to talk Intel or AMD into adding a PPC translation unit in hardware ... I know, dreaming ...
) )Sorry, got off on a tangent within a tangent. In any case, you could do instruction set translation in software, but that's quite expensive. I'd be very surprised if a 3GHz P4 could software-translate+execute PPC instructions faster than a 1GHz G4.
Moving to an x86 or x86-64 (AMD Hammer) architecture would require a long-term shift to using those native instructions. A software instruction translation layer would ease the transition, but you'd see performance skyrocket when you upgrade each application from PPC to native code.
Apple has in place the framework to handle another machine binary within an app package (and to selectively install such a machine's executable in the installer package). But, of course, "legacy" apps might never be recompiled for the x86 architecture.
If it's that easy to switch from one architecture to the next, why do companies spend so much money porting applications over? Because "porting" is not so much dealing with the underlying CPU instructions (your compiler takes care of that in 99% of the code), but dealing with different APIs, libraries, and UI paradigms. This is why a Windows app will not run on Linux without a large reverse-engineered support library system (Wine), and why Linux x86 apps will not run under Windows, even though both OS's use the same underlying processor. It is also why moving an app from Linux x86 to Solaris SPARQ to Linux PPC is little more than a reconfig/recompile, despite the different underlying CPUs.
So, four things should be clear:
1) Will I run Windows apps on an x86 Mac: No. At least not without a third party solution like Wine (Virtual PC would also work, but 90% of its complexity - the software instruction translation - would be thrown in the trash).
2) Will I run OS X apps in Windows: No.
3) Will I run OS X PPC apps on an x86 Mac: Possibly, if Apple puts in a software instruction translation layer for legacy apps.
4) Will the "switch" be incredibly expensive, far more so than what I'll save in hardware: Undoubtably. You'll have to replace all your software, and possibly throw away a bit of no-longer-supported hardware (which will have Windows/x86 drivers and OS9/PPC drivers and OSX/PPC drivers, but not OSX/x86 drivers). If we imagine we might save $250 in hardware costs (which is debatable), we can equally well imagine having to spend at least twice that in software upgrades. Assuming such upgrades are available.
Or, he could be thinking of Banias, a mobile chip that runs in the 1.5GHz range.
There is, however, a real P5 in development, and it does have a starting clock rate reportedly slightly lower (like 2.5GHz when P4 was at 2.8) than the high-end P4, although that may change by release time. Per cycle, it is more efficient than the P4. However, Intel to my knowledge has never released a new x86 flagship that ran at a lower clock speed than the previous iteration. I may be wrong in the 486/DX2 - to - Pentium transition (the DX2's clocked up to 100MHz and the Pentium started at 60 ... not sure of the order of release though). But that's reach awayback in the Intel memory. Doing that with the P5 will cause a bit of marketing counter-spin if it indeed does happen.
As for the Banias: It is not the flagship. It can be slower. Why is it slower? It is a mobile chip, not a desktop chip.
As for Itanium: It is a server-class chip, not a desktop chip. It uses a completely different architecture and instruction set. It does more per cycle than the P4 could dream of doing (3x as much, in fact). It competes quite well in its marketplace, which buyers have both the training and the time to understand that GHz is not a valid measure of cross-architecture performance.
Problem: Deerfield, which is the Itanium-for-Desktop effort at Intel. Release date: Q4, 2003 (same as 970!). Intel might be able to churn up the clock rate on this 64-bit processor, but it's in for a whole lot of re-educating to get people to throw away everything they have to buy their 64-bit dreamship at home. Of course, the plan is that Itanium has become well established by then and the marketing, as always, is "Server power. On your desktop." But that assumes Itanium does better than it has, and that consumers really care enough about 64-bit computing to justify a wholesale switchover.
Re: Re: Altivec, vector processor units??
Remember the "Yellow Box" libraries?
Before NeXT was bought by Apple, their OPENSTEP for Windows product had Win32 compiled libraries that provided all of what is the ancestor of todays "Cocoa" frameworks, including the Objective C runtime environment and a Display Postscript engine, all running on top of Windows.
I'd venture to bet that some group, deep in the bowels of Apple has kept those "Yellow Box for Win32" libraries up to date and, probably, has made a DisplayPDF engine for Win32 as well. Just in case...
Actually it would be relatively trivial for OS X Cocoa apps to run on Windows.
Remember the "Yellow Box" libraries?
Before NeXT was bought by Apple, their OPENSTEP for Windows product had Win32 compiled libraries that provided all of what is the ancestor of todays "Cocoa" frameworks, including the Objective C runtime environment and a Display Postscript engine, all running on top of Windows.
I'd venture to bet that some group, deep in the bowels of Apple has kept those "Yellow Box for Win32" libraries up to date and, probably, has made a DisplayPDF engine for Win32 as well. Just in case...
Re: One Reason: Lawyers
You are wrong. A monopoly by definition is having 100% (or virtually 100%) market share. Apple is not a monopoly and is not even close. It follows then that you're saying is that Apple is a monopoly but has not been called on it because it is not a monopoly. In which case you are very confused. Find a different textbook, because the one you're pulling your facts out of is dead wrong.
Re: Monopoly
By which definition Sony has a monopoly of Sony Diskmen and Ford has a monopoly on Tauruses. And, yes, the laser pickup of a Sony Diskman might not work in a Philips player, and the gearshift of the Taurus probably won't shift the gears of a Celica.
The marketplace is not and never can be defined as "category of dvice + manufacturer". Every manufacturer would then have a monopoly, and the term is meaningless.
On the other hand, yes, things like Apple bundling Sherlock which looks amazingly like Watson would get them in trouble if they owned more of the marketplace. But they don't.
OS X for x86 would not help in this situation, just like Windows for Alpha and IE for Solaris did not help Microsoft.
By which definition Sony has a monopoly of Sony Diskmen and Ford has a monopoly on Tauruses. And, yes, the laser pickup of a Sony Diskman might not work in a Philips player, and the gearshift of the Taurus probably won't shift the gears of a Celica.
The marketplace is not and never can be defined as "category of dvice + manufacturer". Every manufacturer would then have a monopoly, and the term is meaningless.
On the other hand, yes, things like Apple bundling Sherlock which looks amazingly like Watson would get them in trouble if they owned more of the marketplace. But they don't.
OS X for x86 would not help in this situation, just like Windows for Alpha and IE for Solaris did not help Microsoft.
Re: Monopoly
So Pizza Hut is a monopoly because you can only get Pizza Hut pizza from Pizza Hut? And Chevrolet is a monopoly because you can only buy Chevrolet cars from Chevrolet? You're an idiot. There is NO legal questionability here whatsoever.
So Pizza Hut is a monopoly because you can only get Pizza Hut pizza from Pizza Hut? And Chevrolet is a monopoly because you can only buy Chevrolet cars from Chevrolet? You're an idiot. There is NO legal questionability here whatsoever.
Re: Re: Monopoly
Actually, OS X for x86, sold at retail, might put Apple more in legal trouble if they continued selling their PPC-based hardware with OS X locked to it.
Right now, Apple claims that the Mac hardware and the OS X operating system are a single salable unit. If one of the two is available separately, then the most convincing defense gets thrown out.
Actually, OS X for x86, sold at retail, might put Apple more in legal trouble if they continued selling their PPC-based hardware with OS X locked to it.
Right now, Apple claims that the Mac hardware and the OS X operating system are a single salable unit. If one of the two is available separately, then the most convincing defense gets thrown out.
Re: Re: Re: Apple and the attack of the Mac clones!!!
Cheap shot? Those applications are the reason people bought macs in 1997 (and largely still today).
I think that the problem is that Be had no idea what their market was supposed to be.
I'm pretty sure NetPositive was not available in 1997.
I'm 100% certain that most of those were not available in 1997.
Indeed it is.
You keep saying that. It keeps being stupid and unsupported. Please explain to me how Motorola (a multi-billion dollar company), APC (ditto) and UMAX (ditto) were going to "get rich quick" by selling Mac clones.
Re: Re: One Reason: Lawyers
Otherwise McDonald's can be considered as having a monopoly of Big Macs, VW a monopoly on diesel cars, IBM for their PPC-based AIX workstations, and Ford would have a monopoly on Ford vehicles, plus all the other examples already given and more.
Apple does not have a monopoly because you have to buy from Apple to get an Apple or even run Apple software.
You have to buy and Apple to run Apple software because of protections granted to companies under US law, that protect companies from cheap knock-offs that would erode their image in the marketplace.
Apple has not had a big enough market share for people to really care about making clones that get around patent protections like they did in the IBM PC case - plus it's a little different since IBM didn't own the operating system in the first place, which allowed MS to modify it to run on clones.
Somehow I don't see Apple doing that if they don't have a contract with the cloner.
I agree, monopolies are based on the market share of the "entire" market - not a small segment of it.
Otherwise McDonald's can be considered as having a monopoly of Big Macs, VW a monopoly on diesel cars, IBM for their PPC-based AIX workstations, and Ford would have a monopoly on Ford vehicles, plus all the other examples already given and more.
Apple does not have a monopoly because you have to buy from Apple to get an Apple or even run Apple software.
You have to buy and Apple to run Apple software because of protections granted to companies under US law, that protect companies from cheap knock-offs that would erode their image in the marketplace.
Apple has not had a big enough market share for people to really care about making clones that get around patent protections like they did in the IBM PC case - plus it's a little different since IBM didn't own the operating system in the first place, which allowed MS to modify it to run on clones.
Somehow I don't see Apple doing that if they don't have a contract with the cloner.
YOU GUYS!
Just STOP already!
First off, this is AAAALLLLLLL speculation!
Besides, even if ANY of this is true, it isnt because Apple is going to make OSX for PC's, but instead reconfigure their hardware to work with a x86 processor.
It will still be a Mac, just like it is now, but it will just have an "AMD" stamp on the processor instead of "Motorola."
Just STOP already!
First off, this is AAAALLLLLLL speculation!
Besides, even if ANY of this is true, it isnt because Apple is going to make OSX for PC's, but instead reconfigure their hardware to work with a x86 processor.
It will still be a Mac, just like it is now, but it will just have an "AMD" stamp on the processor instead of "Motorola."
Oh, great, now you're quoting dictionary definitions. The only part of the quoted definition that is relevant is the first one; The second one is so vague and broad that you could use it to characterize just about any company as a monopoly, and has nothing to do with whether or not a company fits the legal definition of a monopoly, anyways. And I'm pretty sure that when you called Apple a monopoly, you didn't mean the board game.
So let's look at that first definition: "a market in which there are many buyers but only one seller". Is there a market in which Apple is the only seller? No. Because the primary market in which Apple competes is not "Computer hardware that runs MacOS", or "Operating systems which run on Macintosh hardware", but rather: "Personal computer systems". There are plenty of providers of such things besides Apple. Saying that Apple is a monopoly because they're the only company that competes in the "hardware that runs MacOS" market is about like saying that Ford is a monopoly because they are the only company that competes in the "Ford Mustang" market.
You are, honestly, not getting any more comprehensible here.
But okay, I think what you're trying to say here is that Apple isn't in the Audio/Visual market as a whole, they're only in the part of the AV market that uses Macs. That, friend, is what is called a tautology. Look it up.
I don't know how I can make it any clearer: I work at a video production company. (http://www.feedroom.com if you feel like taking a look. I do not speak for them and what I say here is on my own time and my own dollar.) I have many friends working at other AV production/editing/compositing companies. Apple is a force in this industry, in the same way that Avid, Microsoft, NewTek etc are.
You should really stop trying to talk authoritatively about an industry you apparently know little or nothing about.
And from this you gather that Apple is not pursuing the A/V market? Kid, when you spend millions of dollars to buy a company like Nothing Real (makers of Shake and Tremor), it's not because you're hoping not to make any return on the investment.
"Trying to keep ahold of your existing share and pursuing new customers" is the definition of courting a market.
Oh christ, whatever. I'll remember how innovative Apple is failing to be every time one of our editors fires up Final Cut Pro, okay?
Actually, Pixar uses both of the above, plus Windows, SGI and Sun hardware. (Who do you think the Xserve was specced out for, anyway?)
Intel P4 3Ghz kicks motorola's ass
Check out this recent benchmark test:
http://www.digitalvideoediting.com/2002/11_nov/reviews/cw_macvspciii.htm
Motorola is getting smoked, and Intel is only using a single processor. Apple may be forced to use an Intel Processor to stay competetive. For now people buy mac's because they are mac's, independent of speed claims. But if it takes twice as long to do something on a mac for twice the price, they are going to lost all their business no matter how pretty or easy to use their computers are. Apple is a smarter company than this. If motorola doesn't develop a serious G4++ / G5 within the first half of 2003, expect to see that "Intel Inside" sticker on the blue handle of your favorite mac.
Check out this recent benchmark test:
http://www.digitalvideoediting.com/2002/11_nov/reviews/cw_macvspciii.htm
Motorola is getting smoked, and Intel is only using a single processor. Apple may be forced to use an Intel Processor to stay competetive. For now people buy mac's because they are mac's, independent of speed claims. But if it takes twice as long to do something on a mac for twice the price, they are going to lost all their business no matter how pretty or easy to use their computers are. Apple is a smarter company than this. If motorola doesn't develop a serious G4++ / G5 within the first half of 2003, expect to see that "Intel Inside" sticker on the blue handle of your favorite mac.
Actually, it happened years ago, circa the 486.
What nobody in the RISC camp expected, however, was that Intel (and later NexGen/AMD and Via) would be able to bolt the x86's CISC instruction set on top of a RISC-ish core and a translation layer, and make it go faster than most pure-RISC chips. Ooops.
Hyperthreading
Not to interject intelligent discussion into an otherwise fun conversation, but I was reading about Intel's new 3GHz chip today. It seems *perfectly* suited to MacOS X due to its "hyperthreading" technology. Basically, it improves performance and avoids pipeline stalls by running multiple processes simultaneously, using multiple register files and program counters. If you consider that no instruction from one process depends on the outcome of one from another process, you've cut the pipeline stalls significantly.
What does this mean? It means that the new Intel x86 chip can execute two segments of code at the same time faster than it could execute one, followed by the other. Up until now, all mass market chips still held on to the concept of running one program at a time, and switching between them really fast. Although I've seen papers on it a decade ago, this is the first time anyone's actually released a core that significantly improves performance specifically for the case of multiple tasks running concurrently. It's kind of halfway between a single processor and a multi processor system.
Why would this be great for MacOS X? MOSX's kernelized design offloads a lot of work onto user-level tasks. While it is not a true "microkernel", running quite a bit of code in the kernel itself, it still depends on good performance from a handful of tasks that work together in order to accomplish its operating system duties. Moreso than other operating systems, it will be running many tasks at the same time and would benefit from any processor that can speed up this behavior.
My suspicion? An Apple box using this chip would leave all current Apple hardware in the dust. I would be surprised if, come WWDC in May, Apple didn't offer some sort of cross-compiler and courses on developing for an x86 version of MacOS X Server. I'm still skeptical of MacOS X running on x86, but MOSX Server seems natural, almost obvious.
Not to interject intelligent discussion into an otherwise fun conversation, but I was reading about Intel's new 3GHz chip today. It seems *perfectly* suited to MacOS X due to its "hyperthreading" technology. Basically, it improves performance and avoids pipeline stalls by running multiple processes simultaneously, using multiple register files and program counters. If you consider that no instruction from one process depends on the outcome of one from another process, you've cut the pipeline stalls significantly.
What does this mean? It means that the new Intel x86 chip can execute two segments of code at the same time faster than it could execute one, followed by the other. Up until now, all mass market chips still held on to the concept of running one program at a time, and switching between them really fast. Although I've seen papers on it a decade ago, this is the first time anyone's actually released a core that significantly improves performance specifically for the case of multiple tasks running concurrently. It's kind of halfway between a single processor and a multi processor system.
Why would this be great for MacOS X? MOSX's kernelized design offloads a lot of work onto user-level tasks. While it is not a true "microkernel", running quite a bit of code in the kernel itself, it still depends on good performance from a handful of tasks that work together in order to accomplish its operating system duties. Moreso than other operating systems, it will be running many tasks at the same time and would benefit from any processor that can speed up this behavior.
My suspicion? An Apple box using this chip would leave all current Apple hardware in the dust. I would be surprised if, come WWDC in May, Apple didn't offer some sort of cross-compiler and courses on developing for an x86 version of MacOS X Server. I'm still skeptical of MacOS X running on x86, but MOSX Server seems natural, almost obvious.
>> faster bus speeds, quicker RAM, and the entire host of crappy PC peripherals out there.<<
isn't the mac, especially the new G4s, moving towards faster bus speeds, quicker RAM, and utilizing a host of "crappy PC peripherals out there" (ie. ATA100/133 drives, DDR RAM, etc.) already?
it's not the crappy PC or Mac hardware (granted a bad piece of RAM will cause your system to not boot up at all), that causes system crashes but lousy, poorly written drivers or extensions. a system's stabilty doesn't just rely on a solid OS and solid hardware but solid drivers and extensions support as well.
isn't the mac, especially the new G4s, moving towards faster bus speeds, quicker RAM, and utilizing a host of "crappy PC peripherals out there" (ie. ATA100/133 drives, DDR RAM, etc.) already?
it's not the crappy PC or Mac hardware (granted a bad piece of RAM will cause your system to not boot up at all), that causes system crashes but lousy, poorly written drivers or extensions. a system's stabilty doesn't just rely on a solid OS and solid hardware but solid drivers and extensions support as well.