Actually, NeXT supported 4 platforms simultaneously: PPC, x86, Alpha, and Sparc.
Um, I think you'll find it was 680x0, x86, HPPA and SPARC. The PPC harware they were developing was never released, and ASAIK they never released the software. So technically it could have been 5 supported platforms and 4 released platforms.
The Carbon API isn't tied to PowerPC any more than it was tied to 68k. Good thing too considering how much Cocoa apps suck ass. Why you think only Cocoa is platform neutral is beyond me.
For anyone else who wants to say that Apple is going with AMD, be warned
But Mac OS X already has AMD support!*
Quote:
If Apple said that they would release the PPC 601 machines as well as some new 68060 machines, then software vendors would not have readily ported to the PPC platform. In short, you can't release two different platofrms and expect your software vendors to not kill you.
You can also expect consumers to react badly to CPU insecurity if Apple doesn't trust a single CPU architecture for its consumer computers. When added to the which Mac architecture is best for me dilema, this can't be good for sales.
Quote:
The differences are really, really small.
I strongly suspect that this is a vast understatement. Isn't x86-64 similar to IA32 but with 64 bit versions of the appropriate instructions/registers?
Out of interest, do any/all/some 64/32 bit CPUs store two 32 bit words in one 64 bit register? To do otherwise would seem wasteful, but it would need some tracking for data.
What the **** are you talkign about? I can find examples of good cocoa apps and bad ones, just like I can find good exampls of carbon apps, and bad ones.
Um, I think you'll find it was 680x0, x86, HPPA and SPARC. The PPC harware they were developing was never released, and ASAIK they never released the software. So technically it could have been 5 supported platforms and 4 released platforms.
Well, if you want to be accurate about it, then yeah...
I strongly suspect that this is a vast understatement. Isn't x86-64 similar to IA32 but with 64 bit versions of the appropriate instructions/registers?
Instruction set support is trivial beyond mention. Just tell gcc which architecture you want and let 'er rip.
Hardware support is a different matter. You don't want to have to reinvent every little thing, manage two supply chains, deal with two levels of repair support, have differentiated driver issues, etc.
Get all of your hardware in line, with the fewest differences, and that problem clears up pretty well. My Xserve could well have an Intel or AMD chip in it and the sysadmins would hardly know the difference when dealing with the box, save the lack of a PS2 port. IDE drives, PCI slots, USB, gigabit, AGP, SDRAM, and on and on. It's technically very similar to the Dell server immediately below it.
Another view of this is that 970 might be a transitional product to open up POWER for the high end stuff, leaving AMD for the low-end stuff.
This just doesn't make sense to me. If you intro the 970 in PowerMacs and blade servers and then the Power series into big iron where is there any space for the AMD64 chip to fit in? All it does is add a parallel line of products with all the problems of two architectures (AMD64 and PPC).
The 970/970+(?)/980(?) & Power4/4+/5 would give a complete range of possibilities from notebooks to big stuff. Apple shouldn't dilly dally with other architechtures until there is no clear path beyond a point 2 years in the future. However, the Power line has a 5 coming in 1H04 and a 6 coming about '06. A '980' and a '990' based on these are logical and Apple has more info than us on this, I'm sure. So, if they see a good roadmap with high performing products, sticking with the ability to easily differentiate their products by using PPC is the best move and could give them an edge if the performance is better than the competition. (In the same way they lost the edge during the G4 years.)
This just doesn't make sense to me. If you intro the 970 in PowerMacs and blade servers and then the Power series into big iron where is there any space for the AMD64 chip to fit in? All it does is add a parallel line of products with all the problems of two architectures (AMD64 and PPC).
Well, if IBM wasn't interested in the low-end stuff, how does Apple bring developers to the POWER line if they have to stay with 32 bit PPC or move to something like Opteron? The transition is the killer. Basically the 970 lures developers to 64bit PPC without Apple having to sell the big iron POWER systems as a viable market for developers. Once there, if the 970 fell away and AMD remained, all the software would be ready for POWER and the platform would justify it's own effort (or not). It wouldn't require Apple to sell the transition - it happens naturally.
Quote:
The 970/970+(?)/980(?) & Power4/4+/5 would give a complete range of possibilities from notebooks to big stuff. Apple shouldn't dilly dally with other architechtures until there is no clear path beyond a point 2 years in the future. However, the Power line has a 5 coming in 1H04 and a 6 coming about '06. A '980' and a '990' based on these are logical and Apple has more info than us on this, I'm sure. So, if they see a good roadmap with high performing products, sticking with the ability to easily differentiate their products by using PPC is the best move and could give them an edge if the performance is better than the competition. (In the same way they lost the edge during the G4 years.)
MM
I agree that if IBM is willing to say in the game with low-end 64bit PPC, Apple would be wise to stay with it. I'm really only doubting IBMs committment to that product - not based on anything other than the probable size of the 970 hardware market which will seem very small to someone the size of IBM.
By having AMD out there as well, Apple has a nice little stick to whack IBM along with. Remember, Apple had a good roadmap with Motorola on the G4 and on - and that didn't work out so well. IBM may not set the same table, but Apple must be feeling vulnerable trusting everything to a roadmap that they neither control nor have insurance against.
AMD gives Apple insurance, whether in Opteron or in fabbing 970s for Apple.
There are some perception drawbacks - lack of commitment to one platform, ambiguity to developers, but I think that Apple could overcome these through promotion of always having leading edge performance. Regardless of which platform is fastest (970/Opteron), Apple will be able to claim they are on top. Buy an AMD box one month, a PPC the next. If all else is the same, what's the drawback to the user? What Jobs needs to dial the RDF into is pitting all efforts against Intel, that Apple can help AMD survive and IBM better compete.
"well there's always Apple, a pretty small company that's gone almost exclusively Cocoa for any new software development (minor stuff, like the Finder) ... and you know their software, well, doesn't quite suck either ..."
I agree with the sentiment, but the Finder is written in Carbon as far as I know.
What the **** are you talkign about? I can find examples of good cocoa apps and bad ones, just like I can find good exampls of carbon apps, and bad ones.
Mind elaborating as to why "Cocoa apps suck ass"?
Speed.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
With iCal and iPhoto speed were not the most important thing. It is even possible that they released them before removing all the debuging code and full optimisation, they are afterall free programs. However with Safari speed was one of the major goals. It had to have something beyond a slick face to compete. Other features are being added at a good rate from what I have read (still on OS 9 here).
Apple could probably use another spotlight program for Cocoa, but I dont know what they could come out with quickly that would fit the bill. Their heavy hitters might take some time due to having an established code base that needs rewriting (FileMaker, Final Cut, Shake, DVD Studio Pro). What might be better for Apple in the long run is if Oracle really jumped on the bandwagon with the move to 64 bit and came out with a Cocoa version. That would help Apple sell to the corporate market, and if Oracle did a "clean" job at writing the port, and was able to do it in a short period of time, then that would be a plug for Apples development platform.
With iCal and iPhoto speed were not the most important thing. It is even possible that they released them before removing all the debuging code and full optimisation, they are afterall free programs.
I disagree, there is no excuse for slow final apps. I'm using a £2500 Powerbook G4 800, nothing should feel 'gloopy'. If I can render 45 minutes of DVD video in 40 minutes, I want iPhoto to be snappy.
Apple needs its free apps to really look good, there is no reason to slow Macs more than they need.
I disagree, there is no excuse for slow final apps. I'm using a £2500 Powerbook G4 800, nothing should feel 'gloopy'. If I can render 45 minutes of DVD video in 40 minutes, I want iPhoto to be snappy.
Apple needs its free apps to really look good, there is no reason to slow Macs more than they need.
Apple needs these Apps to run with as few bugs as possible, optamizing performance is often left to maintenence upgrages by most major software companies. Yes performance is a part of the perception, but not as much as corrupted files and constant "unexpectadly quit" windows poping up on the screen... and since these are FREE apps, if you dont like them, then buy a comercial product that works better for you.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
Do you remember the first Finder? It sucked major ass, and still isn't the best. And it is written in Carbon. We could shoot examples back and forth of good apps and bad ones, but whats the point?
Actually, I think it is easier to write slow apps in carbon (or at least port your apss to slow ones) because of the new Event mechanism that the older OS 9 apps didn't use. Hence why some Carbon apps first ports sucked.
"make it work - then make it work fast" is good for most software... unless your definition of working software is software that works fast.
as for coccoa apps being slow... it isnt the framework that makes OSX apps slow [indeed, coccoa allows easy creation of very efficient/fast apps]. its the lack of exploiting hardware exceleration combined with the heavy use of bitmapped widgits and procedural textures (ie: brushed metal). if apple wanted to make the OSX UI fast... they could have ditched:
1. bitmapped widgits
2. textured windows
3. mandatory double buffering of every window (which also consumes tons of memory)
4. mandatory anti-aliasing of text
5. all rendering done by the CPU
and there are a few more lesser things as well. Incidently, if they had ditched these things... OSX would have run a LOT better on a LOT older hardware (makes you wonder).
If they didn't pursue these things... OSX would be fast - no doubt - though the expierience would be different to varying degrees... I wouldn't be surprised if they start dropping some of the things in the list soon anyway... they did some of this already.
or they thought the delta between those things you mentioned and new faster hardware that would negate those things was a lot shorter then it actually turned out to be
Out of interest, do any/all/some 64/32 bit CPUs store two 32 bit words in one 64 bit register? To do otherwise would seem wasteful, but it would need some tracking for data.[/SIZE]
No. When a 32-bit value is loaded from memory into a register it is typically sign-extended or the high 32-bits are zeroed (depending on the load instruction). There are some pair-SIMD style processors around that do what you suggest but they leave the tracking entirely up to the programmer.
This isn't particuarly wasteful because we're only talking about a handful of registers. Partial register values can be stored back to memory.
Comments
Originally posted by johnsonwax
Actually, NeXT supported 4 platforms simultaneously: PPC, x86, Alpha, and Sparc.
Um, I think you'll find it was 680x0, x86, HPPA and SPARC. The PPC harware they were developing was never released, and ASAIK they never released the software. So technically it could have been 5 supported platforms and 4 released platforms.
Originally posted by strobe
The Carbon API isn't tied to PowerPC any more than it was tied to 68k. Good thing too considering how much Cocoa apps suck ass. Why you think only Cocoa is platform neutral is beyond me.
Carbon ran on 68k machines? Really?
For anyone else who wants to say that Apple is going with AMD, be warned
But Mac OS X already has AMD support!*
If Apple said that they would release the PPC 601 machines as well as some new 68060 machines, then software vendors would not have readily ported to the PPC platform. In short, you can't release two different platofrms and expect your software vendors to not kill you.
You can also expect consumers to react badly to CPU insecurity if Apple doesn't trust a single CPU architecture for its consumer computers. When added to the which Mac architecture is best for me dilema, this can't be good for sales.
The differences are really, really small.
I strongly suspect that this is a vast understatement. Isn't x86-64 similar to IA32 but with 64 bit versions of the appropriate instructions/registers?
Out of interest, do any/all/some 64/32 bit CPUs store two 32 bit words in one 64 bit register? To do otherwise would seem wasteful, but it would need some tracking for data.
*(I know, it's really AutoMount Daemon)
Originally posted by strobe
...or RIDE BIKES?
Yes...go do that...on the highway.
Originally posted by kupan787
What the **** are you talkign about? I can find examples of good cocoa apps and bad ones, just like I can find good exampls of carbon apps, and bad ones.
Mind elaborating as to why "Cocoa apps suck ass"?
Have we been trolled Kupan?
Originally posted by JRG
Um, I think you'll find it was 680x0, x86, HPPA and SPARC. The PPC harware they were developing was never released, and ASAIK they never released the software. So technically it could have been 5 supported platforms and 4 released platforms.
Well, if you want to be accurate about it, then yeah...
You are totally correct.
Originally posted by Stoo
I strongly suspect that this is a vast understatement. Isn't x86-64 similar to IA32 but with 64 bit versions of the appropriate instructions/registers?
Instruction set support is trivial beyond mention. Just tell gcc which architecture you want and let 'er rip.
Hardware support is a different matter. You don't want to have to reinvent every little thing, manage two supply chains, deal with two levels of repair support, have differentiated driver issues, etc.
Get all of your hardware in line, with the fewest differences, and that problem clears up pretty well. My Xserve could well have an Intel or AMD chip in it and the sysadmins would hardly know the difference when dealing with the box, save the lack of a PS2 port. IDE drives, PCI slots, USB, gigabit, AGP, SDRAM, and on and on. It's technically very similar to the Dell server immediately below it.
Originally posted by johnsonwax
Another view of this is that 970 might be a transitional product to open up POWER for the high end stuff, leaving AMD for the low-end stuff.
This just doesn't make sense to me. If you intro the 970 in PowerMacs and blade servers and then the Power series into big iron where is there any space for the AMD64 chip to fit in? All it does is add a parallel line of products with all the problems of two architectures (AMD64 and PPC).
The 970/970+(?)/980(?) & Power4/4+/5 would give a complete range of possibilities from notebooks to big stuff. Apple shouldn't dilly dally with other architechtures until there is no clear path beyond a point 2 years in the future. However, the Power line has a 5 coming in 1H04 and a 6 coming about '06. A '980' and a '990' based on these are logical and Apple has more info than us on this, I'm sure. So, if they see a good roadmap with high performing products, sticking with the ability to easily differentiate their products by using PPC is the best move and could give them an edge if the performance is better than the competition. (In the same way they lost the edge during the G4 years.)
MM
Originally posted by MartianMatt
This just doesn't make sense to me. If you intro the 970 in PowerMacs and blade servers and then the Power series into big iron where is there any space for the AMD64 chip to fit in? All it does is add a parallel line of products with all the problems of two architectures (AMD64 and PPC).
Well, if IBM wasn't interested in the low-end stuff, how does Apple bring developers to the POWER line if they have to stay with 32 bit PPC or move to something like Opteron? The transition is the killer. Basically the 970 lures developers to 64bit PPC without Apple having to sell the big iron POWER systems as a viable market for developers. Once there, if the 970 fell away and AMD remained, all the software would be ready for POWER and the platform would justify it's own effort (or not). It wouldn't require Apple to sell the transition - it happens naturally.
The 970/970+(?)/980(?) & Power4/4+/5 would give a complete range of possibilities from notebooks to big stuff. Apple shouldn't dilly dally with other architechtures until there is no clear path beyond a point 2 years in the future. However, the Power line has a 5 coming in 1H04 and a 6 coming about '06. A '980' and a '990' based on these are logical and Apple has more info than us on this, I'm sure. So, if they see a good roadmap with high performing products, sticking with the ability to easily differentiate their products by using PPC is the best move and could give them an edge if the performance is better than the competition. (In the same way they lost the edge during the G4 years.)
MM
I agree that if IBM is willing to say in the game with low-end 64bit PPC, Apple would be wise to stay with it. I'm really only doubting IBMs committment to that product - not based on anything other than the probable size of the 970 hardware market which will seem very small to someone the size of IBM.
By having AMD out there as well, Apple has a nice little stick to whack IBM along with. Remember, Apple had a good roadmap with Motorola on the G4 and on - and that didn't work out so well. IBM may not set the same table, but Apple must be feeling vulnerable trusting everything to a roadmap that they neither control nor have insurance against.
AMD gives Apple insurance, whether in Opteron or in fabbing 970s for Apple.
There are some perception drawbacks - lack of commitment to one platform, ambiguity to developers, but I think that Apple could overcome these through promotion of always having leading edge performance. Regardless of which platform is fastest (970/Opteron), Apple will be able to claim they are on top. Buy an AMD box one month, a PPC the next. If all else is the same, what's the drawback to the user? What Jobs needs to dial the RDF into is pitting all efforts against Intel, that Apple can help AMD survive and IBM better compete.
I agree with the sentiment, but the Finder is written in Carbon as far as I know.
Socrates
Originally posted by kupan787
What the **** are you talkign about? I can find examples of good cocoa apps and bad ones, just like I can find good exampls of carbon apps, and bad ones.
Mind elaborating as to why "Cocoa apps suck ass"?
Speed.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
Originally posted by Blackcat
Speed.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
With iCal and iPhoto speed were not the most important thing. It is even possible that they released them before removing all the debuging code and full optimisation, they are afterall free programs. However with Safari speed was one of the major goals. It had to have something beyond a slick face to compete. Other features are being added at a good rate from what I have read (still on OS 9 here).
Apple could probably use another spotlight program for Cocoa, but I dont know what they could come out with quickly that would fit the bill. Their heavy hitters might take some time due to having an established code base that needs rewriting (FileMaker, Final Cut, Shake, DVD Studio Pro). What might be better for Apple in the long run is if Oracle really jumped on the bandwagon with the move to 64 bit and came out with a Cocoa version. That would help Apple sell to the corporate market, and if Oracle did a "clean" job at writing the port, and was able to do it in a short period of time, then that would be a plug for Apples development platform.
Originally posted by @homenow
With iCal and iPhoto speed were not the most important thing. It is even possible that they released them before removing all the debuging code and full optimisation, they are afterall free programs.
I disagree, there is no excuse for slow final apps. I'm using a £2500 Powerbook G4 800, nothing should feel 'gloopy'. If I can render 45 minutes of DVD video in 40 minutes, I want iPhoto to be snappy.
Apple needs its free apps to really look good, there is no reason to slow Macs more than they need.
Originally posted by Blackcat
I disagree, there is no excuse for slow final apps. I'm using a £2500 Powerbook G4 800, nothing should feel 'gloopy'. If I can render 45 minutes of DVD video in 40 minutes, I want iPhoto to be snappy.
Apple needs its free apps to really look good, there is no reason to slow Macs more than they need.
Apple needs these Apps to run with as few bugs as possible, optamizing performance is often left to maintenence upgrages by most major software companies. Yes performance is a part of the perception, but not as much as corrupted files and constant "unexpectadly quit" windows poping up on the screen... and since these are FREE apps, if you dont like them, then buy a comercial product that works better for you.
Originally posted by Blackcat
Speed.
It seems easier to write slow apps in Cocoa, look at the first iCal and iPhoto and now iMovie.
On the other hand Safari whizzes along.
I think it's just a matter of getting used to a new thing.
Do you remember the first Finder? It sucked major ass, and still isn't the best. And it is written in Carbon. We could shoot examples back and forth of good apps and bad ones, but whats the point?
Actually, I think it is easier to write slow apps in carbon (or at least port your apss to slow ones) because of the new Event mechanism that the older OS 9 apps didn't use. Hence why some Carbon apps first ports sucked.
You'll be seeing a lot of that, and since it's a sound design principle that results in more robust applications, that's a good thing.
as for coccoa apps being slow... it isnt the framework that makes OSX apps slow [indeed, coccoa allows easy creation of very efficient/fast apps]. its the lack of exploiting hardware exceleration combined with the heavy use of bitmapped widgits and procedural textures (ie: brushed metal). if apple wanted to make the OSX UI fast... they could have ditched:
1. bitmapped widgits
2. textured windows
3. mandatory double buffering of every window (which also consumes tons of memory)
4. mandatory anti-aliasing of text
5. all rendering done by the CPU
and there are a few more lesser things as well. Incidently, if they had ditched these things... OSX would have run a LOT better on a LOT older hardware (makes you wonder).
If they didn't pursue these things... OSX would be fast - no doubt - though the expierience would be different to varying degrees... I wouldn't be surprised if they start dropping some of the things in the list soon anyway... they did some of this already.
thanks a lot moto...
prob the answer is alittle of both.
Originally posted by grad student
....exceleration .....
Is this a hidden plug for Microsoft Excel??
Originally posted by Stoo
Out of interest, do any/all/some 64/32 bit CPUs store two 32 bit words in one 64 bit register? To do otherwise would seem wasteful, but it would need some tracking for data.[/SIZE]
No. When a 32-bit value is loaded from memory into a register it is typically sign-extended or the high 32-bits are zeroed (depending on the load instruction). There are some pair-SIMD style processors around that do what you suggest but they leave the tracking entirely up to the programmer.
This isn't particuarly wasteful because we're only talking about a handful of registers. Partial register values can be stored back to memory.