Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
33 ms
·
271.
▲
by
dzaima
2y ago
Some proprietary-friendly compiler would've appeared in one way or another at some point. I'd rather such at least have some amount of openness. Better than many crappy from-scratch completely-proprietary vendor compilers at least
272.
▲
by
dzaima
2y ago
Yeah, an asm marked as memory-clobbering is the proper thing; not the first time I've forgotten that volatile entirely doesn't imply anything to other memory. (in fact, doing "((volatile uint8_t*)x)[0] = 0xaa;" in my god
273.
▲
by
dzaima
2y ago
> I see a fellow enjoyer of bugs ;) Yep! :) I did look at the assembly on a release build and the write method was in fact not inlined (needed to get the compiler to reason about the offset aliasing); that write method is what I called &
274.
▲
by
dzaima
2y ago
Rust doesn't help here; you necessarily must do all stores in potentially-mirrored memory as volatile (and possibly loads too), else you can have arbitrary spooky-action-at-a-distance issues, as, regardless of &[T] vs &mut [T]
275.
▲
by
dzaima
2y ago
Volatile stores would fix that issue. But it does mean that it'd be unsafe to lend out mutable references to objects. (maybe you'd need to do volatile loads too, depending on model of volatility)
276.
▲
by
dzaima
2y ago
That theoretical result of the golden ratio is completely entirely useless for any practical scenario, and, even for its extremely-contrived scenario where the only allocations ever happening are from a single array being expanded, and usin
277.
▲
by
dzaima
2y ago
..yep, true, completely slipped my mind. So modulo is just trivially always the bad choice. Even for arbitrary indexing "tmp=head+index; buffer[(tmp >= capacity) ? tmp - capacity : tmp]" or so is gonna be better. (assuming the
278.
▲
by
dzaima
2y ago
The ExpandingRingBuffer.h is rather bad for a representation of a ring buffer - it uses modulo for the index calculation, which is pretty damn bad and should really at the very least be masking by a power-of-two. (it might very-slightly-but
279.
▲
by
dzaima
2y ago
That'd break arbitrary reads being contiguous O(1) though.
280.
▲
by
dzaima
2y ago
Right, indeed, amluto's comment is incorrectly broad. But it's still a thing that a ring buffer cannot guarantee, but std::deque impls must.
281.
▲
by
dzaima
2y ago
https://en.cppreference.com/w/cpp/container/deque : > When inserting at either end of the deque, references are not invalidated by insert and emplace. > push_front, push_back, emplace_front and emplace_b
282.
▲
by
dzaima
2y ago
Might not be a big chance depending on the project in question, but it's still tons more likely for someone randomly clicking through commits to find a backdoor committed to a git repo than within autogenerated text in a tarball. I cli
283.
▲
by
dzaima
2y ago
The infected version was only the tarball, which was part of the obfuscation (i.e. people may look at git commits, but who individually checks autogenerated code in tarballs of every release) Building from the git commit the release claimed
284.
▲
by
dzaima
2y ago
The backdoor build script specifically checked for things indicating that it's being built for debian, and if not, not inserting the backdoor; so it only ever was non-reproducible in situations where reproducibility wasn't expecte
285.
▲
by
dzaima
2y ago
Looks like as of 2 weeks ago the unsafe block should no longer be required: https://github.com/rust-lang/stdarch/pull/1714 ..at least outside of loads/stores. From a bit of looking at the code though it
286.
▲
by
dzaima
2y ago
Needing to do serious work would correlate with Exo having multiple publications about its design. It's a broader sense of scheduling than "reorder trivially-independent instructions", but, if you remove the "trivially-&
287.
▲
by
dzaima
2y ago
You can quite often write C code that compilers will autovectorize into what you want.. if the thing in question is a simple case, or you put in effort into doing the non-trivial aspects yourself. e.g. for the loop reordering example [1] in
288.
▲
by
dzaima
2y ago
The GSUB lookups used are indeed the same thing that's used for ligatures.
289.
▲
by
dzaima
2y ago
It's more like 0.005%-0.02% of queries and like 0.001% of users depending on what statistics for Google you go by, but of course still very insignificant.
290.
▲
by
dzaima
2y ago
At the very end there's a "movzx eax, dl", i.e. zero-extend the low 8 bits of the accumulated value.
291.
▲
by
dzaima
2y ago
It's not that trivial: The wrapping version uses vpandn + vpaddb (i.e. `acc += 1 &~ elt`). On Intel since Haswell (2013) on ymm inputs that can manage 1.5 iterations per cycle, if unroll 2x to reduce the dependency chain. Whereas v
292.
▲
by
dzaima
2y ago
As far as the question in the OP is concerned, ISPC wouldn't help at all, as it'd necessarily go to basically equivalent LLVM IR.
293.
▲
by
dzaima
2y ago
> Those people are loudly declaring that they have under-invested in the crucial skills of reading, understanding and reviewing code written by other people. I suggest getting some more practice in. Reviewing code written for you by LLMs
294.
▲
by
dzaima
2y ago
OP didn't put much effort into writing the code so I'm certainly not putting in much effort into a proper review of it, for no benefit to me no less. I just wanted to see what quality AI gets you, and made a comment about it. I&#x
295.
▲
by
dzaima
2y ago
I definitely wouldn't say I'm lying (...to.. myself? what? or perhaps others for a quick untested response in a chatroom or something) whenever I write some code and it turns out that I misremembered the name of an API. "Hall
296.
▲
by
dzaima
2y ago
Some free code review of the first file I clicked into - https://github.com/williamcotton/webdsl/blob/92762fb724a9035... among other places should probably be doing the conditional "lexer->line++"
297.
▲
by
dzaima
2y ago
Humans can hallucinate up some API they want to call in the same way that LLMs can, but you don't call all human mistakes hallucinations; classifying everything LLMs do wrong as hallucinations would seem rather pointless to me.
298.
▲
by
dzaima
2y ago
Both Intel and AMD to some extent separate the vector ALUs and the register file in 128-bit (or 256-bit?) lanes, across which arithmetic ops won't need to cross at all. Of course loads/stores/shuffles still need to though, ma
299.
▲
by
dzaima
2y ago
There are x86 extensions for fp16/bf16 ops. e.g. both Zen 4 and Zen 5 support AVX512_BF16, which has vdpbf16ps, i.e. dot product of pairs of bf16 elements from two args; that is, takes a total of 64 bf16 elts and outputs 16 fp32 elts.
300.
▲
by
dzaima
2y ago
oops, haswell has only 3 SIMD ALUs, i.e. 768 bits of output per cycle, not 1024.
More ›