Re: Amicable numbers in Nim and a few questions
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)
Re: Amicable numbers in Nim and a few questions
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 are **421** times those of C / 88x Nim! * Rust's i16 is almost as slow as its i64 - why? * [ICC](https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler) (v17.0.2) is MUCH faster on [my](http://libman.org/notes/hardware/hp-envy-m7-n109dx/20170409-lshw.txt) Intel i7-6500U laptop than GCC (v6.2.0) or LLVM/Clang (v3.9.0). In theory this should give Nim an added advantage over Rust (which is married to LLVM), although I was not yet able to get Nim working with cc=icc.
Re: Amicable numbers in Nim and a few questions
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 --passC:-ftree-vectorize --passC:-fprofile-use' so that building a profiled binary is as simple as, e.g.: $ nim-gen matmul.nim 1500 && nim-use matmul.nim
Re: Amicable numbers in Nim and a few questions
> .nims config file Thanks @Jehan, I've just finished reading up on NimScript
Re: Amicable numbers in Nim and a few questions
Oh my... I may need to sleep a wee bit more...
Re: Amicable numbers in Nim and a few questions
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)
Re: Amicable numbers in Nim and a few questions
@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!
Re: Amicable numbers in Nim and a few questions
@lltp What problem exactly? Is there a performance hit on 64-bit perhaps?
Re: Amicable numbers in Nim and a few questions
In this specific case, the "problem" seems to arise from the use of int instead of int32.
Re: Amicable numbers in Nim and a few questions
**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 = getenv("NIMCFLAGS").split(" ").filter(
proc(x: string): bool = len(x) != 0)
for cflag in cflags:
switch("passC", cflag)
Re: Amicable numbers in Nim and a few questions
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.
Re: Amicable numbers in Nim and a few questions
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.
Re: Amicable numbers in Nim and a few questions
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 always the size of the target architecture's pointer type (32 bits on x86, 64 on x86-64). This can cause disparities in benchmarks. * Putting main code in the global scope of a module prevents certain optimizations. When aiming for optimization, put things in a main procedure. * Profile guided optimization and link time optimization can work really well with regards to speed. Link time optimization also tends to have a significant effect on executable size too. * Depending on how fair you want to be, you can turn off the mark and sweep portion of the garbage collector if you're sure the benchmark doesn't generate any reference cycles. The regular reference counting garbage collector will still run.
Amicable numbers in Nim and a few questions
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 $CFLAGS in release mode, if present, and is there a switch for performing a PGO build automatically? C: [http://pastebin.com/X3ZTp1c0](http://pastebin.com/X3ZTp1c0) Rust: [http://pastebin.com/u2TixCiV](http://pastebin.com/u2TixCiV) Nim: [http://pastebin.com/drhfFJGW](http://pastebin.com/drhfFJGW)
