[moonmonkey]

Safari (as far as I can tell) is the first piece of Panther software we have got our hands on, It looks like it will not leave beta untill the release of Panther.

So the big queston, is Safari 64bit ready?

Its built from the ground up for our new 64bit opperating system, it would be strange for apple not to make it 64bit ready.

Any ideas?

[entrox]

Applications don't need to be made "64-Bit ready" on the PowerPC. It has always been a 64-Bit architecture with provisions for 32-Bit implementations. If an application runs on PPC, it'll work in both modes (modulo unclean code).

So yes - Safari is "64-Bit ready" - just like about every other application on the Mac.

[Webscreamer]

We hear all these things about "64 bit" now days with the expected release of the 970. But what REALLY is the advantage of a 64 bit system?

[moonmonkey]

Originally posted by entrox:
Applications don't need to be made "64-Bit ready" on the PowerPC. It has always been a 64-Bit architecture with provisions for 32-Bit implementations. If an application runs on PPC, it'll work in both modes (modulo unclean code).

So yes - Safari is "64-Bit ready" - just like about every other application on the Mac.

I thought applications had to be recompiled to take advantage of the 64 bit system, they would work in fine 32bit mode but would not be quite as good?

[Rand]

IIRC, 64bit merely means that pieces of memory over XGb (like 2?) can be accessed at once. So, unless you have more than 2Gb of RAM, and you are accessing an entire chunk at once (not a lot of little calls) than 64bit does very little. This would come up if you were like encoding a 2Gb MP3, or working with very large movie tracks.


I could be wrong, but I was so hyped for the rumoured 64bit Mac last January, I did a lot of research on it.

but in general, apps like Safari should never really "utilize" the 64bit routines, though they may need some tweekage simply to allow proper placement of their current memory routines.

[moonmonkey]

Originally posted by Rand:
IIRC, 64bit merely means that pieces of memory over XGb (like 2?) can be accessed at once. So, unless you have more than 2Gb of RAM, and you are accessing an entire chunk at once (not a lot of little calls) than 64bit does very little. This would come up if you were like encoding a 2Gb MP3, or working with very large movie tracks.


I could be wrong, but I was so hyped for the rumoured 64bit Mac last January, I did a lot of research on it.

but in general, apps like Safari should never really "utilize" the 64bit routines, though they may need some tweekage simply to allow proper placement of their current memory routines.

Will 64 bit ready software run faster than 32bit software on a 64 bit system?

[Rand]

Originally posted by moonmonkey:
Will 64 bit ready software run faster than 32bit software on a 64 bit system?

I think applications will only run faster if the program is getting "clogged" on its way to the RAM under the 32bit structure. Generally though, this is not really that big of a problem. Now what WILL improve speed is a true DDR RAM system, and if 64bit is coupled with real DDR, memory access in programs will be significantly faster.

[chabig]

Here's a good discussion of what 64 bit computing means. It is written around the new AMD 64 bit CPU, but the general principles apply to all machines:

http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html

[Nebagakid]

Originally posted by moonmonkey:
Safari (as far as I can tell) is the first piece of Panther software we have got our hands on, It looks like it will not leave beta untill the release of Panther.

So the big queston, is Safari 64bit ready?

Its built from the ground up for our new 64bit opperating system, it would be strange for apple not to make it 64bit ready.

Any ideas?

Where are you getting this all from? Nowhere has Apple stated anything about 64-bit computing/OSes/Panther!

[Arkham_c]

Originally posted by Rand:
IIRC, 64bit merely means that pieces of memory over XGb (like 2?) can be accessed at once. So, unless you have more than 2Gb of RAM, and you are accessing an entire chunk at once (not a lot of little calls) than 64bit does very little. This would come up if you were like encoding a 2Gb MP3, or working with very large movie tracks.

Not entirely true. What you describe is an artifact of "64-bit addressing", meaning that memory addresses are stored as 64-bit values rather than 32-bit values.

Historically, 64-bit computing refers to 64-bit general-purpose registers. Most common CPUs have are 32-bit registers. Using 64 bits means that you can theoretically house and process bigger chunks of data at a time. However, this requires the compiler to organize data in this fashion in the apps.

It's actually a complex question. 64 bit machines can sometimes be slower than 32-bit since it does more work and moves more bits at a time.

[alex_kac]

Safari would have no benefit whatsoever to be 64 bit. I would expect that only a handful of applications will ever be ported over to use 64 bit extensions in Panther - mainly databases, Photoshop, Final Cut Pro, etc...

64-bits is not "faster". Not necessarily. And as others have pointed out, the PPC architecture has always been 64-bits from the beginning. The consumer PPC devices just were 32-bit subsets.

[Webscreamer]

Originally posted by Nebagakid:
Where are you getting this all from? Nowhere has Apple stated anything about 64-bit computing/OSes/Panther!

Exactly what I was thinking... just beat me to it

[Synotic]

Originally posted by Webscreamer:
Exactly what I was thinking... just beat me to it

I think he means that the final of Safari will come out when Panther is released. Implying that it is "Panther" software.

[Webscreamer]

Originally posted by Synotic:
I think he means that the final of Safari will come out when Panther is released. Implying that it is "Panther" software.

Please don't put words in my mouth! I ment what I said... I can speak for myself!

[MaxPower2k3]

Originally posted by Webscreamer:
Please don't put words in my mouth! I ment what I said... I can speak for myself!

i don't think he was putting words in your mouth, i think he was telling you what the topic starter meant by his post...

[Webscreamer]

Originally posted by MaxPower2k3:
i don't think he was putting words in your mouth, i think he was telling you what the topic starter meant by his post...

Sorry... my bad!

[Millennium]

For the most part, Safari would not gain any advantage from a 64-bit processor.

However, it actually matters surprisingly little. Most apps currently on OSX should run fine on a 64-bit PowerPC chip without even a recompile.

The only apps which might run into problems are those which have to work on a very low level. Disk-repair apps, perhaps (which have to use low-level routines to do their stuff), or QuickTime codecs (which use low-level routines to get as much performance as they possibly can). Maybe WebCore as well; I imagine there must be a lot of low-level trickery there.

[Catfish_Man]

Originally posted by Millennium:
For the most part, Safari would not gain any advantage from a 64-bit processor.

However, it actually matters surprisingly little. Most apps currently on OSX should run fine on a 64-bit PowerPC chip without even a recompile.

The only apps which might run into problems are those which have to work on a very low level. Disk-repair apps, perhaps (which have to use low-level routines to do their stuff), or QuickTime codecs (which use low-level routines to get as much performance as they possibly can). Maybe WebCore as well; I imagine there must be a lot of low-level trickery there.

Maybe WebCoreBridge (or whatever it's called). WebCore itself is mostly still the same as the KDE version, which obviously can't rely on a lot of OSX or PowerPC specific stuff. I think KDE also runs on 64 bit systems just fine, so WebCore shouldn't have any trouble with it.

[moki]

Originally posted by moonmonkey:
Will 64 bit ready software run faster than 32bit software on a 64 bit system?

No. In fact, most software will run slower and use more memory.

Only a very few applications will benefit from the transition to 64 bits.

[Stratus Fear]

Originally posted by Arkham_c:
Not entirely true. What you describe is an artifact of "64-bit addressing", meaning that memory addresses are stored as 64-bit values rather than 32-bit values.

Historically, 64-bit computing refers to 64-bit general-purpose registers. Most common CPUs have are 32-bit registers. Using 64 bits means that you can theoretically house and process bigger chunks of data at a time. However, this requires the compiler to organize data in this fashion in the apps.

It's actually a complex question. 64 bit machines can sometimes be slower than 32-bit since it does more work and moves more bits at a time.

64-bit computing also allows for higher precision.

[michaelb]

For a lightweight introduction to the software benefits of 64-bit computing, there's a currently showing video at CNet's news.com of a Microsoft 64-bit presentation.

Geeky presenter, but it does give a glimpse of what sort of apps will be improved.

8 GB image scrolling and faster Maya rendering are the examples shown.

[Guy Incognito 2]

Originally posted by Webscreamer:
Getting ideas is like shaving: if you don't do it every day, you're a bum.

Your signature is a little weird, buddy. What does 'not getting ideas' have anything to do with 'being a bum'?

[moonmonkey]

Originally posted by Guy Incognito 2:
Your signature is a little weird, buddy. What does 'not getting ideas' have anything to do with 'being a bum'?

And his grammer leaves much to be desired.

Although I think he trying to inspire people, I really don't think he is talking about you specifically.

[Graymalkin]

Having a "64-bit" processor means that the general purpose registers (GPRs) are 64 bits wide. This means the native word size of the processor is 64 bits wide. The native word size of the G4 is 32 bits because that is the width of the GPRs.

What does 64 bit wide GPRs get you?

As already mentioned it grants the ability to work with a flat memory space of 2^64 bytes. Work out that number and it ends up being quite enormous. On a 32-bit chip the maximum amount of memory you can address directly is 4GB (2^32 bytes). Intel has fudged their Xeon processors a bit to allow 36-bit memory addressing (64GB 2^36) but typically 4GB is the limit of a 32-bit processor. Four gigabytes of memory may sound like a lot of memory for a single computer but it is not difficult to fathom databases requiring this much if not even more space to live comfortably. Video, either compressed or uncompressed can easily fill up as many GB of RAM as you have to throw at it. Large flat memory spaces also allow you to connect several individual systems with their own installed memory to run under a single kernel/OS image. A bunch of nodes (say XServes) in a cluster that could pool each individual system's RAM and run symmetrically. Large memory spaces are needed so a single process distributed over several processors can address and access the collective (4GB per XServe * 16 XServes = 64GB of addressible RAM) RAM pool.

A less dramatic bonus is the ability of a 64-bit processor to do arithmatic on long long integers in a single pass through the integer pipeline. While most code in existance will not see any benefit from 64 bit wide GPRs the code that DOES see a performance improvement is important. Cryptographic ciphers like larger registers because operations can be done on larger data chunks at a time on the ALU. This means you can write a cipher and get a speed increase without optimizing to a specific architecture, i.e. writing an SSE2 optimized version of your cipher. The same goes for media encoders. Greater speed on long long integer operations could allow portable code to see a performance increase without architecture specific optimizations.

Safari being 64-bit "clean" however is besides the point. A properly written application in any language ought to be clean with regards to the bitness of the target architecture. If you're expecting an arithmatic to have a resolution of only 32 bits you better not be assuming a C int is going to be 32 bits wide. You can refer to a system's types.h file and use #ifdef's to make sure your code will work correctly no matter how many bits a processor's GPRs have. In Objective-C like in Java, you should be letting the system do the memory footwork for you instead of doing funktacular pointer arithmatic. Playing with memory was fine on Commodore 64s and old Amigas but on any modern system you're asking for trouble.

Unless there's something really weird happening in WebCore there probably isn't a single aspect of Safari that would even care about the width of a host system's GPRs. If you were talking Quicktime frameworks or maybe certain aspects of IOKit there might be a question but not so for out friend Safari. As long as you has all the required libraries compiled on a system Safari would likely compile to any architecture with an MMU you had lying around without so much as a line change in its source.