5 ms·

Be careful what conclusions you attempt to draw from examples when you arent sure what exactly is happening. These examples are actually very wrong and misleadi

Be careful what conclusions you attempt to draw from examples when you arent sure what exactly is happening. These examples are actually very wrong and misleading. Take for example, the first code snippet about how many loops you can run in 1 second. The OP fails to realize that since the loop isnt producing anything which gets actually used, the compiler is free to optimize it out. You can see that thats exactly what it does here: https://godbolt.org/g/NWa5yZ https://godbolt.org/g/NWa5yZ All it does is call strtol and then exits. It isnt even running a loop.

justonepost 10y ago
Smart computer can do dumb things very very very fast.
gizmo 10y ago
The page claims the C program can do 550 million loop iterations in one second. That's exactly what you would expect from an average laptop. So the loop clearly isn't getting optimized out in the executable used by the authors. If you compile with -O0 you can confirm this for yourself. You can also see that in later examples printf() statements are added to stymie the optimizer.
andreyf 10y ago
Seems clear the question assumes you're generating code that actually increments the integer (i.e. repeating a single add instruction). An anecdote defending the question on a non-technical level: when I was a kid around 4 or 5 my dad had me race a computer counting to 1000. It was one of the more memorable parts of my young childhood!
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
Klockan 10y ago
> You can see that thats exactly what it does here: https://godbolt.org/g/NWa5yZ https://godbolt.org/g/NWa5yZ You are wrong as well, that is what it is doing if you compile it with -O2 on that exact compiler. Try compiling with -O0 instead and it will include those instructions. Also the number is reasonable, modern cpu cores can execute around a billion loop iterations per second.
- saagarjha 10y ago
  The page mentions that all C programs were compiled with gcc -O2.
jvns 10y ago
We automatically generated all the results in this quiz from the programs on the site. None of the loops were optimized out, we ran basically a binary search to figure out the maximum number of iterations you could run in a second. Results and compiler optimizations will of course vary across computers, but they were correct on my laptop on the day that we ran them (in Sept. 2015). If you want to reproduce this on your computer and see how the results are different, you can clone https://github.com/kamalmarhubi/one-second https://github.com/kamalmarhubi/one-second and run `run_benchmarks.py`
- Johnny555 10y ago
  The -O2 flag wasn't added to the benchmark script until Sept 20th in commit 4a31931, I suspect you ran at least sum.c without that flag since any modern gcc compiler should have optimized away that entire loop. I downloaded and ran the benchmarks and indeed the search for the 1 second runtime for sum.c never completed -- it never found an answer because the sum binary runs in constant time regardless of the iteration count. In fact, atoi() in sum.c quickly overflowed once the iteration count exceeded 2^31 (since atoi() returns a signed int). I removed the -O2 flag and then I got the same 550429840 iter count as you on my laptop. The benchmark script isn't really doing a binary search, it's doing a linear search since it's increasing the iteration count by 10% with each loop.
- alkonaut 10y ago
  No, look again. it's constant time. Yes, "optimizations will vary" - but any C compiler with reasonable settings should just ignore the loop. Otherwise you are running so un-optimized that there is no point in talking about the runtmie of the program anyway. You should change it to return the sum.

justonepost 10y ago

Smart computer can do dumb things very very very fast.

gizmo 10y ago

The page claims the C program can do 550 million loop iterations in one second. That's exactly what you would expect from an average laptop. So the loop clearly isn't getting optimized out in the executable used by the authors. If you compile with -O0 you can confirm this for yourself. You can also see that in later examples printf() statements are added to stymie the optimizer.

andreyf 10y ago

Seems clear the question assumes you're generating code that actually increments the integer (i.e. repeating a single add instruction). An anecdote defending the question on a non-technical level: when I was a kid around 4 or 5 my dad had me race a computer counting to 1000. It was one of the more memorable parts of my young childhood!

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

Klockan 10y ago

> You can see that thats exactly what it does here: https://godbolt.org/g/NWa5yZ https://godbolt.org/g/NWa5yZ You are wrong as well, that is what it is doing if you compile it with -O2 on that exact compiler. Try compiling with -O0 instead and it will include those instructions. Also the number is reasonable, modern cpu cores can execute around a billion loop iterations per second.

saagarjha 10y ago
The page mentions that all C programs were compiled with gcc -O2.

jvns 10y ago

We automatically generated all the results in this quiz from the programs on the site. None of the loops were optimized out, we ran basically a binary search to figure out the maximum number of iterations you could run in a second. Results and compiler optimizations will of course vary across computers, but they were correct on my laptop on the day that we ran them (in Sept. 2015). If you want to reproduce this on your computer and see how the results are different, you can clone https://github.com/kamalmarhubi/one-second https://github.com/kamalmarhubi/one-second and run `run_benchmarks.py`

Johnny555 10y ago
The -O2 flag wasn't added to the benchmark script until Sept 20th in commit 4a31931, I suspect you ran at least sum.c without that flag since any modern gcc compiler should have optimized away that entire loop. I downloaded and ran the benchmarks and indeed the search for the 1 second runtime for sum.c never completed -- it never found an answer because the sum binary runs in constant time regardless of the iteration count. In fact, atoi() in sum.c quickly overflowed once the iteration count exceeded 2^31 (since atoi() returns a signed int). I removed the -O2 flag and then I got the same 550429840 iter count as you on my laptop. The benchmark script isn't really doing a binary search, it's doing a linear search since it's increasing the iteration count by 10% with each loop.
alkonaut 10y ago
No, look again. it's constant time. Yes, "optimizations will vary" - but any C compiler with reasonable settings should just ignore the loop. Otherwise you are running so un-optimized that there is no point in talking about the runtmie of the program anyway. You should change it to return the sum.