4 ms·

Eh kind of... The author was talking about a current iteration of the Rust code being suboptimal, not the current one, which the author believed was well-optimi

Eh kind of... The author was talking about a current iteration of the Rust code being suboptimal, not the current one, which the author believed was well-optimized. > The objective is to get the fastest implementation possible, and having optimised Java and Rust implementations to compare against is a motivator to keep going until there really isn’t anything else that can be tried! > Do you think Common Lisp can run as fast as well-optimised Rust? Read on if you want to find out.

dwohnitmok 5y ago
Whoops I meant "previous iteration"
mst 5y ago
That was based on all of the rust feedback the author actually got from rust people who talked to him as opposed to people who complained in HN comments. Hence if you want it to get even better you should provide feedback to the author, and while I absolutely respect your right to decide you can't be bothered, I don't think it's his fault that he's using code that was well-optimized according to the rustaceans who -did- talk to him.
- dwohnitmok 5y ago
  Oh I'm sure there's a better way to give the author feedback than sniping in HN comments. I'm reacting to your comment here: > The author was pretty explicit in the article that the rust implementation was suboptimal. This is not the way the article portrays it.
  - mst 5y ago
    Perhaps you missed the part where he said you'd need to rewrite it to use a trie to get a properly optimised one?
    - dwohnitmok 5y ago
      That's only vis-a-vis the Main.java Java implementation, which has a different algorithm, not implementation. The author is not referring to the CL implementation (note that the author explicitly calls out Main2.java, CL, and the Rust versions as being the most similar and worthy of being benchmarked). The Main.java one is more of a curio than anything else, which the author threw in because it was the first implementation they wrote (the article acknowledges it has a different algo and is therefore not directly comparable to the other two). This is not what the author is referring to when they say "well-optimised" (note that the article explicitly excludes Main.java from a lot of its valid comparisons, e.g. "Because the Rust code implements a similar algorihm to Java’s Main2, NOT Main, we should not conclude that Java can beat Rust in speed!") The main comparison of the article is Main2.java, main.rs, and main.lisp, as the author both calls out in the article and the attached GitHub repo (as is apparent in the author's choice of optimizations; if it was a comparison of algos, then the CL and Rust versions would be rewritten to use tries as well). The point is the author did not explicitly call out this current Rust iteration as explicitly suboptimal RE CL. The closest the article comes to calling the Rust iteration suboptimal is > However, the Java and Rust implementations were, as CL’s, written without much thought given to performance, after all the description of the original study which introduced the problem asked participants to focus on correctness and readability, not performance. which is referring to the previous iteration of the code, not the current one. (It's also evident from Cryptonic and chrismorgan's comments they are talking about implementation-level concerns, not algo-level ones such as Main2.java vs the other implementations)
      - mst 5y ago
        Fair enough. I stand by that so far as I can tell he incorporated every implementation optimisation he got as feedback, but you're dead right that I didn't represent his wording correctly.
      - brabel 5y ago
        There are two or three branches with different versions of the Rust code, and the author is using the fastest one. What you believe will make the Rust code faster won't, trust me. If you think I'm wrong, could you please submit a PR and link here? @Cryptonic 's suggestions are laughable. Try using arrays as HashMap keys in Rust :D nope, won't even compile let alone be fast. There was a way smarter attempt here to do something *based on* arrays: https://github.com/renatoathaydes/prechelt-phone-number-encoding/commit/c93a961d30144f2fd8469b767f6a853df82b9fc9 https://github.com/renatoathaydes/prechelt-phone-number-enco... The DigitBytes struct is needed because just using arrays (I guess they mean slices, as arrays are obviously wrong) is incredibly slow - it would need to consider the whole array every time instead of just the relevant bytes - far slower than `Vec`. This is indeed fast, but slower than Vec. The other suggestion: print everything at the end?? Do we even know what the objective is here? It's not to finish first, but to show to the user the results as soon as possible. It's like people don't even read the problem proposition and still think it's ok to criticize... also, Rust is using buffered IO... ALSO, the benchmark only prints a single line at the end for the two last runs, essentially doing "print it all at the end".

dwohnitmok 5y ago

Whoops I meant "previous iteration"

mst 5y ago

That was based on all of the rust feedback the author actually got from rust people who talked to him as opposed to people who complained in HN comments. Hence if you want it to get even better you should provide feedback to the author, and while I absolutely respect your right to decide you can't be bothered, I don't think it's his fault that he's using code that was well-optimized according to the rustaceans who -did- talk to him.

dwohnitmok 5y ago
Oh I'm sure there's a better way to give the author feedback than sniping in HN comments. I'm reacting to your comment here: > The author was pretty explicit in the article that the rust implementation was suboptimal. This is not the way the article portrays it.
- mst 5y ago
  Perhaps you missed the part where he said you'd need to rewrite it to use a trie to get a properly optimised one?
  - dwohnitmok 5y ago
    That's only vis-a-vis the Main.java Java implementation, which has a different algorithm, not implementation. The author is not referring to the CL implementation (note that the author explicitly calls out Main2.java, CL, and the Rust versions as being the most similar and worthy of being benchmarked). The Main.java one is more of a curio than anything else, which the author threw in because it was the first implementation they wrote (the article acknowledges it has a different algo and is therefore not directly comparable to the other two). This is not what the author is referring to when they say "well-optimised" (note that the article explicitly excludes Main.java from a lot of its valid comparisons, e.g. "Because the Rust code implements a similar algorihm to Java’s Main2, NOT Main, we should not conclude that Java can beat Rust in speed!") The main comparison of the article is Main2.java, main.rs, and main.lisp, as the author both calls out in the article and the attached GitHub repo (as is apparent in the author's choice of optimizations; if it was a comparison of algos, then the CL and Rust versions would be rewritten to use tries as well). The point is the author did not explicitly call out this current Rust iteration as explicitly suboptimal RE CL. The closest the article comes to calling the Rust iteration suboptimal is > However, the Java and Rust implementations were, as CL’s, written without much thought given to performance, after all the description of the original study which introduced the problem asked participants to focus on correctness and readability, not performance. which is referring to the previous iteration of the code, not the current one. (It's also evident from Cryptonic and chrismorgan's comments they are talking about implementation-level concerns, not algo-level ones such as Main2.java vs the other implementations)
    - mst 5y ago
      Fair enough. I stand by that so far as I can tell he incorporated every implementation optimisation he got as feedback, but you're dead right that I didn't represent his wording correctly.
    - brabel 5y ago
      There are two or three branches with different versions of the Rust code, and the author is using the fastest one. What you believe will make the Rust code faster won't, trust me. If you think I'm wrong, could you please submit a PR and link here? @Cryptonic 's suggestions are laughable. Try using arrays as HashMap keys in Rust :D nope, won't even compile let alone be fast. There was a way smarter attempt here to do something *based on* arrays: https://github.com/renatoathaydes/prechelt-phone-number-encoding/commit/c93a961d30144f2fd8469b767f6a853df82b9fc9 https://github.com/renatoathaydes/prechelt-phone-number-enco... The DigitBytes struct is needed because just using arrays (I guess they mean slices, as arrays are obviously wrong) is incredibly slow - it would need to consider the whole array every time instead of just the relevant bytes - far slower than `Vec`. This is indeed fast, but slower than Vec. The other suggestion: print everything at the end?? Do we even know what the objective is here? It's not to finish first, but to show to the user the results as soon as possible. It's like people don't even read the problem proposition and still think it's ok to criticize... also, Rust is using buffered IO... ALSO, the benchmark only prints a single line at the end for the two last runs, essentially doing "print it all at the end".