Well as a software guy that specialised in OS X for a long time I know that this is not much of an issue...In other words there is no need for developers to really test anything - it should just work. All bugs are Apple bugs - the developer has to be aware of nothing. Apple will probably issue testing machines to certain developers - but not to iron out developer bugs caused by developers - but bugs that Apple has in it's frameworks, mostly.
Then apparently you've worked with a different Apple computer then the rest of us. As a developer of software as well, I know one thing. When you rely on other people's software, you expect it to 'just work'. However, you know better than that. It won't 'just work'. They have bugs. Sometimes lots of them. Which leads to the next thing we all should know: Just because there are bugs doesn't mean they're going to get fixed, or get fixed in a timely fashion.
You try to use objects and frameworks and all that fun stuff, but if some method in the object is buggy, you can't just call the developer, say "Hey, method XXX doesn't work right, fix it!" and tomorrow they'll have a fix. And even if they did, this leads to the next thing you should know: Not all users update their software to the latest version. So you have issues where it'll work with some people, but not others (always a pain if you're always up-to-date, trying to figure out what was broken two versions ago).
But then all of this revolves around the most important thing: If you're software fails do to a bug in someone else's software (say OS X for Intel), the customer doesn't care. They think its your software that's buggy, and they expect YOU to fix it. They don't want to hear how its Apple's fault. They just want it to work. Which means you need to spend time working around the problem.
Now, if you're saying that you won't spend time testing your software on Intel as well as PPC, that shows me that you don't understand programming, don't understand the testing philosophy, and don't understand that its your job to make sure your software works, not Apples. And I'd be advising any of your customers to look for a new vendor, as you apparently don't understand what being a good programmer is about.
OS X has a compatibility layer. This is what isolates the high level code of the programs from the hardware underneath. If a developer follows instructions (even Apple doesn't always do that!) then they only write to the OS. In the old days it was common to write directly to the hardware. When that changed, the software wouldn't work. That's what's behind the idea of software portability.
Mind you, it would still be a bear. I'm not for the idea. But it could be done.
That "compatibilty" is there, but you are obstucating the issue a bit by implying that the layer does some kind of conversion at runtime. Not so. People who write to the higher level ( all developers) will be abstracted from the hardware level, yes, but that does not imply some type of runtime emulation. On an intel machine the entire OS is compiled down to intel byte code, and the applications that run in that space are intel byte coded.
Big endianess is an issue only if the developer bypasses normal read/write API to write or read in data. I imagine that is negligible in the real world.
As for the non-technical issues. I see this as a total benefit.
1) The OS will not be licenced so no talk, please, about clones destroying OS X's marketshare. The nerds who install on Dell's this will be a tiny percentage.
2) OS X will have the top megahertz chips. Nobody cares about the technical ideologies behind the chips, but the speed.
3) Apple can port Cocoa to windows ( and thus the iLife suite) and allow dual booting of Mac based machines into windows. This will facilitate switching, and just people who want to buy an Apple branded machine. i know boatloads of people who would buy a mac if it could also run windows for a time. This is the only way that Apple could ever hope to get to 10% or more of the market again.
Then it is up to Apple to have a much better operating system than the Windows side , so that people who buy the mac for the Form Factor, for the brand etc. will switch to OS X rather than stay with Windows. For those of you who are Mac fans to deny this possibility, is a bit rich, no?
I think Apple is confident enough with OS X - and more importantly - with it's stellar trajectory to assume it can compete with windows on the same machine. they should however, start to reduce the cost of both the .Mac services and the annual(ish) update costs.
Then apparently you've worked with a different Apple computer then the rest of us. As a developer of software as well, I know one thing. When you rely on other people's software, you expect it to 'just work'. However, you know better than that. It won't 'just work'. They have bugs. Sometimes lots of them. Which leads to the next thing we all should know: Just because there are bugs doesn't mean they're going to get fixed, or get fixed in a timely fashion.
You try to use objects and frameworks and all that fun stuff, but if some method in the object is buggy, you can't just call the developer, say "Hey, method XXX doesn't work right, fix it!" and tomorrow they'll have a fix. And even if they did, this leads to the next thing you should know: Not all users update their software to the latest version. So you have issues where it'll work with some people, but not others (always a pain if you're always up-to-date, trying to figure out what was broken two versions ago).
all of this is true but also true of Apple's normal update cycle. OS X.4 introduced bugs as you mention. So will the update to Intel. Any intel bugs could be fixed in a " timely fashion " , or not, as with any other bugs introduced in an update.
You argument that Apple releases with too many bugs is taken, but not really relevant to this argument. The process of moving to Intel will be the same for the developer as if the OS changed underneath his application. Either can cause developer unreleated bugs as we are so much more dependent on the OS for frameworks and other services. But that is not reason enough to not do this, or else it would be reason enough to not have serious updates on the Mac.
I think the technical issues have been explained from my point of view.
The ideology behind this is more of an issue I think. I personally agree with it, but admit it may be a risk - and possible be seen as a capitulation of sorts.
It will be interesting to see market reaction tomorrow if this pans out.
Yes, a recompile will work. That's never been questioned here. But a recompile will result in some very bloated code. Code that will run slowly, because platform crossed re-compiles are inefficient. Even with a compatibility layer.
No, you don't understand the way OS X is designed. Its not one big app where all the compiled code for PPC and Intel are together. You can have separate sets of binaries inside your Application package, one for Intel and one for PPC (so you might say you compile it twice, with different platform flags). When you run the program, the OS picks the appropriate binary(s). There's no bloat, as the code doesn't require bloating, and the compiler should be optimizing it for each platform when its compiled.
Basically, there is no compatibility layer.
Oh, and even if there were, it shouldn't cause humongous slowdowns either, as you would be compiling to an intermediate code language that would be interpreted/compiled at run-time by the appropriate compatibility layer for the platform. (Of course, if the layer sucks, so does the performance, but that's a different story).
It will be interesting to see market reaction tomorrow if this pans out. [/B]
I'm no stock market analyst but wouldn't an announcement lik this destroy Apples stock? I mean think of the impact an announcement like this will have especially if all Jobs has is a 'gameplan' albeit an excellent one. Until he could produce viable results (sounds like at least a year away) Apple's worth would just nosedive to 0. I mean the whole basis for Apple and OSX is it's a totally different hardware/software alternative to Windows/Intel.
I.E. just the other day APPL took a hit just because it was reported Apple has a backstock of iPods. It would be great to be a fly on the wall in the shareholder board meeting if this all turns out to be true. Steveie-poo wuld have to be the greatest Closer of all time to pull support for something like this.
You're assuming it's true. We don't know that yet.
Yes, I'm assuming it's true - the evidence is too strong IMO, and anyway, I'll be pleasantly surprised if I'm wrong the "something amazing from IBM" or the "Intel fabbing PPC" theories are right, where as the people in those camps will be really disappointed...
all of this is true but also true of Apple's normal update cycle. OS X.4 introduced bugs as you mention. So will the update to Intel. Any intel bugs could be fixed in a " timely fashion " , or not, as with any other bugs introduced in an update.
You argument that Apple releases with too many bugs is taken, but not really relevant to this argument. The process of moving to Intel will be the same for the developer as if the OS changed underneath his application. Either can cause developer unreleated bugs as we are so much more dependent on the OS for frameworks and other services. But that is not reason enough to not do this, or else it would be reason enough to not have serious updates on the Mac.
I think the technical issues have been explained from my point of view.
The ideology behind this is more of an issue I think. I personally agree with it, but admit it may be a risk - and possible be seen as a capitulation of sorts.
It will be interesting to see market reaction tomorrow if this pans out.
I wasn't arguing this as a reason Apple shouldn't do this. I was just arguing that this has to be taken into consideration by the developer (the one who I was replying to stated 'no further testing is needed', which I just find ludicrous). I also don't feel (or if I did it was unintentional) that I was singling Apple out on bugs in its OS. They are there, as they would be for an Intel version. But I was just stating any software (OS or stand-alone app) by any vendor (MS, Apple, Adobe, etc) has bugs, and if you plan on having your software work on/with other's software, you can't make the mistake that those problems that aren't your bugs can be just dismissed.
Oh, and keep in mind that besides just the frameworks and OS being issues, processors themselves (both PPC and Intel) are known to contain bugs that must be worked around. These are almost always handled at the compiler/OS level, but its one more thing that Apple has to realize, coded for, and that has to be tested against.
Finally, this is just off the top of my head, speaking of processors. Aren't the floating point (and perhaps integer, but I don't think so) processors and registers different in an Intel chip then on the PPC? I'm speaking mostly on a bit-size and computation front. For if they are different, doesn't that lead to the possibiltiy of different results on different computers? Not sure if its the kind of thing that truly makes a difference, as I do little Floating Point code, just wondering.
That "compatibilty" is there, but you are obstucating the issue a bit by implying that the layer does some kind of conversion at runtime. Not so. People who write to the higher level ( all developers) will be abstracted from the hardware level, yes, but that does not imply some type of runtime emulation. On an intel machine the entire OS is compiled down to intel byte code, and the applications that run in that space are intel byte coded.
Big endianess is an issue only if the developer bypasses normal read/write API to write or read in data. I imagine that is negligible in the real world.
As for the non-technical issues. I see this as a total benefit.
1) The OS will not be licenced so no talk, please, about clones destroying OS X's marketshare. The nerds who install on Dell's this will be a tiny percentage.
2) OS X will have the top megahertz chips. Nobody cares about the technical ideologies behind the chips, but the speed.
3) Apple can port Cocoa to windows ( and thus the iLife suite) and allow dual booting of Mac based machines into windows. This will facilitate switching, and just people who want to buy an Apple branded machine. i know boatloads of people who would buy a mac if it could also run windows for a time. This is the only way that Apple could ever hope to get to 10% or more of the market again.
Then it is up to Apple to have a much better operating system than the Windows side , so that people who buy the mac for the Form Factor, for the brand etc. will switch to OS X rather than stay with Windows. For those of you who are Mac fans to deny this possibility, is a bit rich, no?
I think Apple is confident enough with OS X - and more importantly - with it's stellar trajectory to assume it can compete with windows on the same machine. they should however, start to reduce the cost of both the .Mac services and the annual(ish) update costs.
You're right, I used the wrong term (I said I haven't programmed for a while)
I should have abstraction as that was what I was describing. I was never implying that there was any conversion being done. As I said, the OS shields the programs from the hardware. It's not 100% but it's enough that when a chip is redesigned, the software will still work, if it were properly written.
I wasn't meaning to say that this was true from PPC to x86. If you had read my other posts you would have seen that. I was referring to (and, yes, I should have been more specific) the G3-G4-G5 shifts.
Yes, I'm assuming it's true - the evidence is too strong IMO, and anyway, I'll be pleasantly surprised if I'm wrong the "something amazing from IBM" or the "Intel fabbing PPC" theories are right, where as the people in those camps will be really disappointed...
What evidence? Randomly leaked statements by "industry execs"? Sorry for being a true skeptic about anything but I don't just buy fly-by-night theories because Jim-Bob the IT exec at such and such "industry" company heard something thru a chain-letter email that supposedly came straight from Steve Jobs on the HUSH HUSH and FOR YOUR EYES ONLY. Like I said before there is such a thing as shoddy reporting.
I'm also not denying anything. I see both sides of the argument but I also look at the big picture and the skeptic part of me is winning the argument.
No, you don't understand the way OS X is designed. Its not one big app where all the compiled code for PPC and Intel are together. You can have separate sets of binaries inside your Application package, one for Intel and one for PPC (so you might say you compile it twice, with different platform flags). When you run the program, the OS picks the appropriate binary(s). There's no bloat, as the code doesn't require bloating, and the compiler should be optimizing it for each platform when its compiled.
Basically, there is no compatibility layer.
Oh, and even if there were, it shouldn't cause humongous slowdowns either, as you would be compiling to an intermediate code language that would be interpreted/compiled at run-time by the appropriate compatibility layer for the platform. (Of course, if the layer sucks, so does the performance, but that's a different story).
You don't call that bloat? I think most would.
Compatibility; read my reply to "asdasd".
I'm not saying "humongous" slowdowns. But if it is interpreted/compiled at runtime, that would be bad. That was the big problem Apple had with the 68xx to PPC conversion, interpreted code. I think it was Connectix that stored the code and fixed most of the performance problems You might not remember, or weren't old enough at the time, but 68xx programs ran at about half the speed they ran on the 68xx.
Well, I just reread Apple's Unix tech briefing paper. They don't stop mentioning about how optimized for the G5 it is. They also make a point of telling us how optimized for the Velocity Engine it is.
It would be a big step. It really seems to depend on the VE in any performance related area.
Comments
Originally posted by 1984
I'll bet Virtual PC would get quite a speed boost.
I figured that was the whole point of switching to x86
Originally posted by asdasd
Well as a software guy that specialised in OS X for a long time I know that this is not much of an issue...In other words there is no need for developers to really test anything - it should just work. All bugs are Apple bugs - the developer has to be aware of nothing. Apple will probably issue testing machines to certain developers - but not to iron out developer bugs caused by developers - but bugs that Apple has in it's frameworks, mostly.
Then apparently you've worked with a different Apple computer then the rest of us. As a developer of software as well, I know one thing. When you rely on other people's software, you expect it to 'just work'. However, you know better than that. It won't 'just work'. They have bugs. Sometimes lots of them. Which leads to the next thing we all should know: Just because there are bugs doesn't mean they're going to get fixed, or get fixed in a timely fashion.
You try to use objects and frameworks and all that fun stuff, but if some method in the object is buggy, you can't just call the developer, say "Hey, method XXX doesn't work right, fix it!" and tomorrow they'll have a fix. And even if they did, this leads to the next thing you should know: Not all users update their software to the latest version. So you have issues where it'll work with some people, but not others (always a pain if you're always up-to-date, trying to figure out what was broken two versions ago).
But then all of this revolves around the most important thing: If you're software fails do to a bug in someone else's software (say OS X for Intel), the customer doesn't care. They think its your software that's buggy, and they expect YOU to fix it. They don't want to hear how its Apple's fault. They just want it to work. Which means you need to spend time working around the problem.
Now, if you're saying that you won't spend time testing your software on Intel as well as PPC, that shows me that you don't understand programming, don't understand the testing philosophy, and don't understand that its your job to make sure your software works, not Apples. And I'd be advising any of your customers to look for a new vendor, as you apparently don't understand what being a good programmer is about.
OS X has a compatibility layer. This is what isolates the high level code of the programs from the hardware underneath. If a developer follows instructions (even Apple doesn't always do that!) then they only write to the OS. In the old days it was common to write directly to the hardware. When that changed, the software wouldn't work. That's what's behind the idea of software portability.
Mind you, it would still be a bear. I'm not for the idea. But it could be done.
That "compatibilty" is there, but you are obstucating the issue a bit by implying that the layer does some kind of conversion at runtime. Not so. People who write to the higher level ( all developers) will be abstracted from the hardware level, yes, but that does not imply some type of runtime emulation. On an intel machine the entire OS is compiled down to intel byte code, and the applications that run in that space are intel byte coded.
Big endianess is an issue only if the developer bypasses normal read/write API to write or read in data. I imagine that is negligible in the real world.
As for the non-technical issues. I see this as a total benefit.
1) The OS will not be licenced so no talk, please, about clones destroying OS X's marketshare. The nerds who install on Dell's this will be a tiny percentage.
2) OS X will have the top megahertz chips. Nobody cares about the technical ideologies behind the chips, but the speed.
3) Apple can port Cocoa to windows ( and thus the iLife suite) and allow dual booting of Mac based machines into windows. This will facilitate switching, and just people who want to buy an Apple branded machine. i know boatloads of people who would buy a mac if it could also run windows for a time. This is the only way that Apple could ever hope to get to 10% or more of the market again.
Then it is up to Apple to have a much better operating system than the Windows side , so that people who buy the mac for the Form Factor, for the brand etc. will switch to OS X rather than stay with Windows. For those of you who are Mac fans to deny this possibility, is a bit rich, no?
I think Apple is confident enough with OS X - and more importantly - with it's stellar trajectory to assume it can compete with windows on the same machine. they should however, start to reduce the cost of both the .Mac services and the annual(ish) update costs.
Then apparently you've worked with a different Apple computer then the rest of us. As a developer of software as well, I know one thing. When you rely on other people's software, you expect it to 'just work'. However, you know better than that. It won't 'just work'. They have bugs. Sometimes lots of them. Which leads to the next thing we all should know: Just because there are bugs doesn't mean they're going to get fixed, or get fixed in a timely fashion.
You try to use objects and frameworks and all that fun stuff, but if some method in the object is buggy, you can't just call the developer, say "Hey, method XXX doesn't work right, fix it!" and tomorrow they'll have a fix. And even if they did, this leads to the next thing you should know: Not all users update their software to the latest version. So you have issues where it'll work with some people, but not others (always a pain if you're always up-to-date, trying to figure out what was broken two versions ago).
all of this is true but also true of Apple's normal update cycle. OS X.4 introduced bugs as you mention. So will the update to Intel. Any intel bugs could be fixed in a " timely fashion " , or not, as with any other bugs introduced in an update.
You argument that Apple releases with too many bugs is taken, but not really relevant to this argument. The process of moving to Intel will be the same for the developer as if the OS changed underneath his application. Either can cause developer unreleated bugs as we are so much more dependent on the OS for frameworks and other services. But that is not reason enough to not do this, or else it would be reason enough to not have serious updates on the Mac.
I think the technical issues have been explained from my point of view.
The ideology behind this is more of an issue I think. I personally agree with it, but admit it may be a risk - and possible be seen as a capitulation of sorts.
It will be interesting to see market reaction tomorrow if this pans out.
Originally posted by melgross
Yes, a recompile will work. That's never been questioned here. But a recompile will result in some very bloated code. Code that will run slowly, because platform crossed re-compiles are inefficient. Even with a compatibility layer.
No, you don't understand the way OS X is designed. Its not one big app where all the compiled code for PPC and Intel are together. You can have separate sets of binaries inside your Application package, one for Intel and one for PPC (so you might say you compile it twice, with different platform flags). When you run the program, the OS picks the appropriate binary(s). There's no bloat, as the code doesn't require bloating, and the compiler should be optimizing it for each platform when its compiled.
Basically, there is no compatibility layer.
Oh, and even if there were, it shouldn't cause humongous slowdowns either, as you would be compiling to an intermediate code language that would be interpreted/compiled at run-time by the appropriate compatibility layer for the platform. (Of course, if the layer sucks, so does the performance, but that's a different story).
It will be interesting to see market reaction tomorrow if this pans out. [/B]
I'm no stock market analyst but wouldn't an announcement lik this destroy Apples stock? I mean think of the impact an announcement like this will have especially if all Jobs has is a 'gameplan' albeit an excellent one. Until he could produce viable results (sounds like at least a year away) Apple's worth would just nosedive to 0. I mean the whole basis for Apple and OSX is it's a totally different hardware/software alternative to Windows/Intel.
I.E. just the other day APPL took a hit just because it was reported Apple has a backstock of iPods. It would be great to be a fly on the wall in the shareholder board meeting if this all turns out to be true. Steveie-poo wuld have to be the greatest Closer of all time to pull support for something like this.
Originally posted by melgross
You're assuming it's true. We don't know that yet.
Yes, I'm assuming it's true - the evidence is too strong IMO, and anyway, I'll be pleasantly surprised if I'm wrong the "something amazing from IBM" or the "Intel fabbing PPC" theories are right, where as the people in those camps will be really disappointed...
Originally posted by asdasd
all of this is true but also true of Apple's normal update cycle. OS X.4 introduced bugs as you mention. So will the update to Intel. Any intel bugs could be fixed in a " timely fashion " , or not, as with any other bugs introduced in an update.
You argument that Apple releases with too many bugs is taken, but not really relevant to this argument. The process of moving to Intel will be the same for the developer as if the OS changed underneath his application. Either can cause developer unreleated bugs as we are so much more dependent on the OS for frameworks and other services. But that is not reason enough to not do this, or else it would be reason enough to not have serious updates on the Mac.
I think the technical issues have been explained from my point of view.
The ideology behind this is more of an issue I think. I personally agree with it, but admit it may be a risk - and possible be seen as a capitulation of sorts.
It will be interesting to see market reaction tomorrow if this pans out.
I wasn't arguing this as a reason Apple shouldn't do this. I was just arguing that this has to be taken into consideration by the developer (the one who I was replying to stated 'no further testing is needed', which I just find ludicrous). I also don't feel (or if I did it was unintentional) that I was singling Apple out on bugs in its OS. They are there, as they would be for an Intel version. But I was just stating any software (OS or stand-alone app) by any vendor (MS, Apple, Adobe, etc) has bugs, and if you plan on having your software work on/with other's software, you can't make the mistake that those problems that aren't your bugs can be just dismissed.
Oh, and keep in mind that besides just the frameworks and OS being issues, processors themselves (both PPC and Intel) are known to contain bugs that must be worked around. These are almost always handled at the compiler/OS level, but its one more thing that Apple has to realize, coded for, and that has to be tested against.
Finally, this is just off the top of my head, speaking of processors. Aren't the floating point (and perhaps integer, but I don't think so) processors and registers different in an Intel chip then on the PPC? I'm speaking mostly on a bit-size and computation front. For if they are different, doesn't that lead to the possibiltiy of different results on different computers? Not sure if its the kind of thing that truly makes a difference, as I do little Floating Point code, just wondering.
Originally posted by asdasd
That "compatibilty" is there, but you are obstucating the issue a bit by implying that the layer does some kind of conversion at runtime. Not so. People who write to the higher level ( all developers) will be abstracted from the hardware level, yes, but that does not imply some type of runtime emulation. On an intel machine the entire OS is compiled down to intel byte code, and the applications that run in that space are intel byte coded.
Big endianess is an issue only if the developer bypasses normal read/write API to write or read in data. I imagine that is negligible in the real world.
As for the non-technical issues. I see this as a total benefit.
1) The OS will not be licenced so no talk, please, about clones destroying OS X's marketshare. The nerds who install on Dell's this will be a tiny percentage.
2) OS X will have the top megahertz chips. Nobody cares about the technical ideologies behind the chips, but the speed.
3) Apple can port Cocoa to windows ( and thus the iLife suite) and allow dual booting of Mac based machines into windows. This will facilitate switching, and just people who want to buy an Apple branded machine. i know boatloads of people who would buy a mac if it could also run windows for a time. This is the only way that Apple could ever hope to get to 10% or more of the market again.
Then it is up to Apple to have a much better operating system than the Windows side , so that people who buy the mac for the Form Factor, for the brand etc. will switch to OS X rather than stay with Windows. For those of you who are Mac fans to deny this possibility, is a bit rich, no?
I think Apple is confident enough with OS X - and more importantly - with it's stellar trajectory to assume it can compete with windows on the same machine. they should however, start to reduce the cost of both the .Mac services and the annual(ish) update costs.
You're right, I used the wrong term (I said I haven't programmed for a while
I should have abstraction as that was what I was describing. I was never implying that there was any conversion being done. As I said, the OS shields the programs from the hardware. It's not 100% but it's enough that when a chip is redesigned, the software will still work, if it were properly written.
I wasn't meaning to say that this was true from PPC to x86. If you had read my other posts you would have seen that. I was referring to (and, yes, I should have been more specific) the G3-G4-G5 shifts.
Originally posted by kiwi-in-dc
Yes, I'm assuming it's true - the evidence is too strong IMO, and anyway, I'll be pleasantly surprised if I'm wrong the "something amazing from IBM" or the "Intel fabbing PPC" theories are right, where as the people in those camps will be really disappointed...
What evidence? Randomly leaked statements by "industry execs"? Sorry for being a true skeptic about anything but I don't just buy fly-by-night theories because Jim-Bob the IT exec at such and such "industry" company heard something thru a chain-letter email that supposedly came straight from Steve Jobs on the HUSH HUSH and FOR YOUR EYES ONLY. Like I said before there is such a thing as shoddy reporting.
I'm also not denying anything. I see both sides of the argument but I also look at the big picture and the skeptic part of me is winning the argument.
Originally posted by brent1a
What evidence?
[snip]
I see both sides of the argument but I also look at the big picture and the skeptic part of me is winning the argument.
I am with ya.
I am pretty much with the Mac world's most reliable source right now:
Think Secret sources have heard nothing to date regarding any collaboration between Apple and Intel.
Link
Originally posted by Louzer
No, you don't understand the way OS X is designed. Its not one big app where all the compiled code for PPC and Intel are together. You can have separate sets of binaries inside your Application package, one for Intel and one for PPC (so you might say you compile it twice, with different platform flags). When you run the program, the OS picks the appropriate binary(s). There's no bloat, as the code doesn't require bloating, and the compiler should be optimizing it for each platform when its compiled.
Basically, there is no compatibility layer.
Oh, and even if there were, it shouldn't cause humongous slowdowns either, as you would be compiling to an intermediate code language that would be interpreted/compiled at run-time by the appropriate compatibility layer for the platform. (Of course, if the layer sucks, so does the performance, but that's a different story).
You don't call that bloat? I think most would.
Compatibility; read my reply to "asdasd".
I'm not saying "humongous" slowdowns. But if it is interpreted/compiled at runtime, that would be bad. That was the big problem Apple had with the 68xx to PPC conversion, interpreted code. I think it was Connectix that stored the code and fixed most of the performance problems You might not remember, or weren't old enough at the time, but 68xx programs ran at about half the speed they ran on the 68xx.
QT and apple then is/hold the defacto standard.
Originally posted by Hugi
I hope Apple switches to x86. Then we would be rid of all those stupid "When is Apple switching to x86" threads
Good point.
You don't have to read them though.
It would be a big step. It really seems to depend on the VE in any performance related area.
It's in PDF format.Here's the page:http://images.apple.com/macosx/pdf/MacOSX_UNIX_TB.pdf
Anyway it created a lot of public attention.
This is why I doubt if this is true:
http://www.eweek.com/article2/0,1759,1823273,00.asp