Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
29 ms
·
331.
▲
by
dzaima
2y ago
You can run BQN in termux on Android pretty well. A list of libraries is available at https://github.com/pellertson/awesome-bqn . https://mlochbaum.github.io/BQN/ has pretty good documentation.
332.
▲
by
dzaima
2y ago
1-byte characters (i.e. what k's typically have) handle ASCII just fine, for which doing reversing/splitting/uppercase/lowercase/iteration/etc is actually meaningful (stock symbols, stringified dates, identifie
333.
▲
by
dzaima
2y ago
The big problem with using array languages for lower-level SIMD stuff is that that generally requires some amount of typedness, but tacking on types on an array language without ending up with having types be the majority of the syntax and
334.
▲
by
dzaima
2y ago
Ah, your gcc example does have the branchful branch that could be done branchlessly; I was thinking about my original example with a load, which can't be transformed back. On fusion, https://dougallj.github.io/applecpu&
335.
▲
by
dzaima
2y ago
> since my read of your previous comment seemed to suggest you knew a way I did not, I had my fingers crossed. Whoops, typo! edited. > Interestingly, the RISC-V guys seem to think that adding an explicit instruction is a waste of sili
336.
▲
by
dzaima
2y ago
There's of course no "way" to check, as it's a microarchitectural property. Your best bet is comparing performance of the same code on predictable vs unpredictable branches. I don't think there's any need for x
337.
▲
by
dzaima
2y ago
I haven't heard of anything outside RISC-V having jump-over-mov as an idiom (though I've heard of potentially some CPUs having the ability to unwind only necessary parts on mispredictions over small bits of code or something; stil
338.
▲
by
dzaima
2y ago
Yeah, the need of the "-mllvm -x86-cmov-converter=false" hack is stupid; forgot to check with it. In my mind I guess I equivocated that being fixed with https://reviews.llvm.org/D118118 (and indeed __builtin_unpre
339.
▲
by
dzaima
2y ago
Zicond's czero.eqz & czero.nez (& the `or` to merge those together for the 3-instr impl of the general `x?y:z`) still have to go through the execution pipeline, forwarding network, an ALU, etc just as much as an xor or and need
340.
▲
by
dzaima
2y ago
The "y^((y^z)&x)" method is already branchless, and close in performance to the Zicond variant, is my point; i.e. Zicond doesn't actually add much.
341.
▲
by
dzaima
2y ago
Worse, doing one of the idioms for a conditional move ends up getting gcc to actually produce a conditional move, but clang doesn't, even with its __builtin_unpredictable: https://www.godbolt.org/z/bq9axzvjG
342.
▲
by
dzaima
2y ago
Eh, it takes ~3-4 instrs to do a branchless "x ? y : z" on baseline rv64i (depending on the format you have the condition in) via "y^((y^z)&x)", and with Zicond that only goes down to 3 instrs (they really don't
343.
▲
by
dzaima
2y ago
Not always - https://www.godbolt.org/z/zYxeahf3T . And for any modern (as in, made in the last two decades) x86 processor the branchless version will be hilariously better if the condition is unpredictable (which is a
344.
▲
by
dzaima
2y ago
Linus wrote this on kernel.org not being a SPoF: https://lore.kernel.org/rust-for-linux/CAHk-=wiQUya5_zTwLFNT...
345.
▲
by
dzaima
2y ago
Would be nice to mention how to determine those *_OFFSET constants. For reference, on my linux mint (glibc 2.39) system this gives them: gdb /lib/x86_64-linux-gnu/libc.so.6 -ex 'p &main_arena' -ex 'p
346.
▲
by
dzaima
2y ago
It's certainly not a thing to be resolved in the abstract, but it's also far from thing to be ignored as irrelevant in the abstract. But I have a hard time imagining that my general point of "if there's headroom for a fu
347.
▲
by
dzaima
2y ago
I quite heavily disagree. Perhaps might apply to programs which do spend like 90% of their time in a couple tight loops, but there's tons of software that isn't that simple (especially web.. well, everything, but also compilers, v
348.
▲
by
dzaima
2y ago
My point with vectorization was that the one case where indexed loads/stores are most defendably unnecessary is also the case where you shouldn't want scalar mem ops in the first place. Thus meaning that many scalar mem ops would
349.
▲
by
dzaima
2y ago
So your argument isn't that it's irrelevant, but rather that it might be irrelevant, if you happen to have a core where the extra latency of a 64-bit adder on the load/store AGU pushes it just over to the next cycle. Though
350.
▲
by
dzaima
2y ago
Note that Zba's sh1add/sh2add/sh3add take care of the problem of separate shift+add. But yeah, modern x86-64 doesn't have any difference between indexed and plain loads[0], nor Apple M1[1] (nor even cortex-a53, via some
351.
▲
by
dzaima
2y ago
Not doing things atomically when they should be (incl. missing locks around tiny ops) would be a pretty large class. With native multithreading data can pass from thread to thread millions of times per second, and you're much less like
352.
▲
by
dzaima
2y ago
I'll +1 GDB/MI being utter garbage. Bespoke format (ordered multimap as the only keyed data structure, why), weird quoting requirements (or sometimes requirement of lack thereof) on input, extremely incomplete, and in some cases n
353.
▲
by
dzaima
2y ago
While the single-threaded execution means that issues from thread interleaving on the scale of nanoseconds will effectively not happen, multiple threads are still allowed and will be context-switched between. rr also has a chaos mode to int
354.
▲
by
dzaima
2y ago
Yeah, I was being overly dismissive of your comment :) But beyond obvious hard differences in what languages in question allow about a given topic (of which indeed there are none between C/C++/Rust/Zig on the topic of memory
355.
▲
by
dzaima
2y ago
As long the language in question is turing-complete, everything is equally a skill issue.
356.
▲
by
dzaima
2y ago
And now instead of having a small update every now and then that you can perhaps try to adapt to, you have a massive update every 5 years or whatever (or less if you happened to start out just before the next LTS) that'll basically gua
357.
▲
by
dzaima
2y ago
SMT solvers might not be feasible for large-scale things, but they can certainly be used to find a sequence of a couple instructions doing a specific thing if you give enough computational resources, and that's what OP was talking abou
358.
▲
by
dzaima
2y ago
"why something is written in a certain way" most likely doesn't even have an answer while a project is still in the rewrite-large-parts-frequently stage. Sure, you could spend some time conjuring up an explanation, but that&#
359.
▲
by
dzaima
2y ago
Difference being that if you automate backups they're, well, fully automatic, whereas writing good commit messages always continues to take time.
360.
▲
by
dzaima
2y ago
ICX appears to just default to fast-math: https://godbolt.org/z/jzPazGjoh Requiring -fno-math-errno is sane enough, essentially noone needs math errno anyway (and that flag is needed to vectorize even sqrt, for which t
More ›