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

11–20 of 48 posts

Re: Make a Lisp in Nim

#11

Post by omaranto »

Dewie wrote: post #7
shared4you wrote: post #4

Are your graphs up to date ? Seems just an hour ago [1]: > Rust: build with --release. 10X performance boost! That might mean that Rust would top the charts instead of Nim. [1]: https://github.com/kanaka/mal/commit/434516e0d172904e06b05f6...

It's weird that people that make benchmarks don't investigate which flags to pass for getting the most optimized build. Many compilers don't do max optimization by default. In particular, people making benchmarks with rust code seem to tend to forget or be unaware of the `release` flag.

That's probably because there is no --release flag:

    $ rustc --release prog.rs
    error: Unrecognized option: 'release'.
There is a -O for optimization, it is equivalent to -C opt-level=2.

EDIT: Oh, cargo build does have a --release which seems to be equivalent to -C opt-level=3, which I guess is even better.

Re: Make a Lisp in Nim

#12

Post by rdtsc »

Dewie wrote: post #7
shared4you wrote: post #4

Are your graphs up to date ? Seems just an hour ago [1]: > Rust: build with --release. 10X performance boost! That might mean that Rust would top the charts instead of Nim. [1]: https://github.com/kanaka/mal/commit/434516e0d172904e06b05f6...

It's weird that people that make benchmarks don't investigate which flags to pass for getting the most optimized build. Many compilers don't do max optimization by default. In particular, people making benchmarks with rust code seem to tend to forget or be unaware of the `release` flag.

Maybe the release flag should be the default?

Re: Make a Lisp in Nim

#13

Post by steveklabnik »

omaranto wrote: post #11
Dewie wrote: post #7

Earlier quoted context omitted.

It's weird that people that make benchmarks don't investigate which flags to pass for getting the most optimized build. Many compilers don't do max optimization by default. In particular, people making benchmarks with rust code seem to tend to forget or be unaware of the `release` flag.

That's probably because there is no --release flag: $ rustc --release prog.rs error: Unrecognized option: 'release'. There is a -O for optimization, it is equivalent to -C opt-level=2. EDIT: Oh, cargo build does have a --release which seems to be equivalent to -C opt-level=3, which I guess is even better.

`cargo build --release` does more than just `-C opt-level=3`, actually. For example a regular `cargo build` also adds `-g`, and that's removed for `--release`.

Re: Make a Lisp in Nim

#14

Post by Dewie »

rdtsc wrote: post #12
Dewie wrote: post #7

Earlier quoted context omitted.

It's weird that people that make benchmarks don't investigate which flags to pass for getting the most optimized build. Many compilers don't do max optimization by default. In particular, people making benchmarks with rust code seem to tend to forget or be unaware of the `release` flag.

Maybe the release flag should be the default?

My preference is to have unoptimized by default, unless there is only a negligible difference in compile-time between the two options. I mostly don't need optimized programs while I'm developing them.

Alternatively, don't have a default and let people opt-in to whatever default they like. That forces people to actually make a choice, instead of being lazy and publishing poor benchmarks without having even looked up what optimization knobs there are to turn on or off.

Re: Make a Lisp in Nim

#15

Post by def- »

e12e wrote: post #10
def- wrote: post #5

Earlier quoted context omitted.

Yes, I updated it already.

Is the lua implementation very new and/or incomplete? It seems to be missing from the benchmarks, and if it's lua 5.1, maybe it'll work with luajit? [ed: Also interesting to note that the clojure version is much slower than scala/java. If nothing else, I guess it's an indication of performance gains that can be had by implementing parts of a clojure program in java (unless there's something off with the clojure imple…

I have no idea, I didn't run the benchmarks. I only have a few of these languages on my system.

Re: Make a Lisp in Nim

#16

Post by kanaka »

Dewie wrote: post #7
shared4you wrote: post #4

Are your graphs up to date ? Seems just an hour ago [1]: > Rust: build with --release. 10X performance boost! That might mean that Rust would top the charts instead of Nim. [1]: https://github.com/kanaka/mal/commit/434516e0d172904e06b05f6...

It's weird that people that make benchmarks don't investigate which flags to pass for getting the most optimized build. Many compilers don't do max optimization by default. In particular, people making benchmarks with rust code seem to tend to forget or be unaware of the `release` flag.

Yeah, the performance benchmarks currently suck. They are neither statistically valid, comprehensive, and often just run with default settings. That was really just a personal notes file that I shared with def- without clarifying that it really wasn't ready for publishing.

Re: Make a Lisp in Nim

#17

Post by kanaka »

steveklabnik wrote: post #9
pcwalton wrote: post #6

Earlier quoted context omitted.

Just one glance at the Rust version (e.g. [1]) shows a lot of needless allocation. For example: if *strn == "&".to_string() { ... } is a very slow (and verbose) way to write if &strn[..] == "&" { ... } and rr_string("'".to_string() + k.to_string() + "' not found".to_string()) is a very slow (and verbose) way to write rr_string(format!("'{}' not found", k))` Etc. etc. [1]: https://github.com/kanaka/mal/blob/master/rus…

It's also using some manual clone instead of Cargo overrides, and manually running rather than `cargo run`... time for some PRs, I guess! EDIT: further, looks like it's on a really old Rust: https://github.com/kanaka/rust-pcre wasn't updated since October... EDIT 2: I tried to update the code, but it's really, really out of date, and will be a ton of work. So I've just submitted https://github.com/kanaka/mal/pull/23…

Well, I'm not going to remove it. But I will see if I can find some time to improve it in the next few days. I've been meaning to cycle back around. Of course, fixes from somebody who's actually a Rust expert would have been preferred :-)

The reason it still uses the alternate pcre is because this still hasn't been fixed: https://github.com/rust-lang/regex/issues/28 I would love to get rid of that nastiness.

Re: Make a Lisp in Nim

#18

Post by steveklabnik »

kanaka wrote: post #17
steveklabnik wrote: post #9

Earlier quoted context omitted.

It's also using some manual clone instead of Cargo overrides, and manually running rather than `cargo run`... time for some PRs, I guess! EDIT: further, looks like it's on a really old Rust: https://github.com/kanaka/rust-pcre wasn't updated since October... EDIT 2: I tried to update the code, but it's really, really out of date, and will be a ton of work. So I've just submitted https://github.com/kanaka/mal/pull/23…

Well, I'm not going to remove it. But I will see if I can find some time to improve it in the next few days. I've been meaning to cycle back around. Of course, fixes from somebody who's actually a Rust expert would have been preferred :-) The reason it still uses the alternate pcre is because this still hasn't been fixed: https://github.com/rust-lang/regex/issues/28 I would love to get rid of that nastiness.

That's a bummer, because until then, you'll be strongly mis-representing Rust :/

Re: Make a Lisp in Nim

#19

Post by kanaka »

pcwalton wrote: post #6
shared4you wrote: post #4

Are your graphs up to date ? Seems just an hour ago [1]: > Rust: build with --release. 10X performance boost! That might mean that Rust would top the charts instead of Nim. [1]: https://github.com/kanaka/mal/commit/434516e0d172904e06b05f6...

Just one glance at the Rust version (e.g. [1]) shows a lot of needless allocation. For example: if *strn == "&".to_string() { ... } is a very slow (and verbose) way to write if &strn[..] == "&" { ... } and rr_string("'".to_string() + k.to_string() + "' not found".to_string()) is a very slow (and verbose) way to write rr_string(format!("'{}' not found", k))` Etc. etc. [1]: https://github.com/kanaka/mal/blob/master/rus…

Thanks for the feedback.

That did seem rather inefficient at the time but I wasn't able to discern the more efficient method at the time. I've kind of been waiting for Rust 1 to cycle back around. But I'll see if I might be able to address some of those and bump to Rust 1.0 alpha in the next few days.

Note the conversation about performance is kind of unfortunate. Those numbers should be considered VERY rough (they were just a personal notes file of mine). Also, with --release, the numbers place rust in the same range as other compiled languages.

Re: Make a Lisp in Nim

#20

Post by kanaka »

steveklabnik wrote: post #18
kanaka wrote: post #17

Earlier quoted context omitted.

Well, I'm not going to remove it. But I will see if I can find some time to improve it in the next few days. I've been meaning to cycle back around. Of course, fixes from somebody who's actually a Rust expert would have been preferred :-) The reason it still uses the alternate pcre is because this still hasn't been fixed: https://github.com/rust-lang/regex/issues/28 I would love to get rid of that nastiness.

That's a bummer, because until then, you'll be strongly mis-representing Rust :/

I'm quite happy to take PRs from an expert to address the issues and represent Rust better. :-)

UPDATE: I will point out that the README is pretty clear that this is rust 0.13. Doesn't mean it's a good representation of rust 0.13 either of course, but it clearly isn't based on a recent version of Rust.

Post reply on HN