Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is Tiger 64 bit?
- Thread starter harveypooka
- Start date
- Sort by reaction score
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. 
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.
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.
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
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
spaceballl said:
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.
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.
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.
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.
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.
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).derFunk said:
Anarchy99 said:
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.
derFunk 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.
broken_keyboard said:
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.
broken_keyboard said:
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).
The way CPU pipelines are designed, you can't split the registers up like that to run two separate sets of 32 bit code.wrldwzrd89 said:
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
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.
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.
That clears that up then. I was just taking a guess; I didn't know that it wasn't possible.spaceballl said:
We should just make CPUs that CAN do that! Well, ****... I guess that's what dual core does haha
spaceballl 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.
spaceballl said:
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
).