That being said, if with the addition of 64-bit on the Mac, they give us something like a "double double" then that added precision will be a very welcome and useful addition. I have no idea if they will give us a 128-bit precision floating point arithmetic (I understand there may be hacks with Altivec to get this, but, in many of us need to move our code around CPU's and Altivec is then out of the question). If we do get that increased precision, it would be a great help for non-linear problems where machine round-off blows up in our face.
This already exists in the form of a "long double". I don't know if GCC supports it offhand, and I'm too lazy to look right now. Basically it uses 2 double precision floats, which is something that the G4 can do right now. The AltiVec 128-bit float uses 4 single precision float to try and achieve the same thing. Both of them are fairly slow compared to using a hardware supported type. The 970 will add no new floating point or AltiVec types.
Of course you know people at Apple while I don't so I'm not going to agree to buying you a beer. I might send you a registration fee for EVNova, however, unless I get too irritated by not being able to specify strings of hyper jumps in advance... [/B]
That's why I said above that we might see only partial 64-bit support in the system APIs -- e.g. only all the UNIX APIs might be available to a 64-bit app. This should be downright easy because the UNIX APIs have been 64-bit friendly for a very long time. This would allow "console apps" to be 64-bit, which captures all of the server applications and that is 99.9% of the apps which need to be 64-bit. Anybody else who needed it (say scientific visualization or video editting) could refactor their app into a client/server arrangement and get multiprocessor support at the same time. Plus this gives them the marketing advantage of being about to tout the 970 as a 64-bit machine, especially a 970-based Xserve.
First an opinion then a question...
It's seems that the truth, as far as perception in the general computing publics eyes goes, is that it's just a numbers game. Most of the people I regularly evangelize the mac too just don't buy the megahertz myth, but do seem to accept 64bit as the holy desktop grail.
I'm guessing that Apple will want to make the most of there 64bitness without any uproar over it being "half-implemeted" like current DDR-RAM, even if it's not true.
Remember no one cares if the truth takes 15 minutes and a diagram to explain, they will only remember the quick version.
My Question: If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear? (obvious work related question, I know!)
Programmer, guess this one is directed at you but if anyone has any wisdom....
You guys are forgetting one key person who is on Apple's board of directors, Arthur D. Levinson, Ph. D.
Who is he you ask? The Chairman and CEO of Genentech and I am sure they would just love Apple to go 64 bit...and they purchase a lot of Mac's...enough to where I think it would be worth Apple's while to do it.
My Question: If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear? (obvious work related question, I know!)
Programmer, guess this one is directed at you but if anyone has any wisdom....
If there are already 64-bit versions of those apps then I'd expect them to appear almost instantly... somebody will just recompile them against the latest OS APIs and with the 64-bit flag thrown, and out pops a 64-bit executable. The main thing is that the OS has to be able to create a 64-bit address space and present a 64-bit version of the Posix APIs.
The PPC 970 can not run on 10.2 unless they choose to modify parts of it to support the new processor. The 970 can run 32-bit apps as they are, but not a standard 32-bit OS. Some code need to be modified first.
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Perhaps, but that 0.1% consists of front-runners. The rest of the market will preferably choose the same tools as the "pro's". I'd certainly want to try and capture a decent chunk of that market, especially when it's an issue of when (and not if) anyway. Besides, 64-bitness also allows for some very nice techniques such as extensive file mapping:
As you can see it's already in OS 9, but you can imagine that even a 4GB memory space (per app) can run out quickly when you want to file map big files. This technique can also be used to implement the file system as a big database (think advanced metadata). This is far easier (and faster) to implement with file mapping. When developers latch on to ideas like this, many users may reap the benefits of a through-and-through 64-bit OS.
If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear?
MySQL can simply be compiled for 64-bit CPU's. Various 64-bit versions are available as binaries (Sparc, IA64, Alpha, etc).
64 bit PHP is being worked on it seems (judging from a quick peek at the developer mailing list), but I'm not sure what the exact status is at the moment.
If there are already 64-bit versions of those apps then I'd expect them to appear almost instantly... somebody will just recompile them against the latest OS APIs and with the 64-bit flag thrown, and out pops a 64-bit executable.
I WANT TO HIRE YOUR PROGRAMMERS
Not that I have the budget
Seriously, while it is possible to write address-length agnostic code, I've never seen it done without a lot of heartache, at least if it's written in C. There's just way too many gotchas to have the 64-bit executable "pop-out". However, having 64-bit executable appear within 6 months is not too hard to imagine. (Unless they've been producing the code for another 64-bit platform, in which case it should a recompile.)
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
The PR value is priceless though. In one simple move Apple could reclaim the performance crown with a single 1.8GHz 970 (remember clock for clock these things are supposed to be 2x the speed of a G4 and clock for clock a G4 is supposed to be 30% faster than a Pentium). Now add Altivec. Now add the fact that they might debut at 2GHz+ (equivalent to a 4GHz G4!).
So come September Apple releases the first 64bit desktop, with a 64bit OS, 64bit Shake, 64bit FCP. All these mostly useless 64bit-isms add up to a marketing coup.
Intel has proved real benefit is irrelevent, it's big exciting numbers that count.
My take: 64-bit addressing is not useful to 99.9% of the user base. However, it would open up some new markets to apple, mostly simulation/modeling software and intense video rendering/manipulation at full cinematic resolution. While not plentiful, contracts for just a handful of these types of systems can be quite profitable.
The interesting thing is that very few of the standard libraries and APIs need to be rewritten for the OS to run 64bit versions of these types of apps. The number-crunching portions of these apps, portions capable of benefiting from higher precision or prodigious memory, rarely if ever interact with Carbon and Cocoa calls.
This is why some people are speculating that the kernel and unix apps will be 64bit-enabled prior to the higher level APIs used for most consumer and business apps. This could allow unmodified 32bit apps to be fed remapped memory from above the first 32bits of addressing. These threads could not get more than the current 2GB limit but this would still be an improvement.
What are your thoughts on the possibility of remapped address space during the 32->64bit transition?
Is this an interim solution that Apple will or should attempt to implement?
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
I whole-heartedly disagree. I remember back to the 16 to 32-bit jump, people were saying the same thing. It took very little, probably 8 months to a year, for applications to be 32-bit and enjoy the same benefits that other applications were having.
Moving to 64-bit will push developers to compete. That in itself is a good thing for the platform. Look how long it has taken the numbskulls at Quark to realize it. It took a push from Apple to get them off their arses and start living in the present.
I guarantee that within a year or so of the release of a generally all-around 64-bit OS that people will be clammoring for 64-bit apps and not looking to buy 'older' 32-bit stuff. This will be a huge push for software developers and should help out the market as well. More programmers and support staff required for the switch. A nice boost in the economy is definately needed and I think this could fuel such a thing.
I really don't want to see the next president (whoever it may be) take credit for economic recovery when they are really riding the tails of a self-driven economy anyway! Sorry admins, no more politics, I swear!
What do you think the odds of Quark being 64-bit native on the release of 6.0? Hmmmmmm...
Seriously, while it is possible to write address-length agnostic code, I've never seen it done without a lot of heartache, at least if it's written in C. There's just way too many gotchas to have the 64-bit executable "pop-out". However, having 64-bit executable appear within 6 months is not too hard to imagine. (Unless they've been producing the code for another 64-bit platform, in which case it should a recompile.)
Geez, did you even read what I said? I'll repeat it:
Quote:
If there are already 64-bit versions of those apps
Migrating 32-bit code to 64-bit code is non-trivial unless the application is trivial. The nice thing about the 64-bit PowerPC is that it runs 32-bit code just fine so you can move applications to 64-bit when you are able, and if it makes sense for that application. I doubt most applications will ever move. There have been many 64-bit platforms for a long time now (almost all of them Unix variants), however, so applications that already exist for those platforms will move easily to the new MacOS X 64-bit platform. Applications which are both 64-bit and 32-bit clean and have had their 32-bit versions already ported to MacOS X should pop across with almost no work involved unless the guy who did the original port really screwed up. Even if Apple only provides the Posix APIs in 64-bit form that will still be very useful for these kind of ports because they are already coming from a Posix environment. I really hope Apple provides at least that level of support right off the bat.
This is why some people are speculating that the kernel and unix apps will be 64bit-enabled prior to the higher level APIs used for most consumer and business apps. This could allow unmodified 32bit apps to be fed remapped memory from above the first 32bits of addressing. These threads could not get more than the current 2GB limit but this would still be an improvement.
What are your thoughts on the possibility of remapped address space during the 32->64bit transition?
Is this an interim solution that Apple will or should attempt to implement?
Given the decoupling that already exists between the virtual memory that an app uses and the real memory (RAM or HD) that it maps to, I'm pretty sure that it's fairly simple to map 32-bit apps to adresses beyond 4GB. It will allow us to use more than 4GB in total, even with 32-bit apps.
BTW, there is nothing interim about this. It's a viable long term solution for 'legacy' 32-bit apps. Many 32-bit apps will never make the transition to 64-bit because they don't need more than 2GB, but you still want to be able to use more RAM for all these apps combined.
I remember back to the 16 to 32-bit jump, people were saying the same thing. It took very little, probably 8 months to a year, for applications to be 32-bit and enjoy the same benefits that other applications were having.
You are comparing apples with oranges. 16-bit pointers can address only 64KB, which was totally insufficient when CPU's transitioned to 32-bit. Because the CPU makers were too late, apps were using all kinds of hacks to support more than 64KB. In other words, just about every programmer was clamoring for 32-bit. Furthermore, 32-bit integer calculations were frequently useful and had to be emulated by using two 16-bit integers (slow+ugly).
The current situation is far different. The 2GB that you can address in most 32-bit systems is sufficient for most software that exists today. Some programs do indeed need more, but the majority of software is not hampered by this limitation. Besides, 64-bit integer calculations are quite rare.
Quote:
I guarantee that within a year or so of the release of a generally all-around 64-bit OS that people will be clammoring for 64-bit apps and not looking to buy 'older' 32-bit stuff.
That might be true, but it will not be for technical reasons. A 64-bit word processor may sound nice, but your doc-files tend to corrupt long before you hit the 2GB threshold (and your paper would probably be rejected because of verbosity). Of course, some people will have good reason to ask for 64-bit programs, but it isn't the majority of the market.
Quote:
This will be a huge push for software developers and should help out the market as well. More programmers and support staff required for the switch. A nice boost in the economy is definately needed and I think this could fuel such a thing.
The sheer power of the PowerPC 970 is probably going to do more to boost sales (and the transition to OS X) than 64-bit apps will. Besides, a lot of investments in OS X software have already been made. I don't know whether the market will bear another upgrade bonanza. Especially upgrades that don't have much added value (witness the slow sales of Office X).
Comments
Originally posted by atomicham
That being said, if with the addition of 64-bit on the Mac, they give us something like a "double double" then that added precision will be a very welcome and useful addition. I have no idea if they will give us a 128-bit precision floating point arithmetic (I understand there may be hacks with Altivec to get this, but, in many of us need to move our code around CPU's and Altivec is then out of the question). If we do get that increased precision, it would be a great help for non-linear problems where machine round-off blows up in our face.
This already exists in the form of a "long double". I don't know if GCC supports it offhand, and I'm too lazy to look right now. Basically it uses 2 double precision floats, which is something that the G4 can do right now. The AltiVec 128-bit float uses 4 single precision float to try and achieve the same thing. Both of them are fairly slow compared to using a hardware supported type. The 970 will add no new floating point or AltiVec types.
Originally posted by Programmer
Of course you know people at Apple while I don't so I'm not going to agree to buying you a beer. I might send you a registration fee for EVNova, however, unless I get too irritated by not being able to specify strings of hyper jumps in advance... [/B]
You can, as a matter of fact! It's covered here in the FAQ: http://www.ambrosiasw.com/webboard/F...ML/000038.html
Of course, if you play the Polaris storyline, you can get the nifty multiple-jump-without-stopping gadget. (And a lot of other nifty gadgets too!)
Originally posted by Programmer
That's why I said above that we might see only partial 64-bit support in the system APIs -- e.g. only all the UNIX APIs might be available to a 64-bit app. This should be downright easy because the UNIX APIs have been 64-bit friendly for a very long time. This would allow "console apps" to be 64-bit, which captures all of the server applications and that is 99.9% of the apps which need to be 64-bit. Anybody else who needed it (say scientific visualization or video editting) could refactor their app into a client/server arrangement and get multiprocessor support at the same time. Plus this gives them the marketing advantage of being about to tout the 970 as a 64-bit machine, especially a 970-based Xserve.
First an opinion then a question...
It's seems that the truth, as far as perception in the general computing publics eyes goes, is that it's just a numbers game. Most of the people I regularly evangelize the mac too just don't buy the megahertz myth, but do seem to accept 64bit as the holy desktop grail.
I'm guessing that Apple will want to make the most of there 64bitness without any uproar over it being "half-implemeted" like current DDR-RAM, even if it's not true.
Remember no one cares if the truth takes 15 minutes and a diagram to explain, they will only remember the quick version.
My Question: If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear? (obvious work related question, I know!)
Programmer, guess this one is directed at you but if anyone has any wisdom....
Who is he you ask? The Chairman and CEO of Genentech and I am sure they would just love Apple to go 64 bit...and they purchase a lot of Mac's...enough to where I think it would be worth Apple's while to do it.
Originally posted by robster
My Question: If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear? (obvious work related question, I know!)
Programmer, guess this one is directed at you but if anyone has any wisdom....
If there are already 64-bit versions of those apps then I'd expect them to appear almost instantly... somebody will just recompile them against the latest OS APIs and with the 64-bit flag thrown, and out pops a 64-bit executable. The main thing is that the OS has to be able to create a 64-bit address space and present a 64-bit version of the Posix APIs.
Originally posted by moki
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Perhaps, but that 0.1% consists of front-runners. The rest of the market will preferably choose the same tools as the "pro's". I'd certainly want to try and capture a decent chunk of that market, especially when it's an issue of when (and not if) anyway. Besides, 64-bitness also allows for some very nice techniques such as extensive file mapping:
http://developer.apple.com/technotes/tn/tn2011.html
As you can see it's already in OS 9, but you can imagine that even a 4GB memory space (per app) can run out quickly when you want to file map big files. This technique can also be used to implement the file system as a big database (think advanced metadata). This is far easier (and faster) to implement with file mapping. When developers latch on to ideas like this, many users may reap the benefits of a through-and-through 64-bit OS.
Originally posted by robster
If the obvious first area of interest for 64bitness is going to be command line apps, how long do you think it would be before a 64bit version of Apache2, MySQL and PHP appear?
Covalent And Redhat Developing 64 bit Apache
MySQL can simply be compiled for 64-bit CPU's. Various 64-bit versions are available as binaries (Sparc, IA64, Alpha, etc).
64 bit PHP is being worked on it seems (judging from a quick peek at the developer mailing list), but I'm not sure what the exact status is at the moment.
If there are already 64-bit versions of those apps then I'd expect them to appear almost instantly... somebody will just recompile them against the latest OS APIs and with the 64-bit flag thrown, and out pops a 64-bit executable.
I WANT TO HIRE YOUR PROGRAMMERS
Not that I have the budget
Seriously, while it is possible to write address-length agnostic code, I've never seen it done without a lot of heartache, at least if it's written in C. There's just way too many gotchas to have the 64-bit executable "pop-out". However, having 64-bit executable appear within 6 months is not too hard to imagine. (Unless they've been producing the code for another 64-bit platform, in which case it should a recompile.)
Originally posted by moki
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
The PR value is priceless though. In one simple move Apple could reclaim the performance crown with a single 1.8GHz 970 (remember clock for clock these things are supposed to be 2x the speed of a G4 and clock for clock a G4 is supposed to be 30% faster than a Pentium). Now add Altivec. Now add the fact that they might debut at 2GHz+ (equivalent to a 4GHz G4!).
So come September Apple releases the first 64bit desktop, with a 64bit OS, 64bit Shake, 64bit FCP. All these mostly useless 64bit-isms add up to a marketing coup.
Intel has proved real benefit is irrelevent, it's big exciting numbers that count.
The interesting thing is that very few of the standard libraries and APIs need to be rewritten for the OS to run 64bit versions of these types of apps. The number-crunching portions of these apps, portions capable of benefiting from higher precision or prodigious memory, rarely if ever interact with Carbon and Cocoa calls.
This is why some people are speculating that the kernel and unix apps will be 64bit-enabled prior to the higher level APIs used for most consumer and business apps. This could allow unmodified 32bit apps to be fed remapped memory from above the first 32bits of addressing. These threads could not get more than the current 2GB limit but this would still be an improvement.
What are your thoughts on the possibility of remapped address space during the 32->64bit transition?
Is this an interim solution that Apple will or should attempt to implement?
Originally posted by moki
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
I whole-heartedly disagree. I remember back to the 16 to 32-bit jump, people were saying the same thing. It took very little, probably 8 months to a year, for applications to be 32-bit and enjoy the same benefits that other applications were having.
Moving to 64-bit will push developers to compete. That in itself is a good thing for the platform. Look how long it has taken the numbskulls at Quark to realize it. It took a push from Apple to get them off their arses and start living in the present.
I guarantee that within a year or so of the release of a generally all-around 64-bit OS that people will be clammoring for 64-bit apps and not looking to buy 'older' 32-bit stuff. This will be a huge push for software developers and should help out the market as well. More programmers and support staff required for the switch. A nice boost in the economy is definately needed and I think this could fuel such a thing.
I really don't want to see the next president (whoever it may be) take credit for economic recovery when they are really riding the tails of a self-driven economy anyway! Sorry admins, no more politics, I swear!
What do you think the odds of Quark being 64-bit native on the release of 6.0? Hmmmmmm...
Originally posted by Rhumgod
do you think the odds of Quark being 64-bit native on the release of 6.0? Hmmmmmm...
I'm assuming you mean MacOS X 10.6.0
Originally posted by Blackcat
I'm assuming you mean MacOS X 10.6.0
I meant Quark 6.0, but I think I like that interpretation even better!
Originally posted by Tom West
I WANT TO HIRE YOUR PROGRAMMERS
Not that I have the budget
Seriously, while it is possible to write address-length agnostic code, I've never seen it done without a lot of heartache, at least if it's written in C. There's just way too many gotchas to have the 64-bit executable "pop-out". However, having 64-bit executable appear within 6 months is not too hard to imagine. (Unless they've been producing the code for another 64-bit platform, in which case it should a recompile.)
Geez, did you even read what I said? I'll repeat it:
If there are already 64-bit versions of those apps
Migrating 32-bit code to 64-bit code is non-trivial unless the application is trivial. The nice thing about the 64-bit PowerPC is that it runs 32-bit code just fine so you can move applications to 64-bit when you are able, and if it makes sense for that application. I doubt most applications will ever move. There have been many 64-bit platforms for a long time now (almost all of them Unix variants), however, so applications that already exist for those platforms will move easily to the new MacOS X 64-bit platform. Applications which are both 64-bit and 32-bit clean and have had their 32-bit versions already ported to MacOS X should pop across with almost no work involved unless the guy who did the original port really screwed up. Even if Apple only provides the Posix APIs in 64-bit form that will still be very useful for these kind of ports because they are already coming from a Posix environment. I really hope Apple provides at least that level of support right off the bat.
Originally posted by dfiler
This is why some people are speculating that the kernel and unix apps will be 64bit-enabled prior to the higher level APIs used for most consumer and business apps. This could allow unmodified 32bit apps to be fed remapped memory from above the first 32bits of addressing. These threads could not get more than the current 2GB limit but this would still be an improvement.
What are your thoughts on the possibility of remapped address space during the 32->64bit transition?
Is this an interim solution that Apple will or should attempt to implement?
Given the decoupling that already exists between the virtual memory that an app uses and the real memory (RAM or HD) that it maps to, I'm pretty sure that it's fairly simple to map 32-bit apps to adresses beyond 4GB. It will allow us to use more than 4GB in total, even with 32-bit apps.
BTW, there is nothing interim about this. It's a viable long term solution for 'legacy' 32-bit apps. Many 32-bit apps will never make the transition to 64-bit because they don't need more than 2GB, but you still want to be able to use more RAM for all these apps combined.
Originally posted by Rhumgod
I remember back to the 16 to 32-bit jump, people were saying the same thing. It took very little, probably 8 months to a year, for applications to be 32-bit and enjoy the same benefits that other applications were having.
You are comparing apples with oranges. 16-bit pointers can address only 64KB, which was totally insufficient when CPU's transitioned to 32-bit. Because the CPU makers were too late, apps were using all kinds of hacks to support more than 64KB. In other words, just about every programmer was clamoring for 32-bit. Furthermore, 32-bit integer calculations were frequently useful and had to be emulated by using two 16-bit integers (slow+ugly).
The current situation is far different. The 2GB that you can address in most 32-bit systems is sufficient for most software that exists today. Some programs do indeed need more, but the majority of software is not hampered by this limitation. Besides, 64-bit integer calculations are quite rare.
I guarantee that within a year or so of the release of a generally all-around 64-bit OS that people will be clammoring for 64-bit apps and not looking to buy 'older' 32-bit stuff.
That might be true, but it will not be for technical reasons. A 64-bit word processor may sound nice, but your doc-files tend to corrupt long before you hit the 2GB threshold (and your paper would probably be rejected because of verbosity). Of course, some people will have good reason to ask for 64-bit programs, but it isn't the majority of the market.
This will be a huge push for software developers and should help out the market as well. More programmers and support staff required for the switch. A nice boost in the economy is definately needed and I think this could fuel such a thing.
The sheer power of the PowerPC 970 is probably going to do more to boost sales (and the transition to OS X) than 64-bit apps will. Besides, a lot of investments in OS X software have already been made. I don't know whether the market will bear another upgrade bonanza. Especially upgrades that don't have much added value (witness the slow sales of Office X).
I really don't want to see the next president
You mean the next dicator, don't you
Geez, did you even read what I said?
Um, not carefully enough.
You were of course, right on the money. I should have reread more carefully when one of your posts sounded wrong.