Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
38 ms
·
451.
▲
by
dzaima
2y ago
The article here is about hardware without native FP already; that said, rationals (even before getting to the need of bigints) are quite bad regardless, likely requiring division & gcd around basic arith, which are slow both in softwar
452.
▲
by
dzaima
2y ago
Interesting. I wonder how would interleaved 'inc r64'+'mov r32,r32' look - that's two separate latency-zero ops, equal to 'inc r32'. Wouldn't be too surprised if an eliminated op can only be zero-exte
453.
▲
by
dzaima
2y ago
Note that, not only are multiple consecutive increments reduced to zero latency, but that happens even if they're interleaved with movsxd, as in the second experiment at https://uops.info/html-lat/ADL-P/INC_R6
454.
▲
by
dzaima
2y ago
uops.info's measurements show 'inc r64', interleaved with 'movsxd' instructions, still having zero latency[0], so it can't be just merging the immediates of successive increments (or there's additional fus
455.
▲
by
dzaima
2y ago
But, of course, this wouldn't be shell if that didn't have footguns more; namely, it breaks if ran in an empty directory (giving a literal "got: *"), and excludes the arbitrary set of files whose name begins with ".
456.
▲
by
dzaima
2y ago
There's https://www.agner.org/optimize/microarchitecture.pdf for a bunch of microarchitectural information, covering many interesting things outside of specific instruction breakdown as in uops.info. chipsandchees
457.
▲
by
dzaima
2y ago
Indeed there's no benefit to users from an app being arbitrarily tied to the Play Store, but that's entirely equivalently so to how there's no benefit to users from any sort of DRM. Perhaps "digital rights management&quo
458.
▲
by
dzaima
2y ago
That's a completely different fight from what the DMA targets though. Referring to this as an Android/Google Play thing is a red herring here, this is just bog standard DRM, which just so happens to be made by Google (and maybe ge
459.
▲
by
dzaima
2y ago
Data memory-dependent prefetchers are a thing (..with expected side-channel potential), and tagging would conceivably make it non-functional. Though, realistically, I wouldn't expect for it to make much difference.
460.
▲
by
dzaima
2y ago
On the other hand, this may make it worse for aarch64 & RISC-V, which can have shorter encodings for loads/stores with an immediate offset that's a multiple of the operated-on data: https://godbolt.org/z/z
461.
▲
by
dzaima
2y ago
On NaN-boxing, it's possible to put tags in the top instead of low bits - 64-bit floats have 52 bits of mantissa, 4 of which are in the top 16; though you only get 7 tags due to having to leave qNaN & infinity (8 may be possible if
462.
▲
by
dzaima
2y ago
Huh. In my experience it works nearly flawlessly, certainly far above 50%. And even when there are spurious failures in replaying it's easy enough to just re-replay (though I do wish there was some way to export the current position &a
463.
▲
by
dzaima
2y ago
rr can record process trees; i.e. basically any part/descendant of a process you spawn will be recorded and can be replayed (userspace CPU & memory, that is); won't record the entire OS though.
464.
▲
by
dzaima
2y ago
Any object which is referenced by the stack cannot be moved, but the rest of the heap (i.e. the vast majority, assuming the stack is much smaller than the heap) still can.
465.
▲
by
dzaima
2y ago
Less trivial considering that typically only the low ~47 bits of addresses are allowed to be non-zero; then again, values on the stack would still be full 64 bits and any non-zero bit in the top 17 immediately disqualifies it; then again, b
466.
▲
by
dzaima
2y ago
Assuming that on-heap objects are tracked precisely, the maximum number of objects conservative stack scanning can incorrectly consider as roots is O(stack size) (with, in practice, a tiny constant factor, from excluding actual intentional
467.
▲
by
dzaima
2y ago
perf's produced perf.data is a documented file format that you can parse manually if so desired, and does in fact directly store the 8KB of stack data (or whatever configured) & register values in the "dwarf" mode.
468.
▲
by
dzaima
2y ago
I believe this is essentially what linux perf's "--call-graph dwarf" does. On my system that ends up producing ~33MB/s of recording data for ~4000 samples/s.
469.
▲
by
dzaima
2y ago
For something more systematic/reproducible, it's possible to use rr[1] to record the program, and in a replay run to the end (or whatever boundaries you care about), run "when-ticks", and do various "seek-ticks 1234
470.
▲
by
dzaima
2y ago
Fused multiply add applies equally to scalar and vectorized code (and C actually allows compilers to fuse them; there's -ffp-contract=off / the FP_CONTRACT pragma to turn that off); the compiler/autovectorizer can trivially j
471.
▲
by
dzaima
2y ago
Page crossing affects a minuscule amount of cases - with 4096B pages and 100% non-compressed instructions (but still somehow 50% of the time misaligned), it affects only one in 2048 instructions. The possibility of I/O is in no way exc
472.
▲
by
dzaima
2y ago
On clang, you can actually request that it gives a warning on missed vectorization of a given loop with "#pragma clang loop vectorize(enable)": https://godbolt.org/z/sP7drPqMT (and you can even make it an err
473.
▲
by
dzaima
2y ago
Yep. Unfortunately I am one to be making language runtimes :) It's just the potentially most significant thing I could come up with at first. Though perhaps RVV not being in rva20/rv64gc is more significant.
474.
▲
by
dzaima
2y ago
It's something that the compiler would handle, but can still moderately influence programming decisions, i.e. you can have a lot more temporary variables before things start slowing down due to spill stores/loads (esp. in, say, a
475.
▲
by
dzaima
2y ago
RISC-V with the compressed instruction extension actually ends up smaller than x86-64 and ARM on average. There's not much inherent that needs to change in software approach. Probably the biggest thing vs x86-64 is the availability of
476.
▲
by
dzaima
2y ago
There's the mild note that the behavior of the 'x0, x0' form changed between RVV0.7.1 and 1.0 - on 0.7.1 it sets VL=VLMAX, while on 1.0 it inherits the previous VL. That said, the 0.7.1 behavior is still useful, and improper
477.
▲
by
dzaima
2y ago
The instruction in question doesn't map to any instruction in neither RVV0.7.1/xtheadvector, nor RVV1.0. Disassemblers don't disassemble it, and assemblers don't have any mnemonic for it (the 'vse128.v' used by
478.
▲
by
dzaima
2y ago
It's also possible to run sshd in Termux ( https://wiki.termux.com/wiki/Remote_Access ), and mount a regular sshfs on the Linux side. Though this may not allow modifying files in external storage. The Linux side bei
479.
▲
by
dzaima
2y ago
The option of not needing any fixed register usage would apply to, what, optimizing compilers without support for function calls (at least via passing arguments/results via registers)? That's a very tiny niche to use as an argumen
480.
▲
by
dzaima
2y ago
Function arguments and return values already are effectively special use, and should frequently be on par if not much more frequent than the couple x86 instructions with fixed registers. Both clang and gcc support calls having differing use
More ›