64-bit Discussion [split]

[maxvamp]

On the 64-bitness....

Those who need it, know why, and how to use it... those who don't know how, or why, at least still get to keep some bragging rights. ( Think WindowsXP 64-Bit )

BTW: Panther has some 64-bitness to it... those in the know, know how to use it .

Second...

I would be curious to hear from those with the Tiger preview if DVD+RW disks are finally handled the way the format was intended ( i.e. Floppy/hard disk like ) .

Max.

[AidenShaw]

...at least still get to keep some bragging rights. ( Think WindowsXP 64-Bit )

What will the brag be? "Now OS X has 64-bit - 2 years after XP?"

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prka_fea_ejfy.asp


And Panther doesn't allow anyone to use more than a 32-bit virtual address space, so what "some 64-bitness" are you referring to? Spell it out, don't spread mis-information.

[maxvamp]

What will the brag be? "Now OS X has 64-bit - 2 years after XP?"


The first generally accepted WindowsXP for the consumer/prosumer will be for the AMD64 platform. The Itanic has generally been a flop and was never meant for the consumer. Furthermore, no serious software company has plans to put much money in developing for the platform, yet many are working towards the release of Windows on the AMD platform.

The bragging rights will be that 'I have a 64-bit OS and Processor' . It doesn't matter whether it is Mac or PC, or if the advanced functionality is even ever used. That is the general comment that will be made.

Oddly enough, I am running a pre-released version of both XP and 2k3 ( for testing purposes ) on an AMD. Not faster in most tasks, and a little slower in others.

As far as 64-bitness goes, there are some G5 specific tweaks that are specific for 64-bit operations already out there. Panther has math libraries that take advantage of the new proc, and Tiger is supposed to expand on 64 bit capability. I do not know if Tiger will remove the limited process space that an application can use. I suspect that this too will be 'tweaked'.

Hence : Those in the know.... Think the scientific community.

Hope this helps....

Max.

[AidenShaw]

Panther has math libraries that take advantage of the new proc...

Your claim is misleading.

Current systems support 64-bit hardware floating point math on 32-bit operating systems, yet nobody claims that the FP register makes it a 64-bit *system*.

Why should the option to do 64-bit hardware integer math be any different?

A "64-bit system" is one that delivers a 64-bit flat virtual address space to applications. Panther does not, Panther is 32-bit.

Windows 64-bit Workstation and 64-bit Server operating systems are shipping today, your wiggle-words about "consumer" are just as silly as Apple's claim that the G5 was the first 64-bit desktop.

[Rincewind42]

Your claim is misleading.

Current systems support 64-bit hardware floating point math on 32-bit operating systems, yet nobody claims that the FP register makes it a 64-bit *system*.

Why should the option to do 64-bit hardware integer math be any different?

Your right, Panther is not a 64-bit user-OS. The virtual memory system/kernal is 64-bits by necessity, but that ends up not meaning a whole heck of a lot to users.

A "64-bit system" is one that delivers a 64-bit flat virtual address space to applications. Panther does not, Panther is 32-bit.

Tiger will allow for 64-bit virtual address spaces, but since most frameworks are not 64-bit, it means that generally you have to communicate with a 64-bit background app from 32-bit application space. Presumably this will change in the future, but I doubt that anyone outside of Apple has any clue when that will be (in fact, I doubt that few inside Apple know either).

Windows 64-bit Workstation and 64-bit Server operating systems are shipping today, your wiggle-words about "consumer" are just as silly as Apple's claim that the G5 was the first 64-bit desktop.

Yea, but everyone in the industry has wiggle-words that they use, so in that respect Apple is no different :p

[maxvamp]

So... Aiden...

Windows 64-bit Workstation and 64-bit Server operating systems are shipping today, your wiggle-words about "consumer" are just as silly as Apple's claim that the G5 was the first 64-bit desktop.

I have an AMD-64, the most popular ( by sheer sales numbers ) 64-bit Windows processor out there. I would like a copy of windows 2k3 for my server. Please tell me, or provide a link to a place where I can buy a copy today. I might also want a few WindowsXP clients for this processor. After all, it also make a very nice workstation machine. Where might I be able to buy a few copies of WindowsXP - 64.

I would like to buy today. I called Microsoft, and they have told me that this creature has yet to be released. What do they know... they are only the authors of the OS....

BTW: BTW: Panther has some 64-bitness to it... those in the know, know how to use it .

This was my original quote. Panther has Frameworks that reduce the number of cycles needed to calculate 64 bit integer numbers on a G5. This does not use a FP Proc. Hence... Panther has some 64-bitness to it ( never said that Panther was a 64-bit system in my original post).

Aiden, stop trying to **pick** a fight. Itanic is dead, AMDx86-64 is the future for most Intel installations...

Mac OSX has some ( Although not a lot ) 64-bit functionality , and will gain more in the future. In my mind this does not allow OSX to be classified as a pure 32-bit OS. People will tend to want to claim they have a 64-bit OS, and those who need a specific 64-bit feature that OSX does, or will provide will buy the OS. If they need a 64 bit attribute that the OS does not have, they will buy a Sun, HP, or even Intel. Hence... Those in the know......

Max.

P.S. I await the link to run Win-64 on my AMD servers...

Max.

[maxvamp]

My original post here was not intended to get into a p**sing contest over 64-bits. Aiden and I have been down that path before....

What I want to know is if the media handling of DVD '+' have been improved in Tiger...

We can debate this topic if you like... I know the formats very well, just not the new OS...

Max.

[AidenShaw]

Your right, Panther is not a 64-bit user-OS. The virtual memory system/kernal is 64-bits by necessity, but that ends up not meaning a whole heck of a lot to users.

The Pathner virtual memory system is 32-bits as seen by the applications.

It is not a "necessity" to use 64-bits to support more than 4 GiB of RAM. The kernel memory management system can keep track of pages by the page number, and a 32-bit page number for 4 KiB pages can manage up to 16 TiB of RAM.

Windows and Linux on 32-bit Xeons support up to 64 GiB of RAM on a 32-bit processor with a 32-bit operating system. (Like the G4, the Pentium/Xeon support 36-bit physical addressing on the 32-bit chip.)
________________


If anyone thinks that Itanium (no need to use childish insulting names) is dead, they should look at the top systems in both the Top500 Supercomputer list and in business applications like TPC.

When the latest 64-bit wart on the x86 instruction set runs out of steam, Intel has a clean architecture ready to move into the desktop space....

[reckless_0001]

Why don't y'all make a 64bit Processing thread and talk about it there or start talking about various Tiger features/improvements. :p

[johnnyjibbs]

Arrrggghh....! Why does every one of these threads always end up being about whether it is a true 64 bit OS or not?

"yes it is"
"actually, no it's not"
"Panther isn't but Tiger is"
"Actually neither can address 64 bit instructions but Windows XP 64 bit can"

Arrrggghhh...!! :mad:

[/rant]

Sorry.. had to be done.

[AidenShaw]

Arrrggghh....! Why does every one of these threads always end up being about whether it is a true 64 bit OS or not?


Because the "64-bit myth" is even bigger than the "MHz myth" ??? :rolleyes:

[Punani]

Well then, let's discuss Mac OS X 10.12 with a G11 and 128-bit extensions! :p

[reckless_0001]

Well then, let's discuss Mac OS X 10.12 with a G11 and 128-bit extensions! :p

Sounds good to me :o

[Rincewind42]

The Panther virtual memory system is 32-bits as seen by the applications.

It is not a "necessity" to use 64-bits to support more than 4 GiB of RAM. The kernel memory management system can keep track of pages by the page number, and a 32-bit page number for 4 KiB pages can manage up to 16 TiB of RAM.

Windows and Linux on 32-bit Xeons support up to 64 GiB of RAM on a 32-bit processor with a 32-bit operating system. (Like the G4, the Pentium/Xeon support 36-bit physical addressing on the 32-bit chip.)

This isn't idle speculation on my part. This is information from engineers -- the kernel uses a 64-bit address space for memory. It's more than just the VM system and main memory, it's also IO devices such as PCI and FW. Many of these devices are not page addressable (at least not the same as the memory system), so you have to keep track of memory at a space more fine grained than pages.

[reckless_0001]

Is there another forum thread that is "hot" on the topic of Tiger or is this site just losing interest?

[abhishekit]

Your claim is misleading.

Current systems support 64-bit hardware floating point math on 32-bit operating systems, yet nobody claims that the FP register makes it a 64-bit *system*.

Why should the option to do 64-bit hardware integer math be any different?


They are different because only integer registers can store pointers(for memory addressing) , floating point registers can't.

[maya]

64-bit Development


The 64-bit support in Tiger enables the 64-bit addressing for the next generation of data-intensive applications, such as those working with gene sequencing, advanced medical imaging, and geospatial applications. To give an example of the kinds of data that can be represented with 64 bits, imagine that you are working with a dataset in which the road area of the Golden Gate bridge can be represented in 32 bits. Sixty-four bits of address space gives you the capacity to model the entire surface area of the earth at the same resolution. In addition, LibSystem and many*of Apple's optimized math libraries will*support 64-bit addressing in Tiger, making it easy for developers to harness the full computational power of the PowerPC G5 as well as very large amounts of memory. As you probably know, at the heart of the Power Mac G5 and the new iMac G5 is the PowerPC G5 processor, a fully capable 64-bit processor. It sports 64-bit registers, can perform 64-bit arithmetic operations, and can give the operating system access to greater than 4GB of main memory. In fact, it gives you access to 16 exabytes of virtual memory, and as much physical memory as you can put in your Mac.


Unlike some other CPU architectures, there is no performance penalty for running 32-bit applications on the G5. This is because the PowerPC architecture has always been defined as a 64-bit architecture with a 32-bit subset, allowing a seamless migration between 32-bit and 64-bit hardware. Even better, 32-bit applications can take advantage of many 64-bit features, such as 64-bit math and registers. This has allowed Apple to make a smooth transition between architectures. For example, there is only one version of the kernel for all Apple hardware.


Mac*OS*X Tiger's 64-bit support opens the door to the next level of applications—the ones that couldn't be built until now.

[maxvamp]

Why don't y'all make a 64bit Processing thread and talk about it there or start talking about various Tiger features/improvements

Excellent idea...

I think the reason this 64 bit thing keeps getting pulled in is due to the fact that Tiger will reportedly be 64 bit when running on a 970. Things get mixed up and confused, and then very tense over this topic. The reality is that those who need the extra power will by a 970 with Tiger. Those who just want this setup, won't care why or if they need it, they will buy it anyhow. Apple won't care either way so long as they get paid.

It is all kind of buying a corvette just to drive to work everyday. A Toyota would probably be a better fit for this use, but the purchaser won't care ( until they hit the gas pump ).

Max.

[~Shard~]

64-bit Development

<snip>

Mac*OS*X Tiger's 64-bit support opens the door to the next level of
applications—the ones that couldn't be built until now.

It would have been easier just to link to the source (http://developer.apple.com/macosx/tiger/) instead of cutting and pasting the entire document. :p ;) Plus, I believe most people here have already read the actual documentation on Apple's website, nothing really new there. And on top of that, since it's Apple's site, you know they've probably applied that "Marketing slant" to things as well to a slight degree at least - it's not like the info is taken straight from an Engineering manual or something.

[AidenShaw]

They are different because only integer registers can store pointers(for memory addressing) , floating point registers can't.

Yes, but Panther's able to do integer arithmetic using 64-bits, but it isn't using 64-bits for addresses.

My point is that virtually everyone will call a system with 32-bit addressing a 32-bit system, even if it does 64-bit floating point math. Adding 64-bit integer math while still using 32-bit addressing doesn't change anything - it's still a 32-bit system.

While Panther may be using limited 64-bit in the kernel, it isn't strictly necessary to do so. The earlier post said "by necessity", which isn't true.

Windows and Linux on x86 support 64 GiB of RAM and 64-bit PCI address space (obvious, if you're going to do I/O to more than 4 GiB of RAM) using only 32-bit addressing. It is not a necessity to have 64-bit addressing - you can set up the mapping between memory and addressing using 32-bit operations.

[AidenShaw]

Things get mixed up and confused, and then very tense over this topic. The reality is that those who need the extra power will by a 970 with Tiger. Those who just want this setup, won't care why or if they need it, they will buy it anyhow. Apple won't care either way so long as they get paid.


And, like commuting with the Corvette, 64-bit won't be doing anything for you if you have 4 GiB or less of RAM. That's a factor in the "need a 64-bit laptop" debates - without the big RAM *and* an application that needs more than 4 GiB of RAM, you really don't need 64-bit.

[maya]

It would have been easier just to link to the source (http://developer.apple.com/macosx/tiger/) instead of cutting and pasting the entire document. :p ;) Plus, I believe most people here have already read the actual documentation on Apple's website, nothing really new there. And on top of that, since it's Apple's site, you know they've probably applied that "Marketing slant" to things as well to a slight degree at least - it's not like the info is taken straight from an Engineering manual or something.

That is true Shard, I could have just placed a link. However when with the information ready people have been saying well I didn't know it was there or is it really a. :)

So its better then to open another tab or window in Safari. :)

"marketing slant" maybe, maybe not. Apple has a reputation and when Steve said listen no 3.0GHz this summer I am sure that was hard on his reputation however people passed it off since everyone has the same problem.

The "worlds fastest computer" well that all depends it never stated forever, it could have been for an second, minute, hour, day a week, maybe even a month. The fastest computer was to draw attention and nothing more. Did Apple have to remove it yes.

I do no think Apple and Steve .J are going to make "promises" and then say oh well that was for marketing can you imagine what the developers will think we cannot rely on what Apple says anymore. And considering that there are more developers for the x86 than for Apple PPC desktop I do not think Apple wants to get comfortable in HOT WATER.

Redmond, start your photocopiers, introducing LongHorn, etc....that is marketing.

Anyhow we shall all see when this Cat is out of the bag in 2005, then there will be another argument on MR. Well I told you so blah blah blah. Whatever people if you want to upgrade to Tiger do so otherwise pipe down.

Apple is in the business to compete, do you honestly if they place false information that the media will allow them grace. Apple cannot afford the bad reputation for switcher.

At this point its like debating if Kerry or Bush will do a better job in office.

Get a life, this 64-bit issue is put to rest until we obtain more detailed information about it.

[maya]

Arrrggghh....! Why does every one of these threads always end up being about whether it is a true 64 bit OS or not?

"yes it is"
"actually, no it's not"
"Panther isn't but Tiger is"
"Actually neither can address 64 bit instructions but Windows XP 64 bit can"

Arrrggghhh...!! :mad:

[/rant]

Sorry.. had to be done.

64-bit OS is a very important development its as important to the whole Mac OS experience as CoreImage, CoreData, WebCore.

This is not about aesthetics changes that can and might change when Tiger is released.

This is foundation set for the future development of Mac OS X.

[rendezvouscp]

I wonder how many updates Apple is going to provide to the developers. I really hope they have a lot of momentum behind Tiger. It's looking like a great OS. I'm just concerned that it'll become too bloated with things. Right now, there are way too many GUIs running around, and Apple isn't even following their OS GUI Guidelines sometimes. Please keep the simplicity Apple!
-Chase

[rendezvouscp]

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

[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]

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 :D

[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 (http://www.cpuid.com/sse/ANDPS.htm) instructions in SSE...

[daveL]

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




Or the 128-bit logical (http://www.cpuid.com/sse/ANDPS.htm) 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 (http://www.cpuid.com/sse/ANDPS.htm) 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 (http://www.apple.com/acg/pdf/oct3a.pdf). Somehow I not thinking that Altivec not being able to handle doubles is significant.

[maxvamp]

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]

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 ).

[gekko513]

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.
That's correct. My understanding is also that when SSE instructions are executed they block execution of normal floating point instructions, so theoretically you only save on the number of instructions you use, which can be important, but then again the instructions you use have almost twice as long opcodes (normal float FADD is "DC /0" while SSE float ADDPD is "66 0F 58 /r" so you gain nothing. I don't have any numbers on how this turns out in practice, though.

[AidenShaw]

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.

Info on 64-bit Windows OS right here:

http://www.microsoft.com/windowsserver2003/64bit/default.mspx

IA64 XP was only available on HP's workstations, since HP discontinued those (http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,96160,00.html) there does not appear to be any current way to get IA64 XP except through MSDN, where you can see:

Microsoft has now introduced Windows® XP 64-Bit Edition Version 2003, with support for the Itanium 2 processor, to meet the demands of technical workstation users who require large amounts of memory and floating point performance in areas such as mechanical design and analysis, 3D animation, video editing and composition, and scientific and high-performance computing applications.

The XP 64-bit home page is now focussed on the x64 (AMD64/EM64T) version, the server pages have both IA64 and x64.


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.

bool aiden_codes = true;

I replied to a comment about using AltiVec for wide masks, and pointed out a similar capability in SSE. I didn't intend a tangential debate on VMX vs SSE, so I didn't follow that shift in direction.

Many people here don't realize that Microsoft has been shipping (and yes, selling) 64-bit versions of Windows for over 3 years. 64-bit Linux has been around even longer. They think Apple is leading in the 64-bit evolution, not playing catch-up to everyone else. It seems that some people have learned everything they know about computers from Apple's adverts, and aren't aware of what's really available.

If you think that it's only pedantic drivel, I invite you to skip over my posts. On the other hand, if you want some facts and opinions from a different viewpoint, please read.

[AidenShaw]

That's correct. My understanding is also that when SSE instructions are executed they block execution of normal floating point instructions, so theoretically you only save on the number of instructions you use, which can be important, but then again the instructions you use have almost twice as long opcodes (normal float FADD is "DC /0" while SSE float ADDPD is "66 0F 58 /r" so you gain nothing. I don't have any numbers on how this turns out in practice, though.


Your understanding of the blocked execution is wrong - it was true for MMX, but SSE uses a separate set of registers and can execute SSE *and* (MMX *or* FP) at the same time.

Reference: http://developer.intel.com/technology/itj/q21999/articles/art_2c.htm (page 3, middle)


The longer opcode is a very minor issue. The Pentium 4 instruction decoder converts the x86 instruction stream into uops, and the decoded uops are cached in a special cache. In a loop, you'd only decode once.


The stream does contain two 64-bit uops. The SIMD FP unit can do one 64-bit float or two 32-bit float operations at once - so at the micro-architectural level it does take 2 cycles to start the pair of double float operations (or 2 cycles to start 4 single float ops).

This really isn't part of the SSE architecture, of course. A chip could have a 4-way 32-bit (and 2-way 64-bit) SIMD FP unit for SSE. The Intel engineers had to make tradeoffs as to where to spend the transistor budget - and for overall performance apparently a wider SIMD FP unit didn't make the cut.

If you really need floating performance, Itanium has 4 FP units...

[maxvamp]

64 Bit solaris ( Sparc ) = Released ( years ago )
64 Bit Solaris ( x86-64 ) = Released ( Now )

64 Bit Windows ( Itanium ) = Released ( Years ago )
64 Bit Windows ( x86-64 ) = Beta ( free download )

64 Bit OSX ( PPC ) = Beta ( download though ADC )

The Itanium code is not the same as the x86 code, and is no more or less available than OSX.4. Neither Windows x86-64 nor Tiger are ready to use in real world environments.

Aiden, you bring up Win2k3 for x86-64... I recently installed the latest public build. It is not ready to go.

Point is, when you go on about windows being out for years, this is as misleading as saying that Iraq has weapons of mass destruction. Yes there has been a 64-bit windows out for a long time, but it is as specialized as Solaris. It is not the same code and creature as the version of 64-bit windows people are expecting and will generally get in the popular ( mass ) market.

Max.

[gekko513]

Your understanding of the blocked execution is wrong - it was true for MMX, but SSE uses a separate set of registers and can execute SSE *and* (MMX *or* FP) at the same time.
You're right. So the P4 can theoretically execute 2 double-precision floating point operations per cycle, one SSE and one regular. Which is the same number as the G5 can (2 regular), so the P4 wins in theory when it comes to double-precision flops because it has a higher clock speed.

The only disadvantage for the P4 is that you have to mix SSE and regular float instructions to reach the full potential.

[Rower_CPU]

Try to do a better job staying on topic in the news threads, folks, and take large discussions like this to new threads on your own.

Thanks

[maxvamp]

I'll play nice.

Max.

[Rincewind42]

You're right. So the P4 can theoretically execute 2 double-precision floating point operations per cycle, one SSE and one regular. Which is the same number as the G5 can (2 regular), so the P4 wins in theory when it comes to double-precision flops because it has a higher clock speed.

The only disadvantage for the P4 is that you have to mix SSE and regular float instructions to reach the full potential.

This is also complicated by the fact that the x86 FPU is stack based, so it is not as easy to work with as more modern FPUs. That is one of the primary motivations behind SSE*, to make floating point on x86 easier to use. So while you may in theory be able to run in the FPU & SSE at the same time, it is not necessarily the most straightforward thing to do.

Whereas with the G5 the optimization advice is to pretend that you have a single FPU with a 12 cycle latency when scheduling (even though you actually have 2 FPUs with a 6 cycle latency). I dare say that I don't even want to think about how you would optimize the use of a stack-based FPU with a register-based FPU for similar scheduling gains.

[Catfish_Man]

This is also complicated by the fact that the x86 FPU is stack based, so it is not as easy to work with as more modern FPUs. That is one of the primary motivations behind SSE*, to make floating point on x86 easier to use. So while you may in theory be able to run in the FPU & SSE at the same time, it is not necessarily the most straightforward thing to do.

Whereas with the G5 the optimization advice is to pretend that you have a single FPU with a 12 cycle latency when scheduling (even though you actually have 2 FPUs with a 6 cycle latency). I dare say that I don't even want to think about how you would optimize the use of a stack-based FPU with a register-based FPU for similar scheduling gains.

Easier on AMD's chips or the P3/PM since FXCH is 0 cycles. I don't remember what the latency is on the P4, but it's definitely a pain. Also... am I wrong that no x86 chip so far has had a separate SSE unit? SSE and MMX together I could see, but I definitely recall reading that SSE is done in the FP pipeline.