Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
25 ms
·
361.
▲
by
dzaima
2y ago
Seems "-fno-math-errno" is enough for clang. gcc needs a whole "-fno-math-errno -funsafe-math-optimizations -ffinite-math-only".
362.
▲
by
dzaima
2y ago
gcc and clang are also capable of it, given certain compiler flags: https://godbolt.org/z/z766hc64n
363.
▲
by
dzaima
2y ago
It depends on how high performance your high performance context requires. Being an array language, ideally traditional interpreter overhead doesn't matter if you write "array-y" code as most time would be spent in within-int
364.
▲
by
dzaima
2y ago
For single-author quickly-changing projects I'd guess that it's quite likely for only like 1% of the commits to be looked at to such extent that the commit message is meaningfully useful. And if each good commit message takes 1 mi
365.
▲
by
dzaima
2y ago
If you're writing a shell, you can spend the 15 minutes to write a custom mutable data structure for your envvars; no need to significantly worsen the entire ecosystem to reduce the size of shells by a couple dozen lines (or, rather, m
366.
▲
by
dzaima
2y ago
You can't GC together with the host environment if you do a custom GC (i.e. a wasm object and a JS object in a cycle wouldn't have any way to ever be GC'd).
367.
▲
by
dzaima
2y ago
Indeed a single thread is most simple to reason about, but if you have a single task that can already use 2 cores uniformly, going to 8 cores (assuming enough workload) should be a pretty clean 4x speedup (as long as you don't run into
368.
▲
by
dzaima
2y ago
Well it's not like you could get to the root of the issue on windows, with it being closed-source and all.
369.
▲
by
dzaima
2y ago
Right, with 64-bit ints things are a lot nicer. Though you can still run into some issues on "generate this much data" tasks as opposed to "operate over existing data of this size", though perhaps less exploitably so.
370.
▲
by
dzaima
2y ago
If you accept 2^32, then code using 32-bit ints is definitely broken on it and thus the OP question of the issue on half that is irrelevant. Which is my point - widening the acceptable input range from 2^31 to 2^32 (or in the case of sign
371.
▲
by
dzaima
2y ago
But in what realistic scenario would a user be able to put in ≥2^31 while not being able to put in 2^32-1 (which probably breaks many more things from innocent increments or similar) or 2^100?
372.
▲
by
dzaima
2y ago
That's not valid standard C; gcc and clang give a warning with '-pedantic'. It's valid C++ though. And IMO it's quite a nice feature, useful sometimes for reducing boilerplate in early returns. It's the obvious
373.
▲
by
dzaima
2y ago
Note that switch case ranges might be coming in C2y though.
374.
▲
by
dzaima
2y ago
Multiplication typically takes 3 cycles, so a total of 1+3+1=5 cycles of latency. A load from L1 takes 4-5 cycles on non-ancient x86 and Apple M1. So roughly on-par, perhaps a bit faster, at the cost of eating some ILP in the odd case that
375.
▲
by
dzaima
2y ago
That doesn't work - the numbers change every 3 or 4 entries, i.e. ~log2(10), not 10. (and the precise point of change is important too)
376.
▲
by
dzaima
2y ago
A latency improvement would be to have digitCountThresholds be indexed by the lzcnt, instead of the result of the other LUT. Increases the size of that lookup table from 160B to 512B though. Funnily enough I've had this approach in a l
377.
▲
by
dzaima
2y ago
MIT allows anyone to lock the project down, not just one entity, so there isn't ever anyone who can benefit more than others from a contribution.
378.
▲
by
dzaima
2y ago
Perhaps not - as it happens at the rename stage and thus only with immediate values, it's all fixed behavior for a given instruction stream; with branching you can of course get dynamically different renamed immediates, but, as that&#x
379.
▲
by
dzaima
2y ago
Ah, good to know on the uop count. Still could be (or, well, has to be to some extent) the same concept, just pipelined within one uop.
380.
▲
by
dzaima
2y ago
You don't quite need a full 64-bit adder to materialize the proper value, as one argument is only a 10-bit int. So a 10-bit adder, a 54-bit increment, and muxing it with the original depending on the add carry. And, presumably, the OP
381.
▲
by
dzaima
2y ago
Strict aliasing in particular is very dependent on coding style; I too just turn it off with essentially no harm, but certain styles of code that don't involve carefully manually CSEing everything might benefit a good bit (though with
382.
▲
by
dzaima
2y ago
I don't think rr hooks actual kernel writes, but rather just has hard-coded information on each syscall of how to compute what regions of memory it may modify, reading those on recording and writing on replay. As such, for an asynchron
383.
▲
by
dzaima
2y ago
While not allowing stepping in the kernel, a large part of rr is indeed intercepting all things the kernel may do and re-implementing its actions, writing down all changes to memory & etc it does (of course for Linux, not Windows). With
384.
▲
by
dzaima
2y ago
It is just that. (of course in practice you also need to get the LSP to exist on your system somewhere in the first place and have a command that runs it (rather annoying for java programs), but other than that it's literally just a pr
385.
▲
by
dzaima
2y ago
Most of the simple benches I do are for ~1 second. The order-dependent things definitely were reproducible (something along the lines of rerunning resulting in some rare virtual method case finally being invoked enough times/with enoug
386.
▲
by
dzaima
2y ago
JIT can be very unpredictable. I've seen cases with JVM of running the exact same benchmark in the same VM twice having the second run be 2x slower than the first, occurrences of having ran one benchmark before another making the latte
387.
▲
by
dzaima
2y ago
Worst-case, you just multiply the result by the divisor and subtract that from the dividend.
388.
▲
by
dzaima
2y ago
Here's a version of the vrcpps idea, doing whole vectors of 32 u8's, bypassing lane crossing and somewhat simplifying the packing/unpacking, that's ~1.5x faster on Haswell: https://godbolt.org/z/TExG
389.
▲
by
dzaima
2y ago
Some SIMD ISAs with integer division: - Arm SVE, though only for 32-bit and 64-bit element types: https://developer.arm.com/architectures/instruction-sets/int... - loongarch64 LSX/LASX: https://jia
390.
▲
by
dzaima
2y ago
Compilers can generate non-temporal ops if you ask for it explicitly in some form. And they are problematic: https://github.com/llvm/llvm-project/issues/64521
More ›