Curious about nim compile options

[ozra]

I'm investigating languages in an effort to finally ditch C++, and have narrowed it down more and more to Nim, still investigating. So I was curious to the slowness in these benches since I've seen it top many. Was nim -d:release --opt:fast used?

[nsf]

You can see all the options there: https://github.com/nsf/pnoise/blob/master/compile.bash

So.. -d:release was used. --opt:fast was not.

[ozra]

Should've looked deeper then the results. Would you mind setting it for your next update of tests? Since it's standard use in 'fast releases', like -O2 or -O3 in gcc. I'd be interested to see results that are more fair to "what I'm looking for"...

[nsf]

--opt:none|speed|size     optimize not at all or for speed|size
                            Note: use -d:release for a release build!

I tried speed, results are the same.

[ozra]

Alright, good to know. Thanks for the effort, and interesting benchmarks!

[brimbur]

Change float to float32, float in nim is float64

[nsf]

Will try that, later today.

[nsf]

That's after I replaced all float to float32 in code.

=== Nim (gcc):
       0,232897480 seconds time elapsed

=== Nim (clang):
       0,158984039 seconds time elapsed

[nsf]

Probably nim just does more float -> double -> float conversions somewhere. I don't know nim, don't know how to make it use float32. If somebody cares and wants to spend some time studying code generated by the nim compiler, patches are welcome.

[ozra]

Mainly using Crystal on a project atm, but, I made a change to the Nim compiler (it's already upstream since a while, so you've probably got it - if you're using devel branch [which you should in on-the-edge langs like these]) that float-literals can be suffixed simply with 'f' to make the literals float32. Not sure if this is automatically optimized in semantics, so moot, but otherwise, if full on 32bit float computations are wanted, use

let myVar = 47f
var foo = 1.0f

etc.