3 ms·

Can someone explain the huge performance difference between nim and C? I though nim compiled to C, therefore I would think that good handwritten C would more or

Can someone explain the huge performance difference between nim and C? I though nim compiled to C, therefore I would think that good handwritten C would more or less be the upper performance bound for nim.

chadzawistowski 12y ago
One explanation could be "sufficiently advanced compilers". Reread your sentence in the context of C/asm: Can someone explain the huge performance difference between C and assembly? I though C compiled to assembly, therefore I would think that good handwritten assembly would more or less be the upper performance bound for C.
- username223 12y ago
  I agree with what you wrote: "I would think that good handwritten assembly would more or less be the upper performance bound for C." I doubt a good C (or assembly) programmer has bothered to play this particular benchmark game, so the results look strange.
tel 12y ago
Here's a similar, comically pathological, example: "Haskell compiles to C therefore good, handwritten C ought to upper bound performance for Haskell" main :: IO () main = do x <- return ([1..100000001] !! 100000000) putStrLn "done" As Haskell is lazy and pure it "automatically" eliminates the `x` and returns nearly immediately avoiding all work. The correspondingly written C code would do much more work despite its waste. Of course, the human writing the C version might automatically perform this optimization, but similar things can arise in far less obvious locations in a more genuine compilation.
- jlarocco 12y ago
  I'm not sure that distinction matters. Any C compiler worth using will optimize out 'x' in that case. The details of why (laziness vs code analysis saying it's unused) is pretty much irrelevant. Saying "the human writing the C compiler" is an odd way to put it. It's "the human writing the Haskell compiler" deciding it shouldn't be evaluated in Haskell, too. Totally meaningless distinction.
  - tel 12y ago
    Freudian slip, I meant "C version". It was only meant to illustrate.
- TheLoneWolfling 12y ago
  Please elaborate. I don't see the difference between the person writing the compiler implementing laziness and the person writing the compiler implementing unused value removal.
jlarocco 12y ago
It's possible "good handwritten C" might be assuming too much. It looks like the C version is using GLib for hash tables and data structures, and it's possible that Nim's library is simpler and faster. There could be a lot of reasons.

chadzawistowski 12y ago

One explanation could be "sufficiently advanced compilers". Reread your sentence in the context of C/asm: Can someone explain the huge performance difference between C and assembly? I though C compiled to assembly, therefore I would think that good handwritten assembly would more or less be the upper performance bound for C.

username223 12y ago
I agree with what you wrote: "I would think that good handwritten assembly would more or less be the upper performance bound for C." I doubt a good C (or assembly) programmer has bothered to play this particular benchmark game, so the results look strange.

tel 12y ago

Here's a similar, comically pathological, example: "Haskell compiles to C therefore good, handwritten C ought to upper bound performance for Haskell" main :: IO () main = do x <- return ([1..100000001] !! 100000000) putStrLn "done" As Haskell is lazy and pure it "automatically" eliminates the `x` and returns nearly immediately avoiding all work. The correspondingly written C code would do much more work despite its waste. Of course, the human writing the C version might automatically perform this optimization, but similar things can arise in far less obvious locations in a more genuine compilation.

jlarocco 12y ago
I'm not sure that distinction matters. Any C compiler worth using will optimize out 'x' in that case. The details of why (laziness vs code analysis saying it's unused) is pretty much irrelevant. Saying "the human writing the C compiler" is an odd way to put it. It's "the human writing the Haskell compiler" deciding it shouldn't be evaluated in Haskell, too. Totally meaningless distinction.
- tel 12y ago
  Freudian slip, I meant "C version". It was only meant to illustrate.
TheLoneWolfling 12y ago
Please elaborate. I don't see the difference between the person writing the compiler implementing laziness and the person writing the compiler implementing unused value removal.

jlarocco 12y ago

It's possible "good handwritten C" might be assuming too much. It looks like the C version is using GLib for hash tables and data structures, and it's possible that Nim's library is simpler and faster. There could be a lot of reasons.