PDA

View Full Version : Is Tiger 64 bit?




harveypooka
Dec 6, 2004, 12:10 PM
Just checking - Tiger is going to be 64 bit? Also, will any apps take advantage of this?



jsw
Dec 6, 2004, 12:18 PM
Yes (mostly) and yes (as time goes on).

See here (http://www.apple.com/macosx/tiger/64bit.html) for Apple's commentary.

metfoo
Dec 19, 2004, 06:26 PM
Yes (mostly) and yes (as time goes on).

See here (http://www.apple.com/macosx/tiger/64bit.html) for Apple's commentary.


actually, the kernel is not 64bit as everyone hoped. apple states this in their 64bit transition guide, which can be downloaded by select and premier members on ADC.

Because 64-bit applications will be supported using a 32-bit kernel, this 64-bit support will have no impact on most device driver or kernel extension writers. However, there are exceptions, as explained in “Device Driver Issues” (page 23).

maya
Dec 19, 2004, 06:33 PM
Hoping that any OS after "Tiger" still has 32-biot support for all those G3 and G4 users. :)

Mechcozmo
Dec 19, 2004, 07:37 PM
There was a great thread on this a few weeks ago that explained why Tiger is part 32 bit, part 64. Search for it... I'm packing to leave on a trip. :D

It boils down to things like software rendering is 64 bit, but the GUI is 32 because 32 is easier on a computer than 64. Twice as much stuff to move around, you see.

spaceballl
Dec 27, 2004, 05:12 AM
Nope it's not cuz 64 is twice as much data to move around and its slower... That's not the case. In reality 64 bits isn't like twice as many as 32... Using binary digits, it is only one more digit, and that's how each bit works.

Basically, I don't see a good reason for Apple to not go 64 bits. They could very easily make a 64 bit version and a 32 bit version of the kernel. In the Unix world, 64 bit and 32 bit binaries can coexist without any problem so I don't know why Apple isn't doing the same in the mac world.

http://www.osnews.com/story.php?news_id=9220

Penman
Dec 27, 2004, 05:37 AM
Nope it's not cuz 64 is twice as much data to move around and its slower... That's not the case. In reality 64 bits isn't like twice as many as 32... Using binary digits, it is only one more digit, and that's how each bit works.

Basically, I don't see a good reason for Apple to not go 64 bits. They could very easily make a 64 bit version and a 32 bit version of the kernel. In the Unix world, 64 bit and 32 bit binaries can coexist without any problem so I don't know why Apple isn't doing the same in the mac world.

http://www.osnews.com/story.php?news_id=9220

Woah! This is cosmically wrong. You double the number of bits available in a binary system each time you ad a bit. Thus 33 bits can represent double the number of values as 32 bits. 64 bits is many orders of magnitude greater than 32 bits.

I don't argue the point - 64 bits would be great. However the amount of lifiting involved is much, much greater than with a 32 bit system.

spaceballl
Dec 27, 2004, 05:49 AM
Whoops you are completely right! Haha my field of study is much more high level these days than back in the days of studying pipelining, CPUs, binary digits, etc... I totally goofed. Each bit IS a binary digit. Hehe silly me. The word "bit" is actually short for "binary digit." Thanks for the correction.

broken_keyboard
Dec 27, 2004, 07:02 AM
The kernel itself will not change to 64-bit, because it doesn't need to. On PowerPC, the kernel doesn't have to be 64-bit to run 64-bit programs. That is an x86 thing.

So in other words it will be the same Tiger for everyone, regardless of whether you have a G3, G5 whatever.

As for the 64-bit programs themselves, they will have some limitations to start with, such as no GUI. But I'm sure that will be resolved in one of the 10.4.x releases. It's not an architectural thing, they just haven't ported the GUI library yet.

Anarchy99
Dec 27, 2004, 08:38 PM
they will have some limitations to start with, such as no GUI. But I'm sure that will be resolved in one of the 10.4.x releases. It's not an architectural thing, they just haven't ported the GUI library yet.
its not out yet its still months away would it be possible for this to be done by tigers release

derFunk
Dec 28, 2004, 08:55 AM
64 bit still should not make anything "slower"...the reason being that the registers are 64-bit anyway, and when running in 32bit mode, it's STILL spending half its time writing those extra 32 bits...they're just all 0's. If anything, a 64-bit OS should be FASTER than a 32-bit one, if it's well written, because it can take better advantage of those registers and get some extra work done each clock cycle.

Then again, I'm a Mac newbie and an x86 veteran...this is how it works on the dark side...I figured that if there is not a similar purpose in going 64bit on the Mac side, then the G5 would still be a 32-bit CPU.

wrldwzrd89
Dec 28, 2004, 09:01 AM
64 bit still should not make anything "slower"...the reason being that the registers are 64-bit anyway, and when running in 32bit mode, it's STILL spending half its time writing those extra 32 bits...they're just all 0's. If anything, a 64-bit OS should be FASTER than a 32-bit one, if it's well written, because it can take better advantage of those registers and get some extra work done each clock cycle.

Then again, I'm a Mac newbie and an x86 veteran...this is how it works on the dark side...I figured that if there is not a similar purpose in going 64bit on the Mac side, then the G5 would still be a 32-bit CPU.
Keep in mind that the biggest speed boost with 64-bit on the x86 side comes with the additional registers (from 8 to 16). The PowerPC, on the other hand, has 32 registers already, and doesn't really need more. Therefore, the benefits of 64-bitness are reduced to the increased addressing capabilities it gives. A smart 64-bit implementation could "partition" the 64-bit registers in 32-bit mode, which would give 32-bit applications a speedup similar to what happened with x86-64. There's some slowdowns associated with pointers suddenly becoming twice as big, squeezing other data out of the cache (which can be mitigated by increasing the cache size).

broken_keyboard
Dec 28, 2004, 06:57 PM
its not out yet its still months away would it be possible for this to be done by tigers release

Possibly, but the only Apple will *commit* to is the standard stuff for command line programs.

Edit: note that it's not such a big deal really, because you can just run the GUI in a separate 32-bit process, and when they click the buttons send messages to the 64-bit process to do stuff.

broken_keyboard
Dec 28, 2004, 07:01 PM
64 bit still should not make anything "slower"...the reason being that the registers are 64-bit anyway, and when running in 32bit mode, it's STILL spending half its time writing those extra 32 bits...they're just all 0's. If anything, a 64-bit OS should be FASTER than a 32-bit one, if it's well written, because it can take better advantage of those registers and get some extra work done each clock cycle.

That is correct, but as wrldwzrd89 said, don't forget about the cache. If you use 64-bit pointers when you don't really need to, all you do is fill up your cache faster and get fewer hits, thus slowing your program down.

Rincewind42
Dec 28, 2004, 07:13 PM
As for the 64-bit programs themselves, they will have some limitations to start with, such as no GUI. But I'm sure that will be resolved in one of the 10.4.x releases. It's not an architectural thing, they just haven't ported the GUI library yet.

Don't expect it in any 10.4.x release. In fact, given how much work it is I would say not to even expect it in 10.5. I expect them to start at the lowest level libraries and work their way up. Tiger starts with basically the C standard library and BSD APIs. Things will slowly move upwards from there I expect.

Rincewind42
Dec 28, 2004, 07:15 PM
That is correct, but as wrldwzrd89 said, don't forget about the cache. If you use 64-bit pointers when you don't really need to, all you do is fill up your cache faster and get fewer hits, thus slowing your program down.

Truthfully, I seriously doubt that pointer size will be a huge impact on program performance for most people, simply because if they are already in pointer heavy code they are going to be squeezed by the time it takes to transfer data from main memory to the cache (and presumably with lots of pointers in cache, there are lots of places in memory vying to be in the cache).

spaceballl
Dec 28, 2004, 07:20 PM
A smart 64-bit implementation could "partition" the 64-bit registers in 32-bit mode, which would give 32-bit applications a speedup similar to what happened with x86-64.
The way CPU pipelines are designed, you can't split the registers up like that to run two separate sets of 32 bit code.

x86-64 didn't give 32 bit apps a speedup because of anything to do w/ the 64 bit part of them. The 64 bit part of them, like G5s, is basically sitting idle. Those Athlon 64s are so damn fast because of their great architecture and on-die memory controller

derFunk
Dec 28, 2004, 08:11 PM
broken_keyboard -- I didn't take cache hit ratios into account, my bad...but if you've got a good set of prefetch hardware and good branch prediction, you won't have enough misses to drag the system down.

wrldwzrd -- that's why I prefaced it with being a PPC newbie...;) I wasn't entirely sure about register counts...I really gotta learn more about some of this stuff (http://arstechnica.com/articles/paedia/cpu/ppc-2.ars)...thank you for the correction.

wrldwzrd89
Dec 29, 2004, 04:10 AM
The way CPU pipelines are designed, you can't split the registers up like that to run two separate sets of 32 bit code.

x86-64 didn't give 32 bit apps a speedup because of anything to do w/ the 64 bit part of them. The 64 bit part of them, like G5s, is basically sitting idle. Those Athlon 64s are so damn fast because of their great architecture and on-die memory controller
That clears that up then. I was just taking a guess; I didn't know that it wasn't possible.

spaceballl
Dec 29, 2004, 04:22 AM
We should just make CPUs that CAN do that! Well, ****... I guess that's what dual core does haha

derFunk
Dec 29, 2004, 06:30 AM
The way CPU pipelines are designed, you can't split the registers up like that to run two separate sets of 32 bit code.

x86-64 didn't give 32 bit apps a speedup because of anything to do w/ the 64 bit part of them. The 64 bit part of them, like G5s, is basically sitting idle. Those Athlon 64s are so damn fast because of their great architecture and on-die memory controller

Right. There's a great writeup about the K8 architecture here (http://www.cpuid.com/K8/index.php)

Can anybody point me to something similar for the G5? I thought that Ars Technica had a big PPC 970 writeup but I'll be darned if I can find it since their site redesign.

Rincewind42
Dec 29, 2004, 06:33 AM
We should just make CPUs that CAN do that! Well, ****... I guess that's what dual core does haha

Not quite, but the idea is the same (dual core duplicates hardware vs splitting it). There are CPUs that can split registers to perform operations on different parts of them, these are SIMD machines generally (they perform the same action on different logical parts of a register). There are also MIMD architectures, but these are generally discussed in terms of standard parallel architectures (i.e. the PowerMac G5 would be considered a MIMD architecture). They don't actually split the registers at all (or share them :p).

wrldwzrd89
Dec 29, 2004, 07:06 AM
Right. There's a great writeup about the K8 architecture here (http://www.cpuid.com/K8/index.php)

Can anybody point me to something similar for the G5? I thought that Ars Technica had a big PPC 970 writeup but I'll be darned if I can find it since their site redesign.
You'd be surprised what a simple MSN search will turn up as the first two results for "arstechnica ppc970".

Part 1 (http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html)
Part 2 (http://arstechnica.com/cpu/03q1/ppc970/ppc970-0.html)

spaceballl
Dec 29, 2004, 07:41 AM
Not quite, but the idea is the same
Yup yup i meant on the conceptupal level

derFunk
Dec 29, 2004, 08:54 AM
You'd be surprised what a simple MSN search will turn up as the first two results for "arstechnica ppc970".

Part 1 (http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html)
Part 2 (http://arstechnica.com/cpu/03q1/ppc970/ppc970-0.html)

:p

dlisle20
Jan 3, 2005, 08:56 AM
would it make games run faster :confused:

Rincewind42
Jan 3, 2005, 09:25 AM
would it make games run faster :confused:

More Physical RAM? Yes. 64-bit? Probably not. If it did, it is less likely a game and more likely a vastly complicated simulation posing as one.

spaceballl
Jan 3, 2005, 03:40 PM
would it make games run faster :confused:
Epic Games made a 64bit version of UT Tournament for linux, I think for an AMD64 demo. It was faster than the 32bit version, but the linux 64bit version was slower than the windows 32bit version... But that was due to some other things like worse linux drivers, etc etc... In theory for advanced 3D graphics, performance can be improved, depending on whether or not the game is optimized for 64 bit.
-Kevin

Rincewind42
Jan 3, 2005, 06:11 PM
Epic Games made a 64bit version of UT Tournament for linux, I think for an AMD64 demo. It was faster than the 32bit version, but the linux 64bit version was slower than the windows 32bit version... But that was due to some other things like worse linux drivers, etc etc... In theory for advanced 3D graphics, performance can be improved, depending on whether or not the game is optimized for 64 bit.

Unfortunately as has been said before (I think earlier in this thread too). x86-64 is a completely different beast from most (all?) other 64-bit architectures. x86-64 doubles the number of integer registers, completely reorganizes the FPU and basically makes x86 a more modern architecture (although not by that much). You also need to consider the audience. It was for an AMD demo, so of course it was going to be optimized to outperform the 32-bit version. That's Marketing :).