I fully agree on Nim indeed _being_ a good language. My point though wasn't "I can do faster code than ...".
My point was that one should a) _think_ about optimization starting from "what's actually the point and what's the bottleneck or the most promising approach?" (in this case it was "use a better algorithm") and also "how much optimization do I need and what is it worth? (e.g. in dev time)", b) avoid _obvious_ problems (like nesting loops without need), and c) _help_ the compiler by providing clear hints. I also copied your code verbatim (modulo the now(); I prefer my own routine because I know it's directly getting the monotonic clock), compiled it with the exact switches used by timothee and the above code from you took around 210 ms on my system (debian, Ryzen (in a VM), gcc 8.2.0). And I'm not surprised. While you are right and Nim has excellent iterators the basic problem still is 3 loops and an if in the inner most loop (and a bad algo). Maybe my Ryzen is a bit more or a bit less sensitive than your CPU in that regard but any kind of branching (loops, ifs) risk to trash the L1 and often enough L2 too. And btw, Nim's iterators, as great as they are, are not zero cost. One single change in your code, namely replacing `for z in toInfinity(1):` with `for z in 1 ..< 0x7FFFFFF:` made the code run almost 10% faster. But I had another interesting point in my first post: Why use _any_ language XYZ? Why not use, for instance, Python? What's the point, the difference? (Looking from the perspective I'm interested in here) the answer is: Python means "way less dev. time than C but way slower code (runtime)". Where is Nim on that axis? _That_ (imo) is an immensely important point and one where Nim really shines: You get a dev. time not far from Python -and also- a run time very close to C. That's why I do not even _expect_ and desire Nim to ever reach 100% of C code (runtime) speed. What I want is a language that makes it easy to think about and focus on my task, the algorithm and still get near C speed. From what I see nobody and nothing gets even close to Nim in that crucial point that is _directly related_ both to productivity and code quality and I still _can_ profile and optimize real hot spots in C.
