3 ms·
For reference, here is (who I presume is) Mr Anderson's top-voted reply on the HN thread discussing the original article: https://news.ycombinator.com/item?id
by n4r9 2y ago
For reference, here is (who I presume is) Mr Anderson's top-voted reply on the HN thread discussing the original article:
https://news.ycombinator.com/item?id=42585375 https://news.ycombinator.com/item?id=42585375
Aside: the original question begins "Given a list of 1 million random integers...". For me, this suggests that we ought to be benchmarking from the point after the random numbers have been generated. I don't know how easy this benchmarking is to do in Rust, but I know how I would do it in dotnet using something like BenchmarkDotNet.
- stefs 2y agoi agree that excluding the test data generation from the test should have been required. additionally, the original task should have been formulated much more general, i.e: Given a function that takes a list of n random integers between x and y, find the difference between the smallest and the largest numbers whose digits sum up to m. then define the parameter values for testing and performance evaluation. that should have prevented at least some of the proposed compile time optimizations. edit: i'm aware though that the performance characteristics might be very different depending on the value of "n", especially when it comes to multithreading, so there should be a clause for that (e.g. n usually > 1m).
- dgacmu 2y agoYup, that was my comment / I'm the author of the blog post. The discussion here inspired me to do the study more carefully and turn it into a longer post. I think it's fair to leave the random generation in or out, really, as long as we're still comparing apples to apples. But I agree with you that it probably would have made the benchmarking more clear had I left them out.