I want to know what will happen when my 64 bit G5 comes together with 64 bit OS tiger. Will I be blown away? Looking for someone who really understands what 64 bit means.....
Thanks
Thanks
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.
10.4 64 bit my G5 64 bit what does this mean?
- Thread starter PowermacG5
- Start date
- Sort by reaction score
THe biggest enhancement is that the OS can address more than 4 GB of RAM (something like 16 petabytes or so). It's most good for scientific users and such. You'll notice very little in regular use. Don't be fooled by the bigger number, that does not make it 'twice as fast' or something like that.
PowermacG5 said:
basically all 64bit will mean to you is that when the time comes you have access to more than 4 gigabytes of ram. 2^32 / 1024 / 1024 = 4096 megabytes of data.
2^64 is in the terrabytes of data.
64 bit just means that the number of registers increases, as such the memory available to the processor increases. it can address more ram and crunch bigger numbers. that's all really.
PowermacG5 said:
correct, pretty much just optimizations done to speed things along.
To those expecting as big an increase from Jaguar->Panther, you're kidding yourselves. In a immature state (Puma, Jaguar) there were plenty of optimizations to be done. Especially when you add so many features with each release, it's going to happen that you'll be able to do a lot of speedups due to just optimizing the code a bit. However not as many changes were made between Panther->Jaguar. Sure you have a lot of "features" but none of them are really in the same area that you seen in Panther. You got quartz extreme which is where a lot of your interface speedups came from. CoreImage will likely make a big difference in applications that use it, and you should expect some dramatic speed ups in that department come 10.5 since CoreImage isn't very mature. But to expect the whole OS to just dramatically increase in speed from Panther->Tiger is just something you can't expect. Tiger just all around adds features that should be in any modern operating system, better searching, better video that uses the graphics card, so on and so forth. They're end user visible. Panther had a lot of under the hood changes. Tiger has some, but not near as many as Panther. The biggest under the hood changes come in the form of developer tools. These alone will enhance the users experience though. It makes producing new applications even easier because we now have access to a database system, a great drawing and image rendering system among many other great little developer toys. They make creating new and exciting applications easier. This is what you will see with Tiger, new innovative applications that you hadn't seen before. Not giant speed enhancements.
"64 bit" as such doesn't mean anything. It has to be 64-bit something.
In the case of 64-bit addressing it means programs can address more memory. In the case of 64-bit operands it means the CPU can deal with bigger numbers at once.
So the only people who will benefit from this are people who need lots of memory (video editors) or who deal with very big numbers (scientists). But these are pretty important markets for apple so it's a Good Thing.
In the case of 64-bit addressing it means programs can address more memory. In the case of 64-bit operands it means the CPU can deal with bigger numbers at once.
So the only people who will benefit from this are people who need lots of memory (video editors) or who deal with very big numbers (scientists). But these are pretty important markets for apple so it's a Good Thing.
I suppose that 64 bit architecture in tiger will become more notable in later versions. For example, when more and more programs start to support 64-bit architexture of the G5, then you will see your machine flying.
Right now, all it means is that you will experience faster interface and functionality in Finder and apple's applications.
But it is generally a good thing, I believe the world has already begun to pass from 32-bit architexture to 64-bit.
You will see in the future how inportant that is.
Right now, all it means is that you will experience faster interface and functionality in Finder and apple's applications.
But it is generally a good thing, I believe the world has already begun to pass from 32-bit architexture to 64-bit.
You will see in the future how inportant that is.
Soulstorm said:
64bit is not faster than 32bit.
it's simply the number of bits a single register can hold. in which case it can address more memory or store bigger chunks of memory in the cache. In the end it can crunch bigger numbers, but not necessarily any faster.
The G5 "architecture" is really no different than existing 32bit "architectures"
Finder and Apple's applications have NO change from 32bit to 64bit. In fact, their applications are 32bit since a very large majority of their machines in use are still G3 and G4 machines.. which cannot process 64bit applications. Apple has also stated that they are not going to produce 2 different OSes based on 32bit and 64bit.. so you won't see 64bit fully until a very large portion of their users are on G5 or greater processors. Since they're still selling G4's in bulk then you can't expect this for another 2 or 3 releases at minimum. You get 64-bit kernel extensions in tiger, that is it. It simply provides developers a way to write 64bit applications in case they need access to more memory. that is all.
Sorry, but the UI, and therefor Finder, are 32-bit, even in Tiger. In fact, any software that makes use of the GUI frameworks *cannot* be 64-bit, because Apple has *not* converted those frameworks to 64-bit. If they did, there would have to be 2 versions of the frameworks: 1 for the G5, and 1 for all other Macs. Tiger does support 64-bit (address pointers and data) for command line processes, which is particularly useful in a server environment. The 64-bit memory addressing (virtual) is per process, not per system.Soulstorm said:
Panther and Tiger both provide G5 optimized (64-bit integer, hardware square root) math libraries.
DXoverDY: 32-bit vs 64-bit does not alter the number of registers available to a program on PPC, unlike current Intel 64-bit implementations. In other words, a 32-bit PPC program has access to all CPU registers, not a subset of them. It's not a matter of having X registers that are 64 bits wide and only being able to use 32 bits of each register in a 32-bit program. On PPC, you have X 64-bit registers or 2X 32-bit registers or a mixture of both.
Soulstorm said:
Nope. As explained above, 64 bit doesn't make your computer faster. In fact, it can slow things down. If you're using 64 bit instructions, that takes twice the number of bytes (8 for 64 bit, vs. 4 for 32 bit), which makes your CPU cache fill up faster, which means fetching from main memory more often, which means slower.
--Eric
OK, well let me ask this.... if the G5 can handle 64-bit words instead of the G3 and G4's 32-bits, would not an application written to take advantage of the doubled word width be capable of running rather faster on a G5 than it could run on a G3 or G4, simply because the processor can fetch and process the same amount of data in fewer cycles?
I understand the memory addressing issue, which frankly isn't going to help all that many people, but is extended addressing Tiger's ONLY 64-bit support?
I understand the memory addressing issue, which frankly isn't going to help all that many people, but is extended addressing Tiger's ONLY 64-bit support?
Eric5h5 said:
Surely that's not right. If one takes the analogy of the data being water in a reservoir, if you double the rate of outflow, you halve the time to empty it. Given that software and data files are a finite size, if you throughput at twice the rate, you complete the task faster.
za9ra22 said:
Yes. For example to add two 64-bit numbers on a G5 it is one instruction. On the G4 you would have to do the 32 least significant bits first and then do an add with carry on the top half.
thanks for the clarificationza9ra22 said:
you forget though that while a few tasks may complete faster, in the end you still have to transfer more data to the cache from ram or hard drive. so you complete the task faster but the processor is sitting idle waiting for more data to be put in due to the slower bottleneck, the ram or the hard drive. but also note that since the instructions are larger.. 8 bytes for 64 bit, and 4 bytes for 32 bit. you put less instructions in cache, but they take up twice the space. so your bottleneck gets a bit more noticable since your bottleneck isn't increasing it's bandwidth like the processor is. so it takes twice as long to transfer your instructions to cache since they're twice as big. With smaller instructions you don't wait as long for the instructions to transfer, only 4 bytes vs 8 bytes. so it comes down to the rest of the system not being able to throw enough information at the G5 to make it worthwhile yet. Our other bottlenecks are the problem, ram speed and hard drive speed. if that makes sense.
EDIT: you're essentially pushing out data faster than you get it, as such it's slower since it takes more time to get the data from it's other sources since they're twice as big. In the future this will be fixed when we have more effective means of storing data.
za9ra22 said:
note that your normal apps will not benefit. the gui parts of the OS are not 64bit. you technically can only have command line applications in a 64bit environment. Way too many tricks to get a gui app (like a game for example) to be 64 bit at this time.
DXoverDY said:
Yes, but at the same time you're using less clock cycles to do it. The bottlenecks are the same regardless of how much data you push through them, it's just that at some point you'll reach the capacity of the slowest/most restrictive bottleneck and that's what will limit overall performance of the system. Up to that point, a 64-bit system should surely run faster than an otherwise identical 32-bit system.
And in reality, our 32-bit G3s and G4s are NOT otherwise identical. They have typically less cache, slower bus speeds, slower memory, even slower drives.
za9ra22 said:
That's not such a good analogy though, because you don't just let it flow through, you do something on the way through. And what you do is the instruction.
Now it is not the case that there is one instruction: "modify the bits like so." If there was then I'm sure a compiler could get a huge benefit from 64-bit. Rather, there are many instructions corresponding to higher level operations, and programs are compiled to these.
broken_keyboard said:
Indeed, but that's what I'm having a hard time understanding. To my mind, if the compiled application knows to throw 64-bits at the processor at a time instead of 32, how could that be anything other than a faster way to process instructions and data? Admittedly, given the notion of bottlenecks getting 'filled to capacity' probably not twice the processing speed, but certainly faster than the 32-bit version.
It would require an application written to work in a 64-bit environment and for Tiger to support it, but I don't see how this would not improve performance on a G5 system as and when the software exists.
Clearly I'm missing something!
I think you are confusing memory bus width (which feeds the cpu cache) and processor instruction width (32 bit vs 64 bit). The memory bus is already fetching 128 bits per cycle, regardless of whether the app running is 32-bit or 64-bit. However, most software is satisfied with 32-bit integers. A 64-bit app can add 2 64-bit numbers with a single instruction (ignoring the register loads to set it up), but a 64-bit app also requires 1 instruction to add 2 32-bit numbers; a 64-bit app can't add 2 sets of 32-bit numbers in 1 instruction, just because it's 64-bit. That's where your interpretation breaks down. In other words, when adding 2 32-bit integers, a 64-bit app can't do it any faster than a 32-bit app, in fact it will probably be a bit slower since the 64-bit app will use 64-bit memory pointers, while the 32-bit app will use 32-bit memory pointers. The 64-bit app will require more memory bandwidth and cache entries to fetch and store these 64-bit memory pointers.za9ra22 said:
To make the picture a bit muddier, on a G5 a 32-bit app *can* use the 64-bit integer math instructions, so the app is capable of adding to 64-bit instruction in a single instruction, just like the 64-bit app.
Since the PPC architecture is such that you can mix and match the best attributes of 32-bit and 64-bit computing, Apple has not been compelled to drive directly to a full 64-bit OS X implementation. Rather, they have chosen to implement 64-bit features where they make the most sense. As I posted above, both Panther and Tiger have G5 optimized math libraries available that exploit 64-bit integer math and the hardware square root instruction.
jayscheuerle
macrumors 68020
From what I understand, only apps that handle large chunks of data (Lightwave, Maya, Photoshop) will benefit from having parts rewritten to take advantage of 64 bits. Smaller, more immediately responsive apps like the Finder actually perform faster at 32.
This was according to an interview with someone from Apple. I'll see if I can find the link...
This was according to an interview with someone from Apple. I'll see if I can find the link...
za9ra22 said:
No, not at all true. 64-bit CPUs (running in 64-bit mode) are slower than otherwise identical 32-bit CPUs. The only speed benefit you get is for apps that actually require access to more than 4gigs of memory, or need to use very large numbers > 4billion. Huge databases do benefit, video editing could benefit, Safari will not, at least not today.
64-bit operations take longer to complete. Say you are adding two unsigned numbers, 4 and 5 you really only need 3 bits in each number to complete this operation. On a 32-bit system you need end up adding 29 bits that don't contain data, on a 64-bit system you add 61 bits that don't contain data. A 64 bit adder is more complicated than a 32 bit adder and takes longer to generate a result. Not significantly longer, but longer.
Also, as has been pointed out, if you have 64 bit instructions now instead of 32 bit, your instruction cache fills up twice as fast unless you double the size of the cache. If you have 64 bit integers your data cache fills up twice as fast. This results in more cache misses which slow down the system.
The costs outweigh the benefits for all but high end systems. Where this will become an advantage in the near future is the ability to have more than 4 gigs of ram without playing funny paging games like x86 does, and the ability for a single process to address more than 4 gigs of ram. Ram is becoming cheap to the point where we will see > 4 gigs in desktop machines in the not too distant future. With all of this memory available, applications will be a lot more liberal with the amount of memory that they do use.
Marketing hype aside (and it's not just Apple, the entire industry is doing this), all other things being equal 64-bit CPUs are slower.