nimforum mirror - Amicable numbers in Nim and a few questions

2748 :: Amicable numbers in Nim and a few questions

[2017-01-23T18:57:12+01:00]

View Orginal

petevine (orginal) [2017-01-23T18:57:12+01:00] view original

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

Rust: http://pastebin.com/u2TixCiV

Nim: http://pastebin.com/drhfFJGW

Varriount (orginal) [2017-01-24T09:32:33+01:00] view original

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.

petevine (orginal) [2017-01-24T12:10:21+01:00] view original

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 passed the expanded CFLAGS via --passC automatically in release mode.

Araq (orginal) [2017-01-24T12:16:26+01:00] view original

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.

Jehan (orginal) [2017-01-24T13:03:06+01:00] view original

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 <project>.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)

lltp (orginal) [2017-01-24T16:25:28+01:00] view original

edit: on my computer, a x86_64, Nim's version was running in 0.44 s while C's took 0.13 s. It turned out the difference was cause by C's using int32 while Nim was using raw int (which are int64) in that case.

petevine (orginal) [2017-01-24T20:24:11+01:00] view original

@lltp What problem exactly? Is there a performance hit on 64-bit perhaps?

lltp (orginal) [2017-01-24T22:44:55+01:00] view original

@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!

petevine (orginal) [2017-01-24T23:05:59+01:00] view original

No problem. Anyway it was Rust being slower but that's a throwback to an ARM specific issue that got fixed in LLVM a long time ago here:

http://llvm.org/viewvc/llvm-project?view=revision&revision=259657

lltp (orginal) [2017-01-24T23:53:35+01:00] view original

Oh my... I may need to sleep a wee bit more...

petevine (orginal) [2017-01-25T23:16:44+01:00] view original

<project>.nims config file

Thanks @Jehan, I've just finished reading up on NimScript

petevine (orginal) [2017-04-04T17:02:57+02:00] view original

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

Libman (orginal) [2017-04-10T07:51:22+02:00] view original

I experimented a bit with benchmarking this code (see link for details).

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 (v17.0.2) is MUCH faster on my 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.

def (orginal) [2017-04-10T08:24:54+02:00] view original

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

Mirror of forum.nim-lang.org

2748 :: Amicable numbers in Nim and a few questions