Tiger Will NOT be 64bit!!

[garybUK]

http://developer.apple.com/macosx/tiger/64bit.html

well actually it does run compiled C/C++ Services but not all the apple api's will be 64bit, this means that iLife and Office and Cocoa/Aqua will still be 32bit.... Fiddlesticks!

 

[bousozoku]

It will be 64-bit where it's most important without abandoning all the G3 and G4 users. If you consider how long commercial UNIX took to find its way to full 64-bit compatibility, you should take Mac OS X's progress to be good.

They could certainly hasten the advent of 64-bit-ness with Mac OS X Server since they charge a bit more for that, but it's nothing like the thousands and tens of thousands it costs to upgrade commerical UNIX.

There is no reason to sound the alarm at this point. Hopefully, though, it won't take as long as it took to get Mac OS to full PPC-compatibility.

 

[gwuMACaddict]

so how much real benefit will 32bit apps see?

 

[pncc]

so how much real benefit will 32bit apps see?

Stop confusing 64bit compatibility with faster performance. This '64bitness' isn't a hardware bandwidth kind of thing.

In many cases, 64bit compatibility may actually degrade performance. 64bit compatibility is mostly a memory capability in that the Application can address more than 4GB RAM. iLife, Safari, Mail, MS Office and similar Applications just don't need that kind of memory space. Even Photoshop would have to be working ona HUGE file to need that kind of memory. Genetics, high-end science applications would benefit.

 

[Chaszmyr]

Stop confusing 64bit compatibility with faster performance. This '64bitness' isn't a hardware bandwidth kind of thing.

In many cases, 64bit compatibility may actually degrade performance. 64bit compatibility is mostly a memory capability in that the Application can address more than 4GB RAM. iLife, Safari, Mail, MS Office and similar Applications just don't need that kind of memory space. Even Photoshop would have to be working ona HUGE file to need that kind of memory. Genetics, high-end science applications would benefit.

I could be wrong (please correct me if I am), but it was my understanding that 64 bit optimized applications address memory more rapidly even when using less than 4gb.

 

[gwuMACaddict]

Stop confusing 64bit compatibility with faster performance. This '64bitness' isn't a hardware bandwidth kind of thing

i understand this. i am also wondering how my photo/video editing software is going to behave...

 

[bousozoku]

I could be wrong (please correct me if I am), but it was my understanding that 64 bit optimized applications address memory more rapidly even when using less than 4gb.

It's a bit difficult to quantify.

Perhaps, obviously, 64-bit pointers (they point to memory locations) are twice as large as 32-bit pointers. 64-bit pointers map natively to 64-bit processors, even though the address space on the PPC970/G5 is only 42-bits. Because the pointer maps natively, it can be more efficient, even though it requires more space to store it.

When 32-bit applications need to contain an 3D image, database, or other data larger than 4GB, they must do it with a scheme to point to the information in two steps. On a 64-bit processor, this scheme becomes unnecessary and usually fixes many bugs. It also increases the speed of the application by removing unnecessary and inefficient code. Not all applications will benefit.

 

[wdlove]

So it sounds like the use of 64bit will be in gradual stages. A lot will have to do with what the developers come up with and are asking for. The G5 is ready and waiting.

 

[combatcolin]

Whatever is the case, you will see an increase in perfromance, notable mostly with G5 systems and trickling down to the slower machines (topped out G3's and G4's)

Dual CPU G4's should also see a fairish improvment.

 

[Sweetfeld28]

i wondered about this myself.

But, why couldn't they provide and installer disk, which could recignize what computer you have, and then based on that info. install the 32 or 64 bit software? Granted Apple would need to create a installer that would be contained on two cds.

Does anyone know if this could happen/possible?

 

[mj_1903]

i wondered about this myself.

But, why couldn't they provide and installer disk, which could recignize what computer you have, and then based on that info. install the 32 or 64 bit software? Granted Apple would need to create a installer that would be contained on two cds.

Does anyone know if this could happen/possible?

That would involve having two separate code-bases which for a project as large as Mac OS X is a big no no.

64bit will assist, but not for areas that most people use, except if you have movies open that are greater than 4gb in FCP and are running a G5. It is more of a boost to the scientific community.

 

[Rincewind42]

This comes up now?

Well, first this has been known since June, so I'm a little surprised people are talking about it now . But a few things

1) 32-bit and 64-bit apps fair no differently by the time you get to the virtual memory system. The PowerPC has to do a fair amount of translation for the virtual memory system to work, so the input pointer being 32-bit or 64-bit has no impact on performance.

2) 64-bit pointers can be a performance liability in pointer-heavy code. If your code is this pointer heavy though, you should probably look into seeing if you can optimize the pointers away (sometimes you can, sometimes you can't). In most code, 32-bit and 64-bit pointers make little to no difference in throughput.

3) 64-bit addressing allows you to access a lot more ram than 32-bit addressing, this is known. The speed advantage of this is generally only see when you have enough ram to actually need a pointer larger than 32-bits to address it all. There are uses for 64-bit addressing, but in general the GUI gains very little for it and it is a huge engineering effort to do it.

4) Extending #3, it takes a lot of work to port all of the system frameworks to 64-bit. I'm sure there is an effort underway to do it, but it will be slow and will have an end product of the entire system being shipped in two versions, a 32-bit and a 64-bit one basically. This is strictly because anything that needs to know about pointers (and virtually the entire system does) will have to be forked to deal with 32-bit or 64-bit pointers. Don't expect to see 64-bit GUIs anytime soon (and no, 10.5 isn't likely to have it either).

 

[Anonymous Freak]

64-bit ? faster.

As has been said, 64-bit does not directly equate to faster. 64-bit mode means two things:

1. The processor can address more physical memory. In the PPC 970's case, it really only supports 42-bit addressing, but the instruction set (PPC64) supports full 64, and the PPC970 just fakes it. This simply means that a single process can use significantly more memory than a single 32-bit process.

2. The processor can work on data in 64-bit chunks. This does *NOT* magically mean it can do things twice as fast as a 32-bit processor. Indeed, most apps today don't even really need to work on 32 bits of data at a time. (Think about '16-bit' CD-Audio; or '24-bit' images, which are really just three separate 8-bit channels...) Forcing a program to work in 64-bit mode means it has to transfer twice as much data for each piece of data it's working on. If it doesn't really need 64-bits of data, this actually SLOWS IT DOWN, because the processor ends up being a bandwidth hog. The best way I can say it is that a PowerPC 970, with it's 64-bit mode, is, in fact, *NOT* the perfect processor for processing CD audio. A 16-bit processor would be. If the 970 was EXACTLY the same, except with 16-bit data paths instead of 64-bit, it would probably process CD Audio much faster, since there would be no wasted overhead by sending an extra 16 or 48 bits of 'empty' data per data packet.

Try creating a text document, save it in 'Text Only', then in 'Unicode'. Unicode is for support of Asian languages, so it supports many more different 'letters' than plain text (or ASCII,) but that means that each character takes up twice as much space. When you're only typing English characters, you end up 'wasting' this extra space. It's the same thing with 64-bit. If you're not using 64-bit data, you're wasting processor resources if you're using 64-bit mode.

So, (my point finally comes around,) the OS doesn't NEED to be written in 64-bit. Very few things that the OS itself does ever needs to access more than 4GB of memory (again, for the OS itself,) and access 64-bit chunks of data. Likewise with iLife. Unless GarageBand gets a whole lot more powerful with its next revision, none of the iLife apps need 64-bit chunks of data, and none need more than 4GB per process. (Unless you happen to want to record your entire CD library into a single 4+GB AAC file, or store a 38,000-pixel by 38,000-pixel TIFF in iPhoto.)

To put it in perspective, when Apple first introduced the PowerPC architecture in 1995, less than 1% of the OS (7.1.2) was PowerPC native. Most of it was EMULATED. (Which is significantly worse than just being 'the wrong bit depth'.) It wasn't until OS 8.5 in 1998 that the OS was written entirely for the PowerPC.

 

[jimjiminyjim]

Why is it that every "step up" that we experience seems to cause expectations above and beyond what they really offer? Admittedly, I do recall a lot of hype around the G5 being 64bit... is it marketing, or is it people expecting to see incredible results without realizing the work that needs to go into creating those results?

 

[Rincewind42]

1. The processor can address more physical memory. In the PPC 970's case, it really only supports 42-bit addressing, but the instruction set (PPC64) supports full 64, and the PPC970 just fakes it. This simply means that a single process can use significantly more memory than a single 32-bit process.

Actually, there is nothing faked at all. Any process can address the full 16 exabyte range of memory that 64-bit pointers allow. Of course, no one has that much ram in their computer yet, so the designers of the 970 made a tradeoff for when it comes to accessing real ram, the CPU itself only has enough resources to access 16 terabytes (2^42) of real RAM. This is still more than any home computer user will have for a long time (double your RAM every year and you still need a decade to reach that). But if you have a program that wants to access 17 terabytes of RAM, it'll do it just fine (you'll just hit virtual memory for the last terabyte).

2. The processor can work on data in 64-bit chunks. This does *NOT* magically mean it can do things twice as fast as a 32-bit processor. Indeed, most apps today don't even really need to work on 32 bits of data at a time. (Think about '16-bit' CD-Audio; or '24-bit' images, which are really just three separate 8-bit channels...) Forcing a program to work in 64-bit mode means it has to transfer twice as much data for each piece of data it's working on. If it doesn't really need 64-bits of data, this actually SLOWS IT DOWN, because the processor ends up being a bandwidth hog. The best way I can say it is that a PowerPC 970, with it's 64-bit mode, is, in fact, *NOT* the perfect processor for processing CD audio. A 16-bit processor would be. If the 970 was EXACTLY the same, except with 16-bit data paths instead of 64-bit, it would probably process CD Audio much faster, since there would be no wasted overhead by sending an extra 16 or 48 bits of 'empty' data per data packet.

Not true at all. The PPC instruction set has full support for dealing with values smaller than 64-bits. All general purpose CPUs do. So it can do work on 16-bit data just fine and without any overhead*. In fact, using 64-bit integers it can do better than a 32-bit CPU because you can do various tricks to operate on two 16-bit samples in one operation. This doesn't mean that 64-bit is better of faster than 32-bit in all cases, but 64-bit CPUs give you more options than 32-bit CPUs -- and really that is all that the advance of technology generally offers you anyway.

*It is true that you have to shuffle the entire register's worth of data around for most operations. But the CPU is also generally designed to do optimal things when the register is mostly zeros. This is generally an optimization for multiplication and division.

Try creating a text document, save it in 'Text Only', then in 'Unicode'. Unicode is for support of Asian languages, so it supports many more different 'letters' than plain text (or ASCII,) but that means that each character takes up twice as much space. When you're only typing English characters, you end up 'wasting' this extra space.

UTF-8 is a unicode encoding that uses 8-bits per character for those characters that only require 8-bits to encode. This encoding generally makes English and other roman text systems nearly as compact as they were traditionally.

Didn't mean to pick on ya if it sounds like I am, just setting some things straight

 

[mj_1903]

Why is it that every "step up" that we experience seems to cause expectations above and beyond what they really offer? Admittedly, I do recall a lot of hype around the G5 being 64bit... is it marketing, or is it people expecting to see incredible results without realizing the work that needs to go into creating those results?

The G5 is a monster chip and Mac OS X and its associated applications don't really take advantage of it all that well, but I guess Apple wants to retain the portability of the code base.

A lot of the "issues", if you will call it that, are focused on GCC. It does not produce code that is all that great for the G5 line and probably never will. Potentially there is a 20-30% room for improvement in the compiler, but again portability will be sacrificed not to mention that it will take a lot of code.

Of course, we can always lame the blame on the "slow" Cocoa, Quartz and associated technologies. They do add a lot of overhead but it is worth it in the long run.

 

[broken_keyboard]

When the average Joe asks if you have a 32 or 64 bit OS, they are not asking whether all the system libraries have been ported or whether processes have longer pointers etc. They don't even know what those things mean.

What they are asking is: when the OS is running, is the CPU in 32 or 64-bit mode? And right there is where they make an ass out of themselves and umption. Because the idea of a CPU having modes is an Intel/AMD idea. The G5 has no overall mode, no big switch that is thrown that changes it from 32 to 64 bits. On a G5, 32 and 64 bit processes run all the same, hence the kernel can remain a 32-bit process and still create and manage 64-bit processes.

Once all the libraries are ported and we have a new ABI etc. we will have a full 64 bit OS. Don't let Intel weenies try to tell you the kernel must be a 64-bit process in order for programs to be. Maybe on their CPU...

 

[Anonymous Freak]

Didn't mean to pick on ya if it sounds like I am, just setting some things straight

hehe.. That's okay, I do the same, so I don't take offense. My comment on the 42-bitness, and 'faking' 64-bit memory access was meant to be exactly how you clarified it. I just didn't fully clarify myself. (I figured my post was long enough as-is. )

As for the PPC instruction set supporting different data sized, I wasn't aware that it supported less-than-32-bit. You learn something new every day.

And as for the UNICODE, you caught me. I was thinking of saving specifically in UNICODE-16, where it always uses 16-bit characters. (I tested by saving in MS Word, where saving in 'UNICODE' means UNICODE-16, and forgot about UNICODE-8.)

 

[Rincewind42]

And as for the UNICODE, you caught me. I was thinking of saving specifically in UNICODE-16, where it always uses 16-bit characters. (I tested by saving in MS Word, where saving in 'UNICODE' means UNICODE-16, and forgot about UNICODE-8.)

Yea, alas Word (and Windows in general actually) believe the world is UTF-16 when it comes to unicode, thus support for more compact formats is nonexistent in my experience. But most Mac OS X software saves unicode strings in UTF-8 format, and most localization software does the right thing to get more compact files (UTF-8 is expansive when your dealing mostly in the 16-bit range of unicode, so if you have CJK [chinese-japanese-korean] text, then UTF-16 is more compact).

 

[Fukui]

i wondered about this myself.

But, why couldn't they provide and installer disk, which could recignize what computer you have, and then based on that info. install the 32 or 64 bit software? Granted Apple would need to create a installer that would be contained on two cds.

Does anyone know if this could happen/possible?

Totaly unnecessary. Fat binaries take care of this IFAIK. All you need is simply one executable that contains code for a G4 and a G5, multiple installs are waaay old fashoned IMHO of course...

And, BTW 64-Bit doesn't really have much of an implact on iLife etc as you may think. I could only see it usefull in something like maybe iMovie or iDVD where you wanna have the whole (7+ GB) DVD content ready in RAM or something, you can already have files larger than 4GB on HFS+...

As for Cocoa/Corefoundation, well, there's lots and lots and lots of API's to check up with first. I think apple is more concerned with fixing bugs (esp. in CF) firstly, and adding new features like CoreData, xxxKit, CoreImage etc... I think is probably more important at this time than the number 6 and 4. Unless your a video game company that is...

For apps to really take advantage of the G5, better instruction ordering and other optimizations (compiler) are what will make the G5 trully 'shine,' not apps just being 64 bit...