RichA wrote:



I don't know if this is the answer, but in both cases, the hardware is definitely NOT the same.

Your Windows install may have some driver that is slowing it down that the Ubuntu doesn't have because it's running on virtualized hardware.

W3bbo wrote:

Have you tried running a binary for Windows compiled with GCC?

Or the VC built version under WINE under Ubuntu?

Antitorgo wrote:



I see that you are linking to GMP in Linux, what math library are you using in Windows? Are you using a port of GMP for Windows? If so, which port? Where did you get it from and how was it compiled?

Since computing Mersenne Primes with the Lucas Lehmer test is pretty FFT/iFFT intensive the quality of whatever math library you are using is key.

Seeing as how Prime95 for windows and GLucas for linux/mac both seem to run about the same speed, (granted they both use highly optimized assembly for the FFTs) I highly doubt that Windows is making things slower. (See http://www.mersenne.org/)

You claim to be comparing apples to apples, but I highly doubt it.

TimP wrote:

Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere.

TimP wrote:

Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere.

W3bbo wrote:



TimP wrote: Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere.

Optimizations are good... but I'd never expect a 50% gain in performance with them.

gcc -m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8 mersenne.c /usr/local/lib/gmp.so

Adding the path to gmp.so, in particular. If my understanding of the gcc documentation is accurate, it will regard gmp.so as an "in file", which would seem to imply (if gcc is not complaining) that gmp.so is being statically linked with your executable. You can test this by running ldd yourbinary. If you don't see gmp.so in the output, you're statically linking. I'm not well versed on VC++, so I don't know if your VC++ build is performing static linking or how you would check on Windows. Can anyone chime in?

Back to the point at hand though, if this was the case you should have a fixed delay since dynamic linking resolution is done at invocation and the runtime differences would always be different by a roughly fixed amount.

W3bbo wrote:



TimP wrote: Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere.

Optimizations are good... but I'd never expect a 50% gain in performance with them.

TimP wrote:



W3bbo wrote:  TimP wrote: Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere. Optimizations are good... but I'd never expect a 50% gain in performance with them.

I would assume so too, but it's worth ruling out.

I'm slightly confused by the invocation of gcc.

gcc -m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8 mersenne.c /usr/local/lib/gmp.so

Adding the path to gmp.so, in particular. If my understanding of the gcc documentation is accurate, it will regard gmp.so as an "in file", which would seem to imply (if gcc is not complaining) that gmp.so is being statically linked with your executable. You can test this by running ldd yourbinary. If you don't see gmp.so in the output, you're statically linking. I'm not well versed on VC++, so I don't know if your VC++ build is performing static linking or how you would check on Windows. Can anyone chime in?

Back to the point at hand though, if this was the case you should have a fixed delay since dynamic linking resolution is done at invocation and the runtime differences would always be different by a roughly fixed amount.

TimP wrote:



So it is indeed doing dynamic linking. Maybe passing shared objects to gcc implicitly tells it to link them dynamically, but I've never seen it done before (I usually see -l<lib>).

Since the running time seems to grow with the size of the input, my only guess is that threading is being (ab)used in a way that pthreads handle more gracefully than Windows threading (assuming pthreads-win32 is a wrapper for Windows threads). I would attempt to run to core calculations of the algorithm without any threading involved and compare the numbers.

TimP wrote:



So it is indeed doing dynamic linking. Maybe passing shared objects to gcc implicitly tells it to link them dynamically, but I've never seen it done before (I usually see -l<lib>).

Since the running time seems to grow with the size of the input, my only guess is that threading is being (ab)used in a way that pthreads handle more gracefully than Windows threading (assuming pthreads-win32 is a wrapper for Windows threads). I would attempt to run to core calculations of the algorithm without any threading involved and compare the numbers. I'm not sure what you're using to do your timing, but there is a time program standard on Linux that you can use.

time ./a.out

Shining Arcanine wrote:



TimP wrote:  So it is indeed doing dynamic linking. Maybe passing shared objects to gcc implicitly tells it to link them dynamically, but I've never seen it done before (I usually see -l<lib>). Since the running time seems to grow with the size of the input, my only guess is that threading is being (ab)used in a way that pthreads handle more gracefully than Windows threading (assuming pthreads-win32 is a wrapper for Windows threads). I would attempt to run to core calculations of the algorithm without any threading involved and compare the numbers.

Those numbers are without any threading involved. The original ones for WIndows were with threading involved.

TimP wrote:



Shining Arcanine wrote:  TimP wrote:  So it is indeed doing dynamic linking. Maybe passing shared objects to gcc implicitly tells it to link them dynamically, but I've never seen it done before (I usually see -l<lib>). Since the running time seems to grow with the size of the input, my only guess is that threading is being (ab)used in a way that pthreads handle more gracefully than Windows threading (assuming pthreads-win32 is a wrapper for Windows threads). I would attempt to run to core calculations of the algorithm without any threading involved and compare the numbers. Those numbers are without any threading involved. The original ones for WIndows were with threading involved.

Is the processor multicore? (I didn't see it mentioned in the OP) If it isn't, threading code is just overhead and performance will be degraded on your Windows test.

staceyw wrote:

When I try to find this kind of thing, I try to eliminate as much as possible, then add stuff back until I find the issue.  Try running test on native OS in both cases w/o VM.  Also, verify your timer code is same in both cases. 

Shining Arcanine wrote:


I am not quite sure what you mean by "Try running test on native OS in both cases w/o VM."

If you were having problems with the Linux side I would offer my help, but unfortunately I don't have much experience debugging or tuning unmanaged applications on Windows.

TimP wrote:



Shining Arcanine wrote:  I am not quite sure what you mean by "Try running test on native OS in both cases w/o VM."

Run it without a virtual machine. The Ubuntu 6.10 disc can be used as a LiveCD. In this case though, the performance issues seem to be with the host operating system, so if anything running Linux on bare metal would only skew the numbers more.

If you were having problems with the Linux side I would offer my help, but unfortunately I don't have much experience debugging or tuning unmanaged applications on Windows.

RichardRudek wrote:

I've read about similar sorts of perf issues with various STL containers (C++) and all of the bounds-checking that occurs by default using the new compilers.

I'd expect there's a similar thing at work here (with your C code), so research that.

Shining Arcanine wrote:


 I also applied all of the optimization flags that I applied to my project to the lib_gmp_gc project.

RichardRudek wrote:



Shining Arcanine wrote:   I also applied all of the optimization flags that I applied to my project to the lib_gmp_gc project.

I've never used this library. So I go and download the bits, and then realise what you said above, which I embolded.

The whole point of this library is that key parts of it are compiled using hand optimised assembler. Yet you've elected to compile the Windows library using the Generic C version. Why ?

Shining Arcanine wrote:


It takes 1 second to test M0 through M2281 on Ubuntu and 2 seconds on Windows, making Ubuntu 100% faster.

Yggdrasil wrote:



Shining Arcanine wrote:  It takes 1 second to test M0 through M2281 on Ubuntu and 2 seconds on Windows, making Ubuntu 100% faster.

From what I remember of your original numbers, you're getting huge rounding errors here. The 1sec reported by time on linux was actually 1.6seconds. Try calculating this with more decimal points and you'll get wildly different ratios.

Shining Arcanine wrote:

I cannot calculate this with more decimal points. time.h only reports seconds.

Shining Arcanine wrote:

richard@richard-desktop:~$ time ./a.out 0 2281
.
.
.
17 prime numbers were found. It took 1.00 seconds
real    0m1.676s
user    0m1.652s
sys     0m0.008s

Shining Arcanine wrote:

Not when you consider the fact that there is no analogous measurement method avaliable on Windows..

Syntax: ptime command [arguments ...]

ptime will run the specified command and measure the execution time (run time) in seconds, accurate to 5 millisecond or better. It is an automatic process timer, or program timer.

W3bbo wrote:



TimP wrote: Perhaps gcc is performing optimizations that VC++ is not. Try compiling them both with no optimizations and test the run times. If they're equivalent, then gcc is optimizing more aggressively, otherwise the culprit is elsewhere.

Optimizations are good... but I'd never expect a 50% gain in performance with them.

Shining Arcanine wrote:


Bounds checking? C is not supposed to have bounds checking. That is a Java feature.

Bounds checking could be related is related to the Buffer Security Check, which I have disabled. I am not sure if there are any other features that Microsoft put into its compiler that would do this sort of checking. Is anyone from the Visual Studio team reading this thread and do you have anything to say about any of the things mentioned in the thread?

Shining Arcanine wrote:

Not when you consider the fact that there is no analogous measurement method available on Windows.

I would have to write a time program myself and I have other things to do.

evildictaitor wrote:



Shining Arcanine wrote:  Bounds checking? C is not supposed to have bounds checking. That is a Java feature. Bounds checking could be related is related to the Buffer Security Check, which I have disabled. I am not sure if there are any other features that Microsoft put into its compiler that would do this sort of checking. Is anyone from the Visual Studio team reading this thread and do you have anything to say about any of the things mentioned in the thread?

Bounds checking in C is hard, but possible, and actually happens in lots of modern C compilers (including GCC and VC++). With static arrays it's easy:

int c[100];
for(int i=0;i<=100;i++){
  if(i > 100) #error // inserted by the compiler.
  c[i] = i;
}

Will error when you build the flow graph. With dynamically allocated memory it's more expensive:

int * myArray = calloc(100, sizeof(int));
for(int i=0;i<=100;i++){
  myArray[i] = i;
}


int * myArray = calloc(100, sizeof(int));
for(int i=0;i<=100;i++){
  int __cptr = (int)myArray + sizeof(int) * i;
  if(malloc_index(__cptr) == -1 || malloc_index(myArray) != malloc_index(__cptr)) #error
  *__cptr = i;
}

where malloc_index looks through the malloc table (O(log n)) and returns the index in the table that corresponds to the pointer.

evildictaitor wrote:



Shining Arcanine wrote: Not when you consider the fact that there is no analogous measurement method available on Windows. I would have to write a time program myself and I have other things to do.

You should do the test many times:

float f;
int i, time;

setup_low_resolution_timer();
for(i=0;i<1000;i++){
  do_function();
}
time = stop_low_resolution_timer();

f = ((float)time / 1000);

Shining Arcanine wrote:


I do not want the compiler to try to second guess whether or not I have adequetely ensured that my loop bounds are always in range. Is there any way to disable that feature in GCC (3.4.6 and up) and Visual Studio 2008 Professional?

Shining Arcanine wrote:

That is an option that I will probably use in the future when tweaking my program to get more performance, although for now, I am considering the case to be closed.

AndyC wrote:

It's worth pointing out that unless you have the VM Additions installed, timing under a virtual OS can be somewhat skewed. And there are no VPC additions for Ubuntu....

longnight wrote:

You might try running the windows app in a virtual windows os. It could be something like a virus scanner interfering with the numbers.

W3bbo wrote:



AndyC wrote: It's worth pointing out that unless you have the VM Additions installed, timing under a virtual OS can be somewhat skewed. And there are no VPC additions for Ubuntu....

The VPC additions for Red Hat can be coaxed to work under Ubuntu IIRC.

Otherwise just use WMWare, Windows 95 and Ubuntu both run better under it in my experience.