5 ms·

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147 https://news.ycombinat

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147 https://news.ycombinator.com/item?id=23058147

manaskarekar 6y ago
While Go may be faster somewhere, that post was not a good comparison. See the discussion around it and the patches made by the community and the final results. See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-benchmarks/pulls https://github.com/christianscott/levenshtein-distance-bench...
- Tuna-Fish 6y ago
  And just to help the lazy people, after making the benchmarked loads equivalent, the results are: hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out Time (mean ± σ): 1.888 s ± 0.013 s [User: 2.040 s, System: 0.045 s] Range (min … max): 1.875 s … 1.918 s 10 runs Benchmark #2: node javascript/main.js Time (mean ± σ): 4.257 s ± 0.033 s [User: 4.295 s, System: 0.042 s] Range (min … max): 4.221 s … 4.338 s 10 runs Benchmark #3: rust/target/release/rust Time (mean ± σ): 874.1 ms ± 50.8 ms [User: 5.688 s, System: 0.830 s] Range (min … max): 813.5 ms … 1001.9 ms 10 runs Summary 'rust/target/release/rust' ran 2.16 ± 0.13 times faster than 'go/out' 4.87 ± 0.29 times faster than 'node javascript/main.js'
  - burntsushi 6y ago
    It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-benchmarks/pull/8 https://github.com/christianscott/levenshtein-distance-bench... That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.
  - hu3 6y ago
    The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.
GolDDranks 6y ago
Rust is usually faster than Go. Note the edit in the previous post.
- mesaframe 6y ago
  Well, I would say it's faster than Go almost every time.
melling 6y ago
I don’t think that was the conclusion. “ as some keen HN commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop.”
nindalf 6y ago
I don't think it is. The top comment in that thread indicates why. In general for most long lived workloads, I would expect Go to be approximately 15-25% slower than an equivalent C/C++/Rust program because of the CPU overhead of the Go GC. The Go team have done a lot of great work to optimize pause times and memory consumption though.
empath75 6y ago
As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extremely slow code in rust than it is in go, but once you start optimizing, rust will generally be faster, sometimes by quite a lot. I’ve also run into fewer pathological cases as I’ve learned more of the idiomatic rust patterns.
- rat9988 6y ago
  >it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.
  - baq 6y ago
    likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.
    - empath75 6y ago
      Yeah it’s definitely around using clones everywhere.
      - masklinn 6y ago
        I don't know that clones are problems in and of themselves rather than what they do behind the scenes: allocations. Cloning an Rc is completely innocent, cloning a HashMap<String, Vec<String>> is deadly in a way you may not expect if you're used to shallow-copying hashmaps (or even deep-copying them). And it's true that if you think of allocations as being no big deal unless you're aiming for very high performance, your Rust is going to be slow (also your C++ and your C).
- jdub 6y ago
  And yet, a lot of experienced programmers have noted that even when they write their first time naïve Rust, it turns out to be really fast.
deleted 6y ago
[deleted]
rusty_sheep 6y ago
Rust good, Go bad.

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147 https://news.ycombinator.com/item?id=23058147

manaskarekar 6y ago

While Go may be faster somewhere, that post was not a good comparison. See the discussion around it and the patches made by the community and the final results. See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-benchmarks/pulls https://github.com/christianscott/levenshtein-distance-bench...

Tuna-Fish 6y ago
And just to help the lazy people, after making the benchmarked loads equivalent, the results are: hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out Time (mean ± σ): 1.888 s ± 0.013 s [User: 2.040 s, System: 0.045 s] Range (min … max): 1.875 s … 1.918 s 10 runs Benchmark #2: node javascript/main.js Time (mean ± σ): 4.257 s ± 0.033 s [User: 4.295 s, System: 0.042 s] Range (min … max): 4.221 s … 4.338 s 10 runs Benchmark #3: rust/target/release/rust Time (mean ± σ): 874.1 ms ± 50.8 ms [User: 5.688 s, System: 0.830 s] Range (min … max): 813.5 ms … 1001.9 ms 10 runs Summary 'rust/target/release/rust' ran 2.16 ± 0.13 times faster than 'go/out' 4.87 ± 0.29 times faster than 'node javascript/main.js'
- burntsushi 6y ago
  It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-benchmarks/pull/8 https://github.com/christianscott/levenshtein-distance-bench... That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.
- hu3 6y ago
  The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.

GolDDranks 6y ago

Rust is usually faster than Go. Note the edit in the previous post.

mesaframe 6y ago
Well, I would say it's faster than Go almost every time.

melling 6y ago

I don’t think that was the conclusion. “ as some keen HN commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop.”

nindalf 6y ago

I don't think it is. The top comment in that thread indicates why. In general for most long lived workloads, I would expect Go to be approximately 15-25% slower than an equivalent C/C++/Rust program because of the CPU overhead of the Go GC. The Go team have done a lot of great work to optimize pause times and memory consumption though.

empath75 6y ago

As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extremely slow code in rust than it is in go, but once you start optimizing, rust will generally be faster, sometimes by quite a lot. I’ve also run into fewer pathological cases as I’ve learned more of the idiomatic rust patterns.

rat9988 6y ago
>it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.
- baq 6y ago
  likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.
  - empath75 6y ago
    Yeah it’s definitely around using clones everywhere.
    - masklinn 6y ago
      I don't know that clones are problems in and of themselves rather than what they do behind the scenes: allocations. Cloning an Rc is completely innocent, cloning a HashMap<String, Vec<String>> is deadly in a way you may not expect if you're used to shallow-copying hashmaps (or even deep-copying them). And it's true that if you think of allocations as being no big deal unless you're aiming for very high performance, your Rust is going to be slow (also your C++ and your C).
jdub 6y ago
And yet, a lot of experienced programmers have noted that even when they write their first time naïve Rust, it turns out to be really fast.

deleted 6y ago

[deleted]

rusty_sheep 6y ago

Rust good, Go bad.