Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make a Lisp in Nim

hookrace.net

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Make a Lisp in Nim

#31

Post by Dewie »

pcwalton wrote: post #30
ilaksh wrote: post #29

Earlier quoted context omitted.

So get your Rust buddies together and fix it or rewrite it in the new apparently totally different Rust that has come out since October. Apparently this will require more than half an hour of one person's time. Or maybe it will take a week? Until then we only have this one representation for this case study, and it is a 100% valid representation of the reality of Rust development and Rust code. The fact that you trie…

> But you know, deep down, its still going to be relatively slow and massively verbose. Why do you think it will be slow?

Don't feed the troll. :) He obviously has an axe to grind and isn't looking to have a rational discussion. He even chose to take the good fight to Github, on Steve's pull request to the kanaka/mal repo.

Re: Make a Lisp in Nim

#32

Post by jeremycw »

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.

Re: Make a Lisp in Nim

#33

Post by chadzawistowski »

jeremycw wrote: post #32

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.

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.

Re: Make a Lisp in Nim

#34

Post by username223 »

chadzawistowski wrote: post #33
jeremycw wrote: post #32

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.

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.

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.

Re: Make a Lisp in Nim

#35

Post by tel »

jeremycw wrote: post #32

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.

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

Re: Make a Lisp in Nim

#36

Post by jlarocco »

tel wrote: post #35
jeremycw wrote: post #32

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.

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 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 a…

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.

Re: Make a Lisp in Nim

#37

Post by TheLoneWolfling »

tel wrote: post #35
jeremycw wrote: post #32

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.

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 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 a…

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.

Re: Make a Lisp in Nim

#38

Post by jlarocco »

jeremycw wrote: post #32

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.

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.

Re: Make a Lisp in Nim

#39

Post by [deleted] »

Dewie wrote: post #31
pcwalton wrote: post #30

Earlier quoted context omitted.

> But you know, deep down, its still going to be relatively slow and massively verbose. Why do you think it will be slow?

Don't feed the troll. :) He obviously has an axe to grind and isn't looking to have a rational discussion. He even chose to take the good fight to Github, on Steve's pull request to the kanaka/mal repo.

[deleted]

Re: Make a Lisp in Nim

#40

Post by tel »

jlarocco wrote: post #36
tel wrote: post #35

Earlier quoted context omitted.

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 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 a…

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.

Freudian slip, I meant "C version". It was only meant to illustrate.
Post reply on HN