@cblake thanks for the explanation. I will check with the profiler. From what
you said I tried this and get almost the same results - now for gcc and g++ and
for clang a speed up of about 4x.
proc fib(n: int): uint64 =
if n > 1 and n != 30: return fib(n - 1) + fib(n - 2)
It might be a lot of things, but I'm telling you - there is a `gcc`
optimization, very finicky about context (and probably compiler flags, too),
that reduces function calls by almost exactly his speed-up factor. There's
really no need to guess if I'm right, though. Just add `-pg` to the gcc flag
Besides constant folding, there might be [code
alignment](https://dendibakh.github.io/blog/2018/01/18/Code_alignment_issues)
that can cause massive perf difference.
No `gcc` doesn't -- at least not for me with a factor of about 7X, almost
identical to @adrianv 's results. I used both an earlier gcc-7 and a gcc-8.2
just now.
If you don't want to disassemble your binary, that's ok. You can check this
with `gcc -pg` and `gprof` which will count calls for you.
Nim doesn't evaluate fib(46), GCC does. And it doesn't get up to fib(46), it
evaluates up to fib(34) then does the remaining calculations at runtime. I'm
sure this exact same occurence was mentioned in an older thread.
I am not quite sure what "original" benchmark you mean - perhaps the 4.6 s for
Nim vs 6.0 s for C on the original github page at the top of this thread. That
may be small scale code layout/caching/branch predictor effects as you say.
However, the difference in this thread of 8X is _almost certai
Don't get overexcited. This is probably just a coincidence coming from the
random addresses of the compiled functions and branch instructions that affect
things like the branch prediction unit in the CPU.
> If Nim compiles to C Nim is not faster than C but Nim is able to produce
> faster C code than human programmers.
Effectively making it faster than C ;)
I also got `nim c` 's code running twice as fast as `nim cpp` 's code. See some
previous discussion:
[https://forum.nim-lang.org/t/1779](https://forum.nim-lang.org/t/1779) \- there
are cases where Nim's generated C code "inspires" the C compiler to "unroll the
last few recursions" and save 4x o
On my end `nim cpp` is twice _slower_ than `nim c`.
Oh and btw, whichever version of code you use — the result is not correct ;)
Try running `fib(2)` and you'll see what I'm talking about.
If Nim compiles to C Nim is not faster to C but Nim may produce faster C code
than human programmers.
I think this was posted a while ago and the answer was that G++ found a way to
constant fold Nim's C++ output. This means it probably evaluated fib(46) before
the program ever ran. A bit disappointing, sure, but the C output benchmark is
still very good.
Hi, on twitter I saw that Nim performed better on fibonacci benchmark than C
and C++ ([https://github.com/drujensen/fib](https://github.com/drujensen/fib))
and wondered why. I did my own tests and these are quite interesting:Language|
Time in s| compiled with
---|---|---
Nim| 0.456| nim cpp
13 matches
Mail list logo
