bu

ig 2X boost, but down at the 10s of usec to 10s of ms scale, just fluctuations in OS scheduler or P-core/E-core kinds of things can create confusion which is part of the motivation for aforementioned https://github.com/c-blake/bu/blob/main/doc/tim.md. I should perhaps also have mentioned https://github.com/yglukhov/nimpy as a way to write extensions in Nim. Kind of like Cython/SWIG like stuff, but for Nim.

001991 sys 99.9 % 5944 mxRS TM 0.940162912 wall 0.935362 usr 0.003988 sys 99.9 % 5916 mxRS TM 1.155755936 wall 1.151529 usr 0.002993 sys 99.9 % 5928 mxRS TM 0.432215672 wall 0.430851 usr 0.000998 sys 99.9 % 5800 mxRS python-3.11.9_p1 TM 2.678891504 wall 2.675141 usr 0.000994 sys 99.9 % 7992 mxRS TM 1.348009364 wall 1.344612 usr 0.001995 sys 99.9 % 7864 mxRS TM 2.018986091 wall 2.014702 usr 0.001994 sys 99.9 % 7972 mxRS TM 0.768633122 wall 0.766915 usr 0.000997 sys 99.9 % 7980 mxRS I recall when Python3 was first going through its growing pains in the mid noughties that promises of eventually clawing back performance. This clawback now seems to have been a fantasy (or perhaps they have just piled on so many new features that they clawed back and then regressed?). Anyway, Nim is even faster than PyPy and uses less memory than either version of CPython: doIt.nim: proc doIt() = var i = 10000000 var r = 0 while i > 0: i = i - 1 r += min(i, 500) echo r doIt() #TM 0.024735 wall 0.024743 usr 0.000000 sys 100.0% 1.504 mxRM In terms of "how Python-like is Nim", all I did was change `def` to `proc` and add the 2 `var`s and change `print` -> `echo`. { EDIT: though if you love Py print(), there is always https://github.com/c-blake/cligen/blob/master/cligen/print.n... or some other roll-your-own idea. Then instead of py2/py3 print x,y vs print(x,y) you can actually do either one in Nim since its call syntax is so flexible. } It is perhaps noteworthy that, if the values are realized in some kind of array rather than generated by a loop, that modern CPUs can do this kind of calculation well with SIMD and compilers like gcc can even recognize the constructs and auto-vectorize. Of course, needing to load data costs memory bandwidth which may not be great compared to SIMD instruction throughput at scales past 80 MiB as in this problem.

ion is at best a weak approximation and at worst totally misleading. Ways to measure how much evidence there is that IID / other distributional assumptions are failing do exist { such as some of the ones here: https://github.com/c-blake/fitl/blob/main/fitl/gof.nim and referenced at the bottom of https://github.com/c-blake/bu/blob/main/doc/edplot.md (at the stage where one "plots / pools together multiple data points into some kind of "sample" with a "distribution") }. Sadly, few test such assumptions (which are rarely truly comprehensive anyway) and even small departures from modeling assumptions may lead to relatively large errors in estimates. E.g., the linked to Einmahl 2009/2010 research states this as an assumption to apply the ideas, but then shows no test of that assumption on the used data.

ential cascade of activity. (EDTI: This is clocking in at about 9572177ns/(48*3600s) =~ 55 parts per billion for me right now.) As a final example, I got annoyed with the unwanted complexity of modern syslog junk. So, I whipped up https://github.com/c-blake/kslog which just looking it up for this post, according to /proc/PID/schedstat has only accumulated about 27357590/(24*3600+24*60) =~ 311 parts per billion of 1 CPU on a 4-core system since boot about 24h:24m ago. This in about 25% of the lines of Nim code that busybox spends on less useful C code (to your point of "almost all the code is the actual logic, not other junk"). Also, while it is not as full-featured as stdlib `string`, there is a zero-copy `cligen/mslice.MSlice` type (https://github.com/c-blake/cligen/blob/master/cligen/mslice....) that does have basic features like splitting and number parsing. There are probably others out in the Nimbleverse. If view types ever migrate from experimental status to relied-upon that might become less interesting. Since you do a lot of statistics, you might also appreciate the fmtUncertain* subsystem of https://github.com/c-blake/cligen/blob/master/cligen/strUt.n... which allows you to retain only meaningful number of digits and also https://github.com/c-blake/adix/blob/master/adix/mvstat.nim which has efficient moving quantiles via a Fenwick Tree logarithmic histogram.