4 ms·
1. Looping with a floating point increment is silly here because you can't be sure how many iterations it takes. 2. C translation takes 11 seconds (compare to
by jedbrown 17y ago
1. Looping with a floating point increment is silly here because you can't be sure how many iterations it takes.
2. C translation takes 11 seconds (compare to 25.6 for SBCL)
http://gist.github.com/288936#file_silly http://gist.github.com/288936#file_silly distance loop
- pvg 17y agoChanging the loop indexes to integers is sillier because it makes the program not only different from the original one but also slower.
- jedbrown 17y agoIncorrect code is silly. It is not unlikely that the different languages are performing a different number of iterations in these tests, correcting that by being precise about the range to be iterated over is not silly. The integer indices here produce the behavior that seems to be intended by the `<=` comparison in the originals. The speed difference is negligible since all but the inner multiplication is hoisted out, and each inner loop takes over 250 cycles.
- pvg 17y agoThe speed difference is hardly negligible especially when talking about benchmarks. It's actually about 15% on my OS X laptop, less but still measurable on a Linux server. Your change actually has a greater impact on execution time than off-by-ones in the iteration counts which don't really take place.
- jedbrown 17y ago15% is a bit higher than I benchmark, but here is a version that is guaranteed to do the correct number of iterations, increments in floating point instead of performing the slow cast, and is faster than performing the comparison in floating point math (because it occupies a different execution unit). Note that it is also less accurate than the cast for most definitions of what this function might be attempting to measure. http://gist.github.com/288980 http://gist.github.com/288980