dzaima

13 ms·

181.
by dzaima 1y ago
Yeah, I meant specifically C in an ergonomic way with operators working on them and being passable to existing functions. Though wrapping in different structs doesn't seem to even make gcc & clang properly optimize utilizing the ty
182.
by dzaima 1y ago
I don't think the usefulness is that skewed towards numerics? Both clang/llvm and gcc can do alias checking at runtime if they can't at compile-time, which makes loops vectorizable without alias info, at the cost of a bit of
183.
by dzaima 1y ago
Rust's aliasing rules are very different from C's. In C you have a nuclear `restrict` that in my experience does anything only when applied to function arguments across clang & gcc, and type-based aliasing which is both not a
184.
by dzaima 1y ago
re edit - While the hardware differences are significant, some by necessity, some by tradition, it's not my point. My specific point is that "how to write code that is generic across block size, boundary conditions, and thread div
185.
by dzaima 1y ago
I haven't used CUDA (don't have nvidia gpu), but I've looked at examples of code before. And it doesn't look any more simple than CPU SIMD for anything non-trivial. And pleasepleaseplease don't have locks in somethi
186.
by dzaima 1y ago
It has single-threaded semantics per element. Which is fine for anything that does completely independent computation for each element, but is quite annoying for everything else, requiring major algorithmic changes. And CPU SIMD is used for
187.
by dzaima 1y ago
That's because the things GPUs do just isn't what CPUs do. GPUs don't have to deal with ad-hoc 10..100-char strings. They don't have to deal with 20-iteration loops with necessarily-serial dependencies between invocation
188.
by dzaima 1y ago
I think LLVM should be able to handle up to less than 65536-bit vectors? At least I saw some llvm issue noting that that's where some things broke down; so a 32kbit vector would be f64x512. But I meant an exaggeration as far as actuall
189.
by dzaima 1y ago
If by that absolute value thing you mean _mm512_abs_pd, that's a pseudoinstruction for 'and'ing via a mask that zeroes out the top bit, which can be done equally as well on 128/256-bit vectors, just without an intrinsic
190.
by dzaima 1y ago
Overly-wide vectors I'd say are a pretty poor choice in general. If you're using shuffles at times, you must use native-width vectors to be able to apply them. If you're doing early-exit loops, you also want the vector width
191.
by dzaima 1y ago
If your interpreter is interpreting a program with unpredictable branches, of course no predictor will magically make your interpreter get branches better predicted than an equivalent compiled program will. The question here is about all ot
192.
by dzaima 1y ago
The timestamps just get moved around sometimes: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
193.
by dzaima 1y ago
More generally than the other replies, BQN is an array language, and as such "a+b" & "a×b" etc automatically map over arrays, and the interpreter can thus trivially vectorize them (and, if you're curious, yes, i
194.
by dzaima 1y ago
As a fun note, here's a talk of automatically reordering LLVM passes to optimize for code size, which seemingly worked enough to make a talk/paper about: https://www.youtube.com/watch?v=_SqWd74zG2Y
195.
by dzaima 1y ago
Yeah, it is a good bit down; that said, bump allocators are a very common (most common?) option around GC anyway; I personally scrolled straight to the disassembly, and it's pretty clear from that, and the explicit mention of bump allo
196.
by dzaima 1y ago
The article does include: > The allocation fast path of the RPython GC is a simple bump pointer, and the assembly for it. Indeed a bump allocator has the disadvantage that it effectively continuously thrashes the lower cache layers, but
197.
by dzaima 1y ago
For malloc/free specific workload is much more important than for a bump allocator; malloc potentially has branching and different cache access/utilization patterns depending on requested sizes or distance/pattern between mal
198.
by dzaima 1y ago
Beyond what others have mentioned, I think another big differentiating factor between APL and the rest of those languages is that APL isn't focused on allowing the user to expand the language meaningfully, but rather on being a well-ro
199.
by dzaima 1y ago
The precise requirements of IEEE-754 may not be important for any given program, but as long as you want your numbers to have any form of well-defined semantics beyond "numbers exist, and here's a list of functions that do Somet
200.
by dzaima 1y ago
Oh, also, C23 added standard ckd_add & ckd_sub & ckd_mul for getting a boolean of whether the operation overflows (i.e. standard equivalent to __builtin_add_overflow)!
201.
by dzaima 1y ago
OoO should actually be the care where that doesn't matter I'd think - the CPU can, well, execute the instructions not in the order they're in the binary; it's in-order implementations are where that matters more. And wit
202.
by dzaima 1y ago
While there is no direct access to flags in standard C, you can nevertheless on gcc and clang compile with -ftrapv and get your signed integer arithmetic be overflow-checked. Or you can use __builtin_add_overflow & co and get access to
203.
by dzaima 1y ago
A couple minor notes: - If your program is very light on syscalls (i.e. basically entirely in-memory computation), rr can go to a basically 1.0x slowdown. In particular this means you can run benchmarks in it at full capacity, provided that
204.
by dzaima 1y ago
https://undo.io/resources/undo-vs-rr/ does note parallel recording for multi-process (not multi-threaded), so perhaps that.
205.
by dzaima 1y ago
rr does support multithreaded and multi-process applications, via, like Undo[1], allowing only a single thread to run at a time. (edit note - that's only about multithreading; Undo might have parallel multi-process recording) [1]: htt
206.
by dzaima 1y ago
Intel compilers default to -ffast-math wholesale, so they're just entirely broken: https://godbolt.org/z/18xoEf5Gf Those LLVM issues are unrelated afaict - the former is high-level IR optimizations that just resul
207.
by dzaima 1y ago
If everything goes roughly the same with all seeds, then everything's indeed just fine. If not, I have a paper trail that I did in fact actually encounter the unexpected thing instead of just making up results. (indeed a seed could be
208.
by dzaima 1y ago
The only case I recall of denormals specifically being improperly handled is 32-bit ARM NEON; and indeed clang and gcc just don't use it without -ffast-math. NaNs indeed can get different bit patterns, but my point was that, given that
209.
by dzaima 1y ago
Even denormals and NaNs should be perfectly consistent, at least on CPUs. (as long as you're not inspecting the bit patterns of the NaNs, at least) Irrational stdlib functions (trig/log/exp; not sqrt though for whatever reaso
210.
by dzaima 1y ago
Software developers will be the vast majority of users though, at the very least for the CLI. Git certainly isn't anywhere close to the prettiest thing for ease-of-learning (and indeed used to be even worse), but Mercurial didn't

More ›