Photorun said:
What with all but the portables being G5 by the time it's released (yes, eMacs soon to be too) it'd be nice to have X sail using mostly 64 bit. I'd even be willing to have one OS built for G4 and another built for G5 just so us G5 owners can finally take off the fuel governer and charge ahead full blast with 64 bit goodness, REALLY bringing our favorite forum word "snappy" to new heights.
I love how the term "64-bit" is thrown around as if it's some magical feature that'll double your computer's speed and cook your breakfast too. It's not (and it' won't).
First, you can already use 64 bit math (double precision floating point, 64-bit ints) in any program you like now. Any processor back to the G3 and before can do it. It'll be a bit more efficient on a G5 since the cpu supports it natively, but not overwhelmingly so. The vast,
vast majority of software doesn't (and has no need to) use 64-bit math. Mostly scientific software will benefit, and probably already uses it!
Second, making Tiger "64-bit" will not magically speed up your G5. If everything in Tiger were 64-bit, you'd probably slow things down. Maybe even noticeably so. Remember, that means pushing around twice as much data
for every operation.
The primary benefit to 64-bit support is allowing single processes to use more than 4 GB of memory. Again, this doesn't speed anything up, it just allows things to run that previously would have died when they ran out of memory. Except possibly in the rare case where a program that hit the 4 GB limit was smart enough to use temporary files on disk to keep going past that, but I don't know of many that do (maybe Photoshop? anyone??). In that case, assuming you have more than 4 GB in your machine to begin with, then yes, it'll speed up that one program by allowing it to access more physical ram.
But again, the primary area where this is useful is in scientific computing. I sometimes run some huge processing jobs at work that blast through the 4 GB memory barrier. I have to run them on slower Suns or SGIs because our G5 will kill those jobs under Panther. Tiger will be a welcome update, allowing me to run them on a much faster machine, utilizing more memory.
For
most consumer applications, we're probably still a year or three off from that 32-bit limit becoming a major problem. And of course, there are 32-bit machines out there which have pushed the problem back a few more years by allowing 36-bit memory access, etc. Heck, from what I remember, doesn't the G5 limit memory addressing to something along these lines (36 or 40 bits)? It still does 64-bit computations natively of course.
m a y a said:
Tiger is 64-bit, and also has 32-bit support. 🙂 It will install which ever version if your HW will not support one or the other.
This doesn't quite sound right from everything I've read. I'm pretty sure there will be only one install of Tiger, supporting both 32-bit and 64-bit. Perhaps 64-bit support will be optional on non-G5 machines, but certainly not the other way around. Aside from the kernel, most of the work in supporting 64-bit processes comes in making 64-bit versions of all the various libraries and frameworks. If your application uses 64-bit memory pointers, any library it calls will also have to accept them. I imagine this part is no small task, but ultimately it should be completely transparent to the user. A 32-bit application will use 32-bit versions of libraries at runtime, and same for 64-bit.
Anyway, please correct me if I got anything a little wrong!
😉