Linked by Rayiner Hashem on Tue 15th Nov 2005 17:44 UTC
Apple I recently bought one of the new dual core PowerMacs. Having used the machine for a couple of weeks, I thought I would share some of my observations and feelings about it. First, let me get my biases out in the open. I have, for about four years, very happily used Linux on my desktop. Doing so has made me very comfortable with the UNIX environment in general, and with GNOME specifically. During that time, I have used OS X machines on a regular basis, so I am quite comfortable in that environment as well. Since I switched to Linux, I have not used Windows for anything more than the occasional bit of software testing or lab work, and generally feel quite uncomfortable with it. Thus, this article is very much written from the perspective of someone who finds OS X and Linux pleasing on principle. I implore the reader to make his own value judgments based on my comments.
Thread beginning with comment 60658
To read all comments associated with this story, please click here.
Some comments!!!
by Hakime on Wed 16th Nov 2005 05:07 UTC
Hakime
Member since:
2005-11-16

My next point concerns the poor knowledge of what 64 bits means. The author wrote:
"The G5 is fastest when running 32-bit code, and the X2 is fastest when running 64-bit code. "

That's nonsense. Hey you are student of aerospace engineering and you dont know what 64 bits means. For users 64 bits means two things:
- 64 bits integers
- 64 bits memory adressing. That is a processor that be able to adress terobytes of memory.
Nothing else, if an os allows any process to adress more than 4 GB of memory, then the os is 64 bits. You wrote this " Moreover, OS X and its apps are almost completely 32-bit, while Ubuntu and its apps are almost completely 64-bit."
This sentence is meaningless, and this misunderstod of how Tigers handles 64 bits comes very often (for more information i would advice the author to read arstechnica's Tiger article) OS X allows any process to adress more than 4GB of memory that is, up to 4 TeraBytes of physical memory and up to 16 exabytes of virtual memory. The limitation comes in as OSX only allows process that runs in the shell to adress 64 bits. Any code that has calls to the CArbon or Cocoa API can not run in 64 bits at present. Thats ok because most (actually only) people who use 64 bits are people in high performance computing and who need to write 64 bits apps that do not use a GUI in general. For apps that do, its still possible to write a 64 bits thread to handle a task that 64 bits computing and to send resultst to the app via Mach message passing. That's an elegant solution because anyway a high end app, does not always need to adress large memory as a whole, but only for some hign end tasks that can be handled in separate threads.

So OS X is 64 bits as Ubuntu is, OS X provides 64 bits supports for people who needs it, you really do not need a 64 bits compiled mail app. You dont believe me, well an example, the last version of Mathematica 5.2 support 64 bits adressing across many os, including Tiger.
In general, the author speaks about Ubuntu 64 bits apps, those apps are generally not 64 bits, those apps are 32 bits recompiled to run on 64 bits chips in a 32 bits mode.

AMD is champion regarding the 64 bits marketing. They always come up with some test by comparing 32 bits and 64 bits apps and conclude that 64 bits chips are much faster. And the author seem to have fallen in the marketing trap. Fisrt of all when AMD talks about 64 bits apps most of their test are actually using 32 bits apps recompiled for 64 bits chips which have more registers (16 on 64 bits AMD chips, 8 on 32 bits chips).

The app is still 32 bits but performs better in the so called 64 bits modes, because simply the chip has more registers which improve the performace of 32 bits apps by a simple recompilation. But again the app have not be rewritten to adress memory in 64 bits (you need to write code to do that), so the app is not runnign in a true 64 bits mode, it still 32 bit.

Worse a french team (x86-secret.com) have discovered a few months ago that AMD in their comparison between 32 apps and 64 bits apps actually compared a 32 bits function written in C and without any optmization (this was the 32 app, this function was inside the source code of an unzip app) against a assembly highly optimized 32 bits written function (this was the so called 64 bits app). Guess who win, they made to put a lot of importance in the performance of the 64 bits, but it end up to be a huge user manipulation.

If you recompile a 32 bits app to run on a G5 well it will perform like if the G5 would be 32 bits, its normal, again because the app is still 32 bits not 64 bits.

How can you conclude that the X2 is faster running 64 bits code, you actually did not run any 64 bits tests. If you want to test both machines for performing 64 apps that deal with large date set, well you need to run some code that actually adresses more than 4 GB to run. Thats how to test 64 bits performance. You did not do so, so your statement is wrong!!!!

Thare are also many starnge commenst from the author about this quation of memory or disque. But i guess that previous people have already replied to that.

Reply Score: 1

RE: Some comments!!!
by rayiner on Wed 16th Nov 2005 05:57 in reply to " Some comments!!!"
rayiner Member since:
2005-07-06

For users 64 bits means two things:
- 64 bits integers
- 64 bits memory adressing. That is a processor that be able to adress terobytes of memory.


The "user" is irrelevant here. We're talking about benchmarks of a CPU from the perspective of a developer. On both CPUs, "64-bit mode" has a very specific meaning. On the Opteron, a 64-bit binary is code that runs with the long-mode bit enabled and uses 64-bit instruction encodings. On the G5, a 64-bit binary is code that runs with the SF bit in the MSR set to 0, and uses the regular SLB mappings.

Nothing else, if an os allows any process to adress more than 4 GB of memory, then the os is 64 bits.

The OS is 64-bits if the kernel and its libraries are compiled as 64-bit binaries, whatever that implies in the target architecture. Nothing less, nothing more.

This sentence is meaningless, and this misunderstod of how Tigers handles 64 bits comes very often (for more information i would advice the author to read arstechnica's Tiger article) OS X allows any process to adress more than 4GB of memory that is, up to 4 TeraBytes of physical memory and up to 16 exabytes of virtual memory

You're missing the point. The fact that OS X Tiger allows 64-bit binaries to run does not change the fact that the kernel itself is a 32-bit binary. As someone pointed out to me:

file /mach.sym gives:

mach.sym: Mach-O executable ppc

file ./nbench (which I've compiled in 64-bit mode) gives:

nbench: Mach-O 64-bit executable ppc64

The limitation comes in as OSX only allows process that runs in the shell to address 64 bits. Any code that has calls to the Carbon or Cocoa API can not run in 64 bits at present.

Yes, because, because Carbon and Cocoa, along with most of the OS are compiled as 32-bit binaries! 64-bit binaries cannot link to 32-bit binaries.

That's an elegant solution because anyway a high end app

It's hardly an elegant solution, just a decent hack until the OS X user-space can be made 64-bit clean.

So OS X is 64 bits as Ubuntu is, OS X provides 64 bits supports for people who needs it, you really do not need a 64 bits compiled mail app.

No! Every binary in Ubuntu runs in 64-bit mode. No binary, by default, in OS X runs in 64-bit mode.

In general, the author speaks about Ubuntu 64 bits apps, those apps are generally not 64 bits, those apps are 32 bits recompiled to run on 64 bits chips in a 32 bits mode.

You have absolutely no idea what you're talking about. Source code does not have an intrinsic "bit-ness". Whether you compile it as a 64-bit binary or a 32-bit one is what decides whether it is 64-bit. In OS X, you do this via the GCC flag: -arch ppc64. Most OS X binaries are not compiled with this flag. Instead, they run in a "32-bit mode" on the G5, with the SF bit set to 0.

The app is still 32 bits but performs better in the so called 64 bits modes, because simply the chip has more registers which improve the performace of 32 bits apps by a simple recompilation. But again the app have not be rewritten to adress memory in 64 bits (you need to write code to do that), so the app is not runnign in a true 64 bits mode, it still 32 bit.

No, the app isn't still a 32-bit app. It uses 64-bit pointers, and can its 'long' type is 64-bits. That makes it a 64-bit app! And you don't need to do any rewriting to have a C app address 64-bits, because it's already using 64-bit pointers.

How can you conclude that the X2 is faster running 64 bits code, you actually did not run any 64 bits tests.

All the tests on the X2 were run in 64-bit mode. They all operated with in 64-bit long mode, used 64-bit pointers, and used the amd64 instruction set.

Reply Parent Score: 2

RE: Some comments!!!
by japail on Wed 16th Nov 2005 14:14 in reply to " Some comments!!!"
japail Member since:
2005-06-30

Just so we're clear, you think that whether a program compiled for x86_64 or ppc64 uses 64-bit addressing depends on whether it actually uses more than 4GB of memory? If that's what you think, please let me know.

Reply Parent Score: 1