bu

than the git log itself on the Linux kernel (61 seconds to git log, but only 227 ms to `lfreq` it). Besides all that, there's also the distributed-with-Zsh `cdr` (`man zshcontrib` or similar to read all about that).

..) [1] https://github.com/c-blake/bu/blob/main/doc/newest.md*

undreds of closed issue threads got into a comparison of dups and jdupes ( https://github.com/c-blake/cligen/issues/99#issuecomment-485... ) where Jody shows up. I mean, in my test cases dups fared well, but on what many would call the "boring non-IO bound case". For IO bound cases things rapidly depend a lot on your host OS & devices. I should say that "the point" of most of these things was not caffeine-fueled rage optimization, but more to show how easy it is to get performance & functionality out of Nim. Almost all are much smaller programs (perhaps with many fewer features) than their competing programs. But such catering to The Unix Philosophy felt like it fit well with a CLI toolkit. { Even sys_batch is like a 30 lines of C virtual machine for inside Linux instead of untold 10s of thousands for eBPF & IO uring. While porting to other arches would be more, that 30 lines could probably stay the same. }

how he said because of 1 byte/cycle is 4GB/s things are "easily CPU bound" while I feel like I've been "fighting The Memory Wall for at least 3 decades now..." even just from super-scalar CPUs, but he later does some vectorization stuff. That more relates to what calcs you are doing, of course, but high bandwidth memory is a big part of what nVidia is selling.

ormance in real programs where each `key` is often not speculatively pre-computable.

ts (and this is true outside of computing). People have a rather strong tendency to oversimplify -- no matter how many times this lesson shows up. EDIT: Also, the article at least uses two CPUs, Intel & Apple M1 and two compilers (gcc & clang), but there are realistic deployment scenarios across many more generations/impls of Intel, AMD, and ARM and probably other compilers, too. So, it only even samples a small part of the total complexity. Also, if you want to be more scientific, esp. for differences like "1.01X" then time measurements should really have error bars of some kind (either std.dev of the mean or maybe better for a case like this std.dev of the min[2]) and to minimize those measurement errors you probably want CPU core affinity scheduling in the OS. [1] https://stackoverflow.com/questions/360748/computational-com... [2] https://github.com/c-blake/bu/blob/main/doc/tim.md

dagogy in general is also tricky, but I think this rhetorical advice is common practice and might also double as a way to address your initial misread of the topic. EDIT: he can always do refinements / more analysis in follow up posts/something if this library has any legs for him. [1] https://github.com/c-blake/bu/blob/main/doc/tim.md [2] https://github.com/c-blake/bu/blob/main/doc/edplot.md ¹ Sure, fancy any-size allocators can tack on a histogram of maybe somewhat rounded lg sizes (to economize histo space) and spawn fixed-size object sub-arenas if there are enough of them, say >= enough to fill a VMem page or 2, but this is rare in my experience and also complicates the dispatch to subarenas that you mention above to slightly fancier search. This kind of topic rapidly spirals into allocator-complete discussion and even systems-complete - e.g. a filesystem is largely an allocator with good old MS-DOS FAT being close to a "file is a pool of disk blocks" model.