64-bit Discussion [split]

[Rincewind42]

Other than Apple, I wonder if Maya will go 64-bit? Wouldn't it benefit from it?
-Chase

The renderer might go 64-bit, but the application that you typically use won't. You see, only a very few systems have 64-bit frameworks available, and neither Carbon nor Cocoa are included in that list. Right now, the only things you will likely see go 64-bit are renderers, databases, and other applications that store, provide or generate large data sets.

 

[AidenShaw]

Photoshop without scratch files !!

Other than Apple, I wonder....

Photoshop might be a candidate - it would only need to go to scratch files on disk after you've used up *all* of the 8 GiB/16 GiB or whatever you have.

It might even be fairly easy to do even within the carbon/cocoa 32-bit restrictions. Make a 64-bit "buffer manager" for the workfiles, so that the data is copied to/from the 32-bit workspace into a 64-bit "RAMdisk" that avoids going to real disk until *all* memory is used up. The main part of Photoshop could stay 32-bit (assuming that hybrid apps are possible).

As for 64-bit developer stuff, the work I do has been using the 64-bit math available in the G5 since it came out. I know that really has nothing to do with Tiger, but it's far more useful in my realm of development than getting 64-bit addressing.

Just curious - can you tell us what you're doing that depends on high-performance 64-bit integers?

Since compilers can emulate 64-bit integer math on 32-bit CPUs, for most applications which use the occasional 64-bit integer for a file offset there isn't a critical dependence on hardware 64-bit integers.

 

[Rincewind42]

Photoshop might be a candidate - it would only need to go to scratch files on disk after you've used up *all* of the 8 GiB/16 GiB or whatever you have.

Yea, but then Adobe would have to change the structure of their entire app -- they've been fighting VM since it was first introduced in desktops (due to essentially having their own VM).

It might even be fairly easy to do even within the carbon/cocoa 32-bit restrictions. Make a 64-bit "buffer manager" for the workfiles, so that the data is copied to/from the 32-bit workspace into a 64-bit "RAMdisk" that avoids going to real disk until *all* memory is used up. The main part of Photoshop could stay 32-bit (assuming that hybrid apps are possible).

The buffer manager would need to be a separate application. Then you have the windowing problem -- the need to look at an image larger than 4GB from the 32-bit side. Not a huge problem by any means, but certainly a performance drainer.

Just curious - can you tell us what you're doing that depends on high-performance 64-bit integers?

Since compilers can emulate 64-bit integer math on 32-bit CPUs, for most applications which use the occasional 64-bit integer for a file offset there isn't a critical dependence on hardware 64-bit integers.

There are tons of applications that could use faster 64-bit integers -- cryptography, scientific data analysis, networking (think IPv6 handling), and many more. Many of the applications that benefit actually deal in integers even larger than 64-bits (cryptography often deals in ?128 bits) and can definitely use the reduction of operations by half or more.

Just as food for thought, there are more than 10^23 atoms within a 10 cm radius of your body right now. Imagine if you wanted to do a scientific analysis of how each of those atoms interacts with your skin. Your way past 32-bit integers right there.

 

[AidenShaw]

The buffer manager would need to be a separate application. Then you have the windowing problem -- the need to look at an image larger than 4GB from the 32-bit side. Not a huge problem by any means, but certainly a performance drainer.

The point is that Adobe already has a solution for the windowing problem - scratch files. Putting a multi-GiB (64-bit aware) buffer between the main Photoshop engine and the scratch file might eliminate a lot of disk activity.

It wouldn't be as efficient as true 64-bit VM, but it might be ready sooner and it would be a big improvement from the current scratch files for those with lots of RAM.

There are tons of applications that could use faster 64-bit integers -- cryptography, scientific data analysis, networking (think IPv6 handling), and many more

I was hoping for a specific example of why *you* are using 64-bit integers, not some generic examples and guesses. (and 2^64 is about 10^19, so the atoms still fall short )

I don't consider IPv6 a particularly "important" case - considering the latencies involved in building and transmitting (or receiving and decoding) a network packet - saving a couple of instructions when looking at the IP address is inconsequential. Besides that, most systems are pretty good at dealing with character strings - and an IPv6 address is just an 8 byte string.

Similarly, every time you touch a file (on a filesystem that supports files bigger than 4 GiB) you need to use 64-bit integer arithmetic. There's so much other stuff going on with file access, however, that using hardware 64-bit integer arithmetic isn't going to make a noticeable improvement.

 

[Rincewind42]

The point is that Adobe already has a solution for the windowing problem - scratch files. Putting a multi-GiB (64-bit aware) buffer between the main Photoshop engine and the scratch file might eliminate a lot of disk activity.

It wouldn't be as efficient as true 64-bit VM, but it might be ready sooner and it would be a big improvement from the current scratch files for those with lots of RAM.

As I said, it isn't a big issue. However, you already have a buffer that can eliminate the disk activity -- the Unified Buffer Cache that is a part of OS X. If a manual VM system ala Photoshop's would keep it in memory, then it is likely that the system's UBC would also, and as part of the kernel the UBC can be even more efficient -- by allowing multiple processes to use that data transparently. Nothing that Adobe would do manually could do that (because the other applications would need to know about their buffer, whereas all applications automatically know about the UBC). So Adobe's VM system probably won't see a significant gain from 64-bit memory spaces. (Caveat: obviously Adobe can do things that can improve the performance of their caching system that the general VM system cannot, but almost anything they do that saves disk accesses would fight with the rest of the system and affect overall system performance, most likely negatively.)

I was hoping for a specific example of why *you* are using 64-bit integers, not some generic examples and guesses. (and 2^64 is about 10^19, so the atoms still fall short )

Your right, my example there fell a bit short. But at least you can get closer to modeling each one individually . But then, I wasn't the OP with examples, so I just came up with stuff that I knew

 

[mkramer]

Just curious - can you tell us what you're doing that depends on high-performance 64-bit integers?

Since compilers can emulate 64-bit integer math on 32-bit CPUs, for most applications which use the occasional 64-bit integer for a file offset there isn't a critical dependence on hardware 64-bit integers.

I evaluate theoretical microprocessors designs, writing tools like emulators and compilers for some pretty unique looking devices. So i'm using 64-bit math to emulate 48- and 64-bit DSP and dataflow architectures.

But for people not in such a niche field, the ability for the G5 to do 64-bit logical operations shouldn't be overlooked. Sure, very few people deal with numerical values greater than 32-bits. But there are innumerable uses for large bitfields in applications. Things like lookup tables, state tables, trackers, masks (although those are usually more of a candidate for Altivec), etc..

 

[AidenShaw]

Thanks for the use case for 64-bit integers - sounds like fun coding...

Things like lookup tables, state tables, trackers, masks (although those are usually more of a candidate for Altivec), etc..

Or the 128-bit logical instructions in SSE...

 

[daveL]

Thanks for the use case for 64-bit integers - sounds like fun coding...




Or the 128-bit logical instructions in SSE...

Or the 128-bit logical instructions in Altivec ...

 

[gekko513]

Thanks for the use case for 64-bit integers - sounds like fun coding...

Or the 128-bit logical instructions in SSE...

The 128-bit logical SSE(2) instructions only include left shift and right shift by steps of 8 which can make them useless for some applications. Like shift registers in cryptography for instance.

 

[AidenShaw]

The 128-bit logical SSE(2) instructions only include left shift and right shift by steps of 8 which can make them useless for some applications. Like shift registers in cryptography for instance.

Yes, and the fact that Altivec has no support for double precision floating point means that many scientific codes cannot benefit from its improved performance. (But, SSE(*) does support 64-bit floating vectors...)
__________________________


The real point is that PPC970 and x64 chips are much more alike than different - the main difference is that anyone can download Linux for x64 or the XP/2k3 previews for x64 and run 64-bit today.

64-bit for OS X will be first available to the "masses" sometime next year (and apparently OS X will have significant 32-bit frameworks limitations).

Not necessarily bad news, but don't let the "64-bit myth" overtake reality....

 

[daveL]

The 128-bit logical SSE(2) instructions only include left shift and right shift by steps of 8 which can make them useless for some applications. Like shift registers in cryptography for instance.

I might add that the Altivec 128-bit logical instructions don't have these limitation.

Is it me, or does AidenShaw, under the pretense of offering objective opinions on Mac vs Wintel hardware architecture, actively disseminates FUD for the Wintel camp? Anyone who has any appreciation for dsp extensions to processor instruction sets knows that Altivec, under its many monikers, has lead the Intel attempt at the same functionality and performance for years. That's exactly why Intel has made half-a-dozen half-baked attempts to provide equivalent functionality and performance. It also explains why PPC, at lower clock rates, exceed the performance of the Intel platform, at higher clock rates, for signal processing and HPC workloads. Not to mention Intel has burdened their developers with a myriad of extension flavors. I guess they can't get it right the first time, or the second, or the third ...

BTW AidenShaw, where's that request for a URL to the download for a 64-bit released version Windows XP. You've apparently dropped the ball (a couple days ago, by anther poster)?

So, I guess we'll get back to your pedantic arguments about 64-bit computing, as you see it (which is pretty dim from my perspective). Do you actually write code, AidenShaw, or do you just bless us with your pontification?

 

[daveL]

Man , it's been more than 5 minutes and AidenShaw hasn't dumped a new load! What's up AidenShaw? Speechless? I can't imagine that! (Sorry for the multiple posts).

 

[AidenShaw]

BTW AidenShaw, where's that request for a URL to the download for a 64-bit released version Windows XP. You've apparently dropped the ball (a couple days ago, by anther poster)?

It's the same URL as the released versions of OS X for any version - it doesn't exist - the release versions are purchased!

The earlier post was very carefully worded to say "buy x64".

That ignores the fact that 64-bit Windows has been shipping for years on Itanium - not downloadable (unless you're an MSDN member), but available for purchase. You can *buy* 64-bit Windows today.

That ignores the fact that 64-bit Windows has been freely downloadable for Opteron/Athlon 64 for a long time, and was quickly updated to include support for the Intel "EM64T" version of the x64 extensions.

In spite of the fact that few people need or will benefit from 64-bit, Apple is way behind in the 64-bit realm (in spite of the ludicrous "first 64-bit desktop" ads), and in Tiger will be shipping a botched 64-bit attempt (Carbon/Cocoa/frameworks are 32-bit only ??????? ????????? ????????? ?????????? ???????? ????? - are you kidding?).

Why is it FUD to see the world without Cupertino's rose-coloured glasses?

 

[Rincewind42]

Yes, and the fact that Altivec has no support for double precision floating point means that many scientific codes cannot benefit from its improved performance. (But, SSE(*) does support 64-bit floating vectors...)

Correct me if I'm wrong, but the last time I heard about SSE and dealing with 128-bit vectors, it implemented the functionality by processing the two 64-bit vector halves in serial. So this would mean that even though SSE can handle 2 doubles in one instruction, it still works as if your only processing one of them per cycle.

 

[AidenShaw]

Man , it's been more than 5 minutes and AidenShaw hasn't dumped a new load! What's up AidenShaw? Speechless? I can't imagine that! (Sorry for the multiple posts).

Sorry, took me 14 minutes - I had to baste the rack of lamb for tonight's dinner party.

Help me - I can't decide between a 2001 Australian Shiraz and and an Alexander Valley Merlot for the wine - what would you suggest?

 

[AidenShaw]

...it still works as if your only processing one of them per cycle.

It's "you're", not "your".

On a super-scalar chip processing billions of instructions per second - "one per cycle" is a third of a billionth of a second.

While your "microscopic" analysis of the problem may be superficially right, when systems with super-scalar super-pipelined OOOE engines actually process the data the real-world results can be quite at odds with the arm-chair analysis.

 

[Rincewind42]

Apple is way behind in the 64-bit realm (in spite of the ludicrous "first 64-bit desktop" ads), and in Tiger will be shipping a botched 64-bit attempt (Carbon/Cocoa/frameworks are 32-bit only - are you kidding?).

Are you kidding me??? You do have some semblance of an idea how complicated it would be to port and test ALL THAT CODE to make sure that it works properly in a 64-bit address space?. Not to mention that it would quite literally DOUBLE the code size of the OS. And finally how FEW GUI apps would actually need to deal with more than 4GB of RAM directly. Really, the fact that Tiger has any 64-bit application support only a year and a half after Panther is amazing.

Sure, they could have done it. But then there wouldn't be Spotlight, updated Mail, or new features of any kind. Apple would have spent the entire time revising and verifying the new APIs that they created. Personally, I would rather limited 64-bit support and loads of new/useful stuff than full 64-bit and nothing "new". And without new/useful stuff, no one else will buy Tiger over Panther either.

 

[AidenShaw]

Are you kidding me??? You do have some semblance of an idea how complicated it would be to port and test ALL THAT CODE to make sure that it works properly in a 64-bit address space?.

Linux and Windows did it....

'nuf said.

 

[Rincewind42]

It's "you're", not "your".

Bored much?

On a super-scalar chip processing billions of instructions per second - "one per cycle" is a third of a billionth of a second.

While your "microscopic" analysis of the problem may be superficially right, when systems with super-scalar super-pipelined OOOE engines actually process the data the real-world results can be quite at odds with the arm-chair analysis.

I am quite aware of what I'm talking about here. The fact that only one double per cycle comes out the other end effectively means that SSE is no better than the floating point unit in a G4, which can also put out one double per cycle. And it puts it at half the throughput of a G5 which can put out two doubles per cycle. Granted you have to tune towards this being possible, but if it is important to you you will do it and you will see the difference.

Pretty simply put, if I can process 2 doubles per cycle at 1.6 billion cycles per second, vs 1 double per cycle at 3 billion cycles per second then I'm doing 3.2 billion doubles per second in the former and 3 billion doubles in the latter example. I would say that 1 vs 2 at once is pretty damn significant.

The post I commented on implied that SSE was superior to Altivec because it can process doubles and Altivec cannot. But if SSE requires two passes to process them then it is no better than the FPU on a PPC chip at processing doubles, so you really aren't at any loss using the PPC FPU vs using SSE, and even less so if your on a G5 at 2.5 Ghz and it's dual FPUs.

Finally, to put this all to rest, if your doing some really serious floating point computation, Apple presented an Octuple precision (256-bit) Altivec floating point implementation geared towards performance. That's 32-bit exponent and 224-bit mantissa. Read more here. Somehow I not thinking that Altivec not being able to handle doubles is significant.

 

[maxvamp]

Not quite

Linux and Windows did it....

'nuf said.

There is not a single version of 64-bit windows that runs a decent number windows apps, either with performance, or at all. The stuff run on the iTanic is mostly 64 bit, and compiled specifically for the iTanic.

The 64-bit x86 version should run more than 90% of today's apps, but it has not been released yet. Linux has done a good job moving to the new platform, but Linux is highly portable at any rate.

I would like to clarify for those not in the know that the Itanium ( Itanic ) is not an Intel x86 compatible chip. It is a totally unique processor as different as the PowerPC from the x86 processors of today. It only plays nicely with some of today's intel apps because it emulates an x86 processor. Imagine VirtualPC on a chip.

Long and short... When people claim 64 bit windows is out today, they are being **VERY** misleading. They might as well be saying that Windows - 64 is out because there is a port out for the 970. This means little to nothing to 95% of the people that use a PC. A 64-bit version of windows for AMD64 ( AME-64 ) means a lot more because that is a more natural upgrade path to those currently with PCs.

Windows 64 has a lot of testing to go before they can release it and be comfortable that it can run most windows apps. Even then, any old 16 bit Win3.1 apps may not run.

Max.

 

[daveL]

It's the same URL as the released versions of OS X for any version - it doesn't exist - the release versions are purchased!

The earlier post was very carefully worded to say "buy x64".

That ignores the fact that 64-bit Windows has been shipping for years on Itanium - not downloadable (unless you're an MSDN member), but available for purchase. You can *buy* 64-bit Windows today.

That ignores the fact that 64-bit Windows has been freely downloadable for Opteron/Athlon 64 for a long time, and was quickly updated to include support for the Intel "EM64T" version of the x64 extensions.

In spite of the fact that few people need or will benefit from 64-bit, Apple is way behind in the 64-bit realm (in spite of the ludicrous "first 64-bit desktop" ads), and in Tiger will be shipping a botched 64-bit attempt (Carbon/Cocoa/frameworks are 32-bit only ??????? ????????? ????????? ?????????? ???????? ????? - are you kidding?).

Why is it FUD to see the world without Cupertino's rose-coloured glasses?

Like Itanium matters. Oh no, AidenShaw is going to tell me that I don't know squat about Itanium or I'm just generally myopic!

As you dance around, trying to defend your extremely lame position, knowing full well we are talking about a 64-bit Wintel platform, NOT Itanium, where is it? Where can I buy it for delivery *today*?

<supply music for next AidenShaw verbal dance>

Go AidenShaw ...........

 

[daveL]

Sorry, took me 14 minutes - I had to baste the rack of lamb for tonight's dinner party.

Help me - I can't decide between a 2001 Australian Shiraz and and an Alexander Valley Merlot for the wine - what would you suggest?

I prefer the Shiraz, actually. Lamb can be very gamey and needs a stout red, I think.

 

[AidenShaw]

I prefer the Shiraz, actually. Lamb can be very gamey and needs a stout red, I think.

Sounds pretty good - I'll start with that, and keep a Mendicino Cabernet in reserve along with the Merlot....

The rest of you - crazy talk.

"a 64-bit Wintel platform, NOT Itanium" - are you on drugs, man? An Itanium running Windows isn't 64-bit Wintel? Are you crazy?

"The 64-bit x86 version should run more than 90% of today's apps, but it has not been released yet." - are you on even better drugs? It's not released, but it's based on the 64-bit IA64 code that's been shipping for years, and any one with an email address can download and install it.

Where do I download 64-bit Mac OS X ??????? Nowhere, right?

 

[melgross]

Getting out of hand guys

Merlot if your guests have an unsophisticated palate, a Shiraz if they could use a bit more "bite". I don't find that cut to be gamey at all. It's not as though you are roasting a hind leg, after all. The Cab is a bit rich, but would go better if it doesn't follow a Shiraz. You need a contrast. The Merlot before the lamb, the Cab with the lamb.

My favorite, Fonseca '85 to finish it all off. (sob, only three bottles left! It has been a good 18 years).

By the way, Windows 64 for the x86 isn't any more 64 bit than Tiger will be, possibly even less so. We'll find out when Tiger is here.

 

[daveL]

Sounds pretty good - I'll start with that, and keep a Mendicino Cabernet in reserve along with the Merlot....

The rest of you - crazy talk.

"a 64-bit Wintel platform, NOT Itanium" - are you on drugs, man? An Itanium running Windows isn't 64-bit Wintel? Are you crazy?

"The 64-bit x86 version should run more than 90% of today's apps, but it has not been released yet." - are you on even better drugs? It's not released, but it's based on the 64-bit IA64 code that's been shipping for years, and any one with an email address can download and install it.

Where do I download 64-bit Mac OS X ??????? Nowhere, right?

I'm still looking for the IA64 Windows XP release you continue to put forward a Windows OS release ahead of Mac OS X Tiger, because that's what you've been communicating in your posts.

You also haven't answered my question as to whether you actually write code but, no matter, I wouldn't believe you, regardless of what you say.

Thirdly, you've given no response to the delta between Altivec and SSE, as mentioned above concerning 128-bit logical operations. You make assertions, people counter with facts, and you just move on to your next unsupported rant. Dennis Miller with no conscious.

This all reminds me of a sit-com promo I saw the other night where a husband is trying to "command" his wife, she laughs at him, he smiles and says: "I feel like I ran out of bullets and just threw the gun at you!" I'm sure I didn't get it right, but close enough.

Desperate posts to support desperate opinions. In short: Whatever AidenShaw ( blah, blah, blah or let's have more pedantic AidenShaw 64-bit drivel ).