Last I tested ICC worked with --cc:gcc --gcc.exe:icc --gcc.linkerexe:icc (but I
see some ICC defines now, so that might have changed) Some work for
auto-vectorization was still needed though:
[https://github.com/nim-lang/Nim/issues/1797](https://github.com/nim-lang/Nim/issues/1797)
I [experimented a bit with benchmarking this code (see link for
details)](https://github.com/lbmn/nim/tree/master/bench/amicableInt).
Some observations:
* Rust (v1.16.0) is slower than Nim (v0.16.0) on all int sizes except i32,
where it takes off at the speed of Clang.
* Rust binary sizes
I eventually settled for plain aliases:
alias nim-gen='nim c -r -d:release --passC:-mcpu=cortex-a5
--passC:-mfpu=neon --passC:- ftree-vectorize --passC:-fprofile-generate
--passL:-lgcov'
alias nim-use='nim c -d:release --passC:-mcpu=cortex-a5 --passC:-mfpu=neon
> .nims config file
Thanks @Jehan, I've just finished reading up on NimScript
Oh my... I may need to sleep a wee bit more...
No problem. Anyway it was Rust being slower but that's an ARM specific bug that
should have been fixed a long time ago here:
[http://llvm.org/viewvc/llvm-project?view=revision=259657](http://llvm.org/viewvc/llvm-project?view=revision=259657)
@petevine: oops... well, I read the post and the answers this morning and then
I noticed that Nim's version was twice as slow. I got back to it this evening
and completely forgot that this was absolutely not the question here but only
something I was curious about. Sorry about that!
@lltp What problem exactly? Is there a performance hit on 64-bit perhaps?
In this specific case, the "problem" seems to arise from the use of int instead
of int32.
**petevine:** _It would be good for usability if the nim compiler offered
automated profiled builds as well as pass the expanded CFLAGS via --passC
automatically in release mode._
You can do this via a `.nims` config file, e.g.:
import strutils, sequtils
let cflags =
But I don't like environment variables, they are global shared state affecting
the build environment... No thanks, it's already hard enough to figure out
which set of options is passed to anything.
C compilers don't expand shell variables so the short answer to my questions
seems to be no and no, use --passC
It would be good for usability if the nim compiler offered automated profiled
builds as well as pass the expanded CFLAGS via --passC automatically in release
mode.
The Nim compiler knows nothing about CFLAGS and related things, however the C
compiler it uses should (if you're using GCC or Clang). You can also pass in
arguments via `--passC` and `--passL` arguments.
When benchmarking, it's good to remember some things:
* Nim's `int` datatype is
I've translated the Euler problem #21 solution (C and Rust versions lifted off
the net) to Nim and benchmarked the binary.
Time to solution for C/Nim/Rust on my Cortex A5 cpu:
1.5s/1.5s/2.5s
Two questions about compiling the generated C immediately spring to mind.
Does the nim compiler use
14 matches
Mail list logo
