C++ performance in Ubuntu vs. Mac OS X

[jvn]

I have a puzzle. I have an HP desktop running Ubuntu 9.04 and a MacBook Pro running Mac OS 10.5. I am running a piece of C++ code, which reads 100,000 lines of binary data and writes it out to another file in ASCII. It runs nearly 6 times faster on my MBP than on the HP (2 secs vs. 12 secs). But, the HP is a bigger/faster machine. Here are the specifics:

Ubuntu 9.04 with 4GBs ram, Intel 2.4GHz Quad 2 Core Q6600, Seagate 7200 rpm 750GB hdd, filesystem is ext3, GCC version is 4.3.3.

MBP with 1GB ram, Intel 2GHz Core Duo, 5400 rpm hdd, GCC version is 4.0.1.

I have compared the output with diff and cmp and they are the same. Anyone have any ideas why this is happening? Shouldn't the HP Ubuntu machine be running this faster? I would really appreciate your help!

~JVN

 

[MrLinux]

Apple keep very tight control over the hardware used (and supported) in their products, so the OS and related tools can be very highly optimised for the hardware; Ubuntu running on generic PC hardware would require multiple abstraction layers to allow for the huge range of possible hardware devices…
The result is Apples are faster, but you pay for it by having a restricted choice of more expensive hardware...

 

[Zorak]

If you are already familiar with Linux a bit, you could compile your own kernel to be a bit more tailored to the hardware on your system. Compiling the C runtime libraries on your system with some optimizations turned on would probably help too. However, this would probably only get you a few percent extra performance. As MrLinux pointed out, it is much easier to optimize for performance when you are only targeting a very narrow possible list of hardware configurations.

Also, just for the sake of better experimental rigor, it is probably best if you were to perform the test using Ubuntu dual booted on the same hardware. Either make your HP machine into a hackintosh or put ubuntu on the other machine. Also, try to get the same version of GCC if possible (there could be performance regressions that you don't know about). I'd say it is better to do it this way, so that you can have a better understanding what difference the OS and available runtime libraries make. In any experiment, it is best to keep the number of changing variables to a minimum.

--Zorak

 

[linux_0]

Are you running ubuntu 9.04 i386 or amd64?

Did you compile the code with the exact same flags?

Does your code run in a single thread?

 

[jvn]

Are you running ubuntu 9.04 i386 or amd64?

Did you compile the code with the exact same flags?

Does your code run in a single thread?

I am running Ubuntu 9.04 amd64. I compiled the code on both machines with the following command:

g++ -g -Wall -o name name.cpp

Forgive my lack of understanding, but how do I tell if my code runs in a single thread?

Thanks so much for your help!

~JVN

 

[jvn]

If you are already familiar with Linux a bit, you could compile your own kernel to be a bit more tailored to the hardware on your system. Compiling the C runtime libraries on your system with some optimizations turned on would probably help too. However, this would probably only get you a few percent extra performance. As MrLinux pointed out, it is much easier to optimize for performance when you are only targeting a very narrow possible list of hardware configurations.

Also, just for the sake of better experimental rigor, it is probably best if you were to perform the test using Ubuntu dual booted on the same hardware. Either make your HP machine into a hackintosh or put ubuntu on the other machine. Also, try to get the same version of GCC if possible (there could be performance regressions that you don't know about). I'd say it is better to do it this way, so that you can have a better understanding what difference the OS and available runtime libraries make. In any experiment, it is best to keep the number of changing variables to a minimum.

--Zorak

Zorak,

Thanks for your suggestions. I am looking into compiling my own kernel, as well as recompiling the C runtime libraries.

Thanks!

~JVN

 

[audiovoodoo]

I'm amazed nobody has suggested trying a different version of GCC. Were there not some issues with a recent release that actually made things slower? I'm sure I remember reading something about it on /. a while back. I can't find the specifics but a quick Google gave:

http://gcc.gnu.org/ml/gcc-bugs/2009-06/msg01000.html

so newer != better in every case.

 

[jvn]

I'm amazed nobody has suggested trying a different version of GCC. Were there not some issues with a recent release that actually made things slower? I'm sure I remember reading something about it on /. a while back. I can't find the specifics but a quick Google gave:

http://gcc.gnu.org/ml/gcc-bugs/2009-06/msg01000.html

so newer != better in every case.

Thank you very much for your suggestion. I will give this a try.

~JVN

 

[audiovoodoo]

No problem.

@Zorak - sorry man, I missed your mention of GCC versions in your reply.