@scrawl yeah, let me know if you have any questions. helps to know what grabs people's attention

i'm debating starting an article series again

@kevinlawler you can make virtual function tables in manually in C if you so want to (I've done so for CBQN, and rarely rely on actual types, and when I do, there's a generic fallback). The problem with having a compact range object is that you can't get a, say, int32_t* out of it to pass to some SIMD loop though. You either need to materialize it at the use-site (adding overhead checking for it every time an array is used, and making the optimization useless), have special loops for everything when some args are ranges, or use the generic slow item-by-item fallback.

(or you could decide to not care about performance that much ¯\_(ツ)_/¯)

@dzaima re: virtual function tables: you can do it in C, and most c-based k-like implementations are going to veer that way. but in my mind once you are doing virtual function tables, doing function-local push+pops for workstack management, etc., in some cases literally going after the gcc built-ins that facilitate C++. So you might as well pull in all the C++ sugar. And afaik there aren't going to be any performance downsides there.

@dzaima re: O(1) range simd loop: sure, O(1) range is just an example. (and there's always the option not to use it.) but to your point, there are a lot of wrinkles in the area of the example you cite. One is that, if you're doing a lot of O(n) ops on something, it's probably moot whether you do the O(1) or O(n) range. Another is that it's typically hard to see (appreciable) SIMD speedups since you're going to be mostly memory bound (IME, it's been a few years since I played with SIMD)

A third is that a range object begins to be more compelling if you're doing say an index into a 1-byte boolean vector using indices that exceed the int32_t max (8 times as long). And the space savings aside.

but yeah, i see your point

O(1)-range is neat, but it gets a lot neater using combinations of special types

@kevinlawler SIMD is indeed pretty memory-bound for large inputs, yeah. But for medium inputs, it's still very beneficial, and non-SIMD code needs to be pretty well optimized in order to beat the SIMD memory bound. I do hope to one day have a loop fusing JIT for CBQN (at which point a range would just be created on the fly as its used) but that's faaar off.