Number generator performance linux vs windows

Question

I compiled this code using mingw32 4.4.1 on windows 7 64-bit using codeblocks. For Debian I used g++ 4.9.2.

#include <iostream>
#include <time.h>
#include <math.h>
#include <cstdlib>

using namespace std;

int main()
{
    clock_t t1,t2;
    t1=clock();

    for (int i=0; i<=50000; i++)
    {
        cout << i << " ";
    }    

    t2=clock();
    float diff (((float)t2-(float)t1) / CLOCKS_PER_SEC);
    cout<<"it took: "<<diff<<endl;
    system ("pause");
    return 0;

}

Windows XP 32-bit Virtual Machine: 3 times, mean time to generate was 7.656 sec

Windows 10 32-bit Virtual Machine: 3 times, mean time to generate was 16.446 sec

Debian 8.2 32-bit Virtual Machine: 3 times, mean time to generate was 0.0118 sec

How can this huge difference in time be explained specially between linux and windows ?

Kindly provide keywords and topic names that I could research and read to have a better in-depth understanding behind the reason, in addition to your explanation.

Did you have compiler optimization enabled in your Windows builds? What compilers did you use and how did you invoke them? — Baum mit Augen, Oct 20 '15 at 13:56
Also, what does this have to do with rng? I feel like you do not measure what you wanted to measure. — Baum mit Augen, Oct 20 '15 at 13:57
I invoked it by clicking on "build & run" in codeblocks, in the setting it says C++ Compiler: mingw32-g++.exe ; MinGW32 4.4.1 No Optimization, no flags added. On Debian: g++ file.c -o NumGen — SAZ, Oct 20 '15 at 14:06
it not about rng, I wanted to write a simple code, then find out how much time it takes to tun on different OSs and why. I'm beginner and I this is what I came out with, please suggest a more resource intensive function if possible. — SAZ, Oct 20 '15 at 14:13
Oh sorry, I misread. First of all, always measure with optimization enabled. The performance of unoptimized C++ code does not matter. Second, your current code is most likely I/O bound. That means that you measure mostly the time it takes to print the numbers (although you should flush the stream before you stop the timer), and not the time it takes to generate them. Is that what you want? — Baum mit Augen, Oct 20 '15 at 14:16
Thanks, No I didn't want to measure the time it takes to print the number, I wanted a more intensive task that involves the cpu as well. I didn't know I'm measuring mostly I/O. could you refer me to a more complex mathematical algorithm/function, that I could use to benchmark the performance on different OSs ? — SAZ, Oct 20 '15 at 14:35
Benchmarking stuff that takes very little time is far from trivial. For example, [this](https://www.youtube.com/watch?v=nXaxk27zwlk) is a good watch. For stuff like `+` on integers and floats or `exp`, `sqrt` etc. I would not expect a difference between OSs as they are usually done by the CPU directly, not by anything OS specific, but hey, C++ performance is full of surprises. What you most likely should do is write correct code first. Then, if it is not fast enough, use a profiler to find out what parts take up the most time and then try to optimize those. — Baum mit Augen, Oct 20 '15 at 14:42
And last but not least: One can write fast code for any OS if it matters. — Baum mit Augen, Oct 20 '15 at 14:44
Thanks, that was very useful. Just to verify, mostly the performance difference is trivial with different OSs if trying to measure the CPU performance. On the other if trying to measure I/O performance the difference could be big on different OSs. — SAZ, Oct 20 '15 at 14:58
+1 by way of welcome :) 1) of course you are learning that I/O-bound programs will not meaningfully demonstrate non-I/O speed. 2) Later, when you have a program big enough to actually take significant time, whether I/O-bound or not, and you want to speed it up, you will find that measuring doesn't tell you much, but [*this technique will work.*](http://stackoverflow.com/a/378024/23771) — Mike Dunlavey, Oct 20 '15 at 15:15
@SAZ Neither one is true in general and both could be true on your specific target environment. There is no silver bullet here. Just for the record: Currently, you do not measure anything useful at all. — Baum mit Augen, Oct 20 '15 at 15:52
@MikeDunlavey What point exactly? I'm usually up for an internet debate. :) — Baum mit Augen, Oct 20 '15 at 21:08
@Baum: I made a couple points above, but (2) is the one I enjoy debating, especially with academics (which I was once, not that that matters). The crux of it is [*here*](http://scicomp.stackexchange.com/a/2719/1262). Briefly: speed is limited by the problems not found due to emphasis on measurement. — Mike Dunlavey, Oct 21 '15 at 12:56
@MikeDunlavey Alright, let's go! http://chat.stackoverflow.com/rooms/93004/discussion-with-mike-dunlavey — Baum mit Augen, Oct 21 '15 at 18:34

score 0 · Answer 1 · answered Oct 20 '15 at 13:57

0

I think this is an artifact of the windows console (which is slow). Try running the windows code with

program > data.txt

and check there. Also was the linux code running on X, or in a straight terminal. A straight terminal would have been faster.

answered Oct 20 '15 at 13:57

mksteve

12,614
3
28
50

score 0 · Accepted Answer · answered Oct 20 '15 at 14:01

0

cout is not OS independent.

Try writing to memory then dumping the results then meassure. It should be more accurate.

stdout on windows causes flushes more often the the ones on linux (which cache then flush).

answered Oct 20 '15 at 14:01

MichaelCMS

4,703
2
23
29

Number generator performance linux vs windows

2 Answers2