Is Tiger 64 bit?

harveypooka

macrumors 65816
Original poster
Feb 24, 2004
1,302
0
Just checking - Tiger is going to be 64 bit? Also, will any apps take advantage of this?
 

metfoo

macrumors member
Apr 25, 2002
61
0
jsw said:
Yes (mostly) and yes (as time goes on).

See here 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).
 

Mechcozmo

macrumors 603
Jul 17, 2004
5,215
2
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

macrumors 68030
Nov 2, 2003
2,856
240
San Francisco, CA
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

macrumors regular
Jan 27, 2004
158
0
spaceballl said:
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

macrumors 68030
Nov 2, 2003
2,856
240
San Francisco, CA
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

macrumors 65816
Apr 19, 2004
1,144
0
Secret Moon base
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

macrumors 6502a
Dec 13, 2003
860
759
CA
broken_keyboard said:
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

macrumors newbie
Dec 24, 2004
19
0
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

macrumors G5
Jun 6, 2003
12,106
73
Solon, OH
derFunk said:
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

macrumors 65816
Apr 19, 2004
1,144
0
Secret Moon base
Anarchy99 said:
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

macrumors 65816
Apr 19, 2004
1,144
0
Secret Moon base
derFunk said:
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

macrumors 6502a
Mar 3, 2003
620
0
Orlando, FL
broken_keyboard said:
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

macrumors 6502a
Mar 3, 2003
620
0
Orlando, FL
broken_keyboard said:
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

macrumors 68030
Nov 2, 2003
2,856
240
San Francisco, CA
wrldwzrd89 said:
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

macrumors newbie
Dec 24, 2004
19
0
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...thank you for the correction.
 

wrldwzrd89

macrumors G5
Jun 6, 2003
12,106
73
Solon, OH
spaceballl said:
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.
 

derFunk

macrumors newbie
Dec 24, 2004
19
0
spaceballl said:
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

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

macrumors 6502a
Mar 3, 2003
620
0
Orlando, FL
spaceballl said:
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

macrumors G5
Jun 6, 2003
12,106
73
Solon, OH
derFunk said:
Right. There's a great writeup about the K8 architecture here

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
Part 2