> Are you on Mac OS X by chance? We're calling c stdlib function for pow and
> they may be significantly faster.
Yes, but that wouldn't explain the faster Julia code (and if it did, it
wouldn't explain the difference between Julia and Nim that others are
observing).
Indeed could this be a library issue, I get ~4.5x faster results if I link to
musl instead of glibc.
Maybe you have some special Nim settings in your nim.cfg, Jehan? For me it's
~3.5 seconds with an i7 6700k for both gcc-5 and clang. Or are you using an
older Nim release? I'm running the current devel branch. **Are you on Mac OS X
by chance? We're calling c stdlib function for pow and they may
@zolem: Ah, ok, then I didn't understand you correctly that time.
@LeuGim I mean that LLVM/clang's pow is much faster than gcc's pow and not just
in this particular case pow(-1, n), but is faster in general.
This is no longer Nim's problem, but just for fun, (short of importing
intrinsics)
{.passc:"-march=native".}
import times, math
proc leibniz0(terms: int): float =
var res = 0.0
for n in 0..terms:
res += pow(-1,float(n))/(2*float(n)+1)
4*res
@zolern:
My point was exactly that the library function is NOT to be considered as bad
implemetned for not optimizing this case. Such optimizations come with cost
(additional runtime checks), yet at least they have a cost of implementing them
(their developers effort/time), so all possible
Using exponentiation just for interlacing 1, -1, 1, -1, ... is pointless (apart
from mathematical formulas on paper) and should not be done, so no matter if
some compiler optimizes it.
Our **lovely Nim** is outstanding !
I am pretty sure that Julias's POW takes care that first argument is -1 and
optimized it with something like MOD You can check it, I suppose that modified
Julia code with MOD will take pretty same time as code with POW.
@zolern, thank you. Your code rocks.
However, we are cheating Julia because in her code there is a **POW** instead
**MOD**.
I will modify / rerun the .jl script just to check the result.
Well, my 10 cents
import times, math
proc leibniz(terms: int): float =
var res = 0.0
for n in 0..terms:
res = res + (if n mod 2 == 0: 1.0 else: -1.0) / float(2 * n + 1)
return 4*res
let t0 = cpuTime()
It seems that Julia JIT is aware of SSE extensions and it uses them. GCC or
MSVC should be emitting them too, but it depends on C code
Thank you all.
@wiffel/Nibbler, in my Julia test, I was using Pro version 0.6.1 64 bit running
on Windows 10.
Now, running the same .jl code on a Windows 8 64 bit (i5 CPU 650 @ 3.20GHz,
3193 Mhz, 2 Cores, 4 Processors) I got the following:
2.763225 seconds (1.77 k allocations:
I compiled the same approximate version to C with gcc optimisations on, and
found the execution time to be roughly comparable between Nim and C. Could
Julia's JIT be doing some sort of optimisation that shortcuts the full code
somehow?
With the Nim version:
import times, math
@alfrednewman
I tried to replicate your test. On my computer the following (slightly modified
version) of the _nim_ program and the _julia_ program have the same runtime.
Whatever I do, I fail to run the _julia_ version in less than 2 seconds (as you
had). Are you sure that test went OK?
At least so: `res += float([1,-1][n mod 2])/(2.0*float(n)+1.0)`.
That call to `pow` to change sign may be a possible reason of slowdown.
Hello,
How can I optimize the speed of the following proc:
import times, math
proc leibniz(terms: int): float =
var res = 0.0
for n in 0..terms:
res += pow(-1.0,float(n))/(2.0*float(n)+1.0)
return 4*res
let t0 = cpuTime()
19 matches
Mail list logo
