Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
renato.athaydes.com
Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
1–10 of 26 posts
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#2The Rust code is bar far not optimized. For example while loading the dictionary, why creating a Vec and returning it instead of operating on a max word size array and reusing it. Also why not write everything at the end. I'm not a Rust Professional also, but maybe get a review by one please before benchmarking against something else.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#3The Rust code is bar far not optimized. For example while loading the dictionary, why creating a Vec and returning it instead of operating on a max word size array and reusing it. Also why not write everything at the end. I'm not a Rust Professional also, but maybe get a review by one please before benchmarking against something else.
Another point where it’s doing something that to me as a Rust expert is obviously inferior: it’s using Unicode-aware string stuff although anything non-ASCII will either be ignored (if non-alphabetic) or panic (if alphabetic). It’d certainly be better to treat the input throughout the program as a sequence of bytes rather than as UTF-8.
This type of thing reminds me of the three articles ending in https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry... (which has links to the first two parts of the saga), where one guy rewrote stuff in Rust for performance, another demonstrated how it was possible to make the JavaScript version faster than the Rust by some algorithm changes and by various painful and fragile tricks requiring detailed knowledge of the runtime environment, and finally the first guy applied the applicable parts of that back to the Rust, after which it handily beat the JavaScript again while also being more consistent and dependable.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#4The Rust code is bar far not optimized. For example while loading the dictionary, why creating a Vec and returning it instead of operating on a max word size array and reusing it. Also why not write everything at the end. I'm not a Rust Professional also, but maybe get a review by one please before benchmarking against something else.
Another point where it’s doing something that to me as a Rust expert is obviously inferior: it’s using Unicode-aware string stuff although anything non-ASCII will either be ignored (if non-alphabetic) or panic (if alphabetic). It’d certainly be better to treat the input throughout the program as a sequence of bytes rather than as UTF-8. This type of thing reminds me of the three articles ending in https://fitzgeraldn…
The author was pretty explicit in the article that the rust implementation was suboptimal.
I'm sure if you submitted a better implementation he'd be happy to add it in.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#5Earlier quoted context omitted.
Another point where it’s doing something that to me as a Rust expert is obviously inferior: it’s using Unicode-aware string stuff although anything non-ASCII will either be ignored (if non-alphabetic) or panic (if alphabetic). It’d certainly be better to treat the input throughout the program as a sequence of bytes rather than as UTF-8. This type of thing reminds me of the three articles ending in https://fitzgeraldn…
The author was pretty explicit in the article that the rust implementation was suboptimal. I'm sure if you submitted a better implementation he'd be happy to add it in.
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.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#6There are a lot of interesting comments in the Lisp subreddit regarding the second part of the blog: https://www.reddit.com/r/lisp/comments/q5f7u5/revenge_of_lis...
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#7And here come the Rust fan boys telling us the correct way to write the code so it will be faster than anything ever written, much safer than anything ever written and better than any programming language ever written.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#8And here come the Rust fan boys telling us the correct way to write the code so it will be faster than anything ever written, much safer than anything ever written and better than any programming language ever written.
Refer to my other comment here and the cited articles for a fair rebuttal: Rust lets you get equivalent or better performance (than Common Lisp or Java, in this instance) without significant special effort or deep knowledge of the environment, while being much more predictable; and if you do apply deeper knowledge of the language, then it’ll pull well ahead.
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#9In case anyone else is wondering what the author means by "phone encoding": it's an algorithm trying to map telephone numbers to words (via the letters usually printed on telephone keypads). Would have been better to call it "phone number encoding" IMHO...
Re: Optimising Common Lisp to try and beat Java and Rust on phone encoding 2/2
#10Those are pretty impressive results for what didn't amount to a huge amount of changes (mostly just adding some types).