5 ms·

I have different times for both naive solutions on my machine than you. It's 2.6 seconds for Go and 3.5 seconds for Rust, both perf results and code here: http

by lossolo 10y ago

I have different times for both naive solutions on my machine than you. It's 2.6 seconds for Go and 3.5 seconds for Rust, both perf results and code here: http://pastebin.com/WwhvHH6S http://pastebin.com/WwhvHH6S

burntsushi 10y ago
Your Rust program corresponds to my second Rust program. Your Go program is not what I would expect. A bufio.Scanner is the idiomatic (and naive) way to read lines in Go. But this is immaterial. Your results are consistent with mine. They aren't different. I just included more analysis and more programs to provide proper context to this challenge of yours.
- lossolo 10y ago
  I gave you naive solution, now lets see amateurish solution (someone totally new to both languages) Rust 4.6s Go 3.1s http://pastebin.com/r6K22Dt2 http://pastebin.com/r6K22Dt2 EDIT: Using grep 0.6s Then I have installed rigrep and... Using ripgrep 0.4s Really nice burntsushi. I am surprised by those (ripgrep) results compared to grep.
  - mmstick 10y ago
    Seems I can't reply to your other comment, so I'll reply here. How can you say that my naive implementation is not naive? What is not naive about it? It's very naive. It's basically the same naive code that you were writing, but in actual idiomatic Rust with the linting issues fixed. Using a `lines()` approach is naive because that allocates owned heap-allocated strings. An optimal, non-naive solution would not use heap allocation for buffering lines but use a stack-allocated array. That alone would bring significant speedup versus the line approach. As for ripgrep, it's a pretty comprehensive application that makes use of SIMD/AVX so it's only natural that it's fast.
    - lossolo 10y ago
      Your solution is not naive in my opinion because you set the size of the buffer and use map/filter but ok... Let's check. Your solution is the slowest from all the solutions. It took 4.6s which only confirms what I wrote on beginning when we started this discussion. Perf counters for your solution in here: http://pastebin.com/Anak1ahe http://pastebin.com/Anak1ahe
deleted 10y ago
[deleted]
mmstick 10y ago
Your Rust example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust. https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b916ca1 https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91... As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabling LTO, setting O3, disabling jemalloc, and using the musl target. All these things can make significant differences to the performance of the binary that's produced.
- lossolo 10y ago
  I don't know if you noticed but we are discussing naive solutions which I've mentioned couple of times in previous posts. Code you linked is not naive solution. Things you proposed to do are not naive either.
  - AsyncAwait 10y ago
    Here's the thing; it is a naive solution. You may not want to accept it because that contradicts your claim of the Go solution being faster, but at that point it becomes a he-said/she-said kind of scenario because I can claim that your Go solution isn't naive as well and have exactly the same "validity" for such a claim as you do.
    - lossolo 10y ago
      Anyway this really doesn't matter as his solution is the slowest of all which confirms what I wrote and contradicts what he wrote. For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution? I know I can't. For everyone naive solution is something different, what I saw in burntsushi reply and what I wrote myself is the closest to what I think are naive solutions. > like enabling LTO, setting O3, disabling jemalloc, and using the musl target. And this is for sure not part of naive solution either. > You may not want to accept it because that contradicts your claim of the Go solution being faster This is not true. You can find perf numbers of his solution in my second reply to him. Or you can compare those solutions yourself.

by lossolo 10y ago

burntsushi 10y ago

Your Rust program corresponds to my second Rust program. Your Go program is not what I would expect. A bufio.Scanner is the idiomatic (and naive) way to read lines in Go. But this is immaterial. Your results are consistent with mine. They aren't different. I just included more analysis and more programs to provide proper context to this challenge of yours.

lossolo 10y ago
I gave you naive solution, now lets see amateurish solution (someone totally new to both languages) Rust 4.6s Go 3.1s http://pastebin.com/r6K22Dt2 http://pastebin.com/r6K22Dt2 EDIT: Using grep 0.6s Then I have installed rigrep and... Using ripgrep 0.4s Really nice burntsushi. I am surprised by those (ripgrep) results compared to grep.
- mmstick 10y ago
  Seems I can't reply to your other comment, so I'll reply here. How can you say that my naive implementation is not naive? What is not naive about it? It's very naive. It's basically the same naive code that you were writing, but in actual idiomatic Rust with the linting issues fixed. Using a `lines()` approach is naive because that allocates owned heap-allocated strings. An optimal, non-naive solution would not use heap allocation for buffering lines but use a stack-allocated array. That alone would bring significant speedup versus the line approach. As for ripgrep, it's a pretty comprehensive application that makes use of SIMD/AVX so it's only natural that it's fast.
  - lossolo 10y ago
    Your solution is not naive in my opinion because you set the size of the buffer and use map/filter but ok... Let's check. Your solution is the slowest from all the solutions. It took 4.6s which only confirms what I wrote on beginning when we started this discussion. Perf counters for your solution in here: http://pastebin.com/Anak1ahe http://pastebin.com/Anak1ahe

deleted 10y ago

[deleted]

mmstick 10y ago

Your Rust example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust. https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b916ca1 https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91... As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabling LTO, setting O3, disabling jemalloc, and using the musl target. All these things can make significant differences to the performance of the binary that's produced.

lossolo 10y ago
I don't know if you noticed but we are discussing naive solutions which I've mentioned couple of times in previous posts. Code you linked is not naive solution. Things you proposed to do are not naive either.
- AsyncAwait 10y ago
  Here's the thing; it is a naive solution. You may not want to accept it because that contradicts your claim of the Go solution being faster, but at that point it becomes a he-said/she-said kind of scenario because I can claim that your Go solution isn't naive as well and have exactly the same "validity" for such a claim as you do.
  - lossolo 10y ago
    Anyway this really doesn't matter as his solution is the slowest of all which confirms what I wrote and contradicts what he wrote. For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution? I know I can't. For everyone naive solution is something different, what I saw in burntsushi reply and what I wrote myself is the closest to what I think are naive solutions. > like enabling LTO, setting O3, disabling jemalloc, and using the musl target. And this is for sure not part of naive solution either. > You may not want to accept it because that contradicts your claim of the Go solution being faster This is not true. You can find perf numbers of his solution in my second reply to him. Or you can compare those solutions yourself.