Remnant44

Honestly, even a single adversarial reviewer agent, even of the same model, goes a very long way to catching and fixing this kind of thing too.

I'm one of the weirdos that still holds on to mercurial as I genuinely prefer it's methods and workflow to git most of the time.

How the author describes handling work trees is exactly how they work in hg, and I find it enormously convenient vs the way that git by default really wants you to branch with work trees.

This was an unexpected find on HN but I found it very moving. Good writing lets you do something that is almost impossible otherwise; to get a glimpse inside someone else's mind and experience, the thing that is forever hidden from us unassisted.

I think it's all too easy to view other humans almost like NPCs, and most of the interactions we have in our day to day life reinforce this. You interact with the grocery checker, the waiter, even unfortunately sometimes your loved ones, and those interactions are 'on rails', following a script.

What a nice change of pace from AI-written linked-in articles.

I haven't had a chance to dig into the repo at all, so that's excellent, thank you!

Looks very promising - I've been looking for a good delaunay library that supports constrained delaunay.

It looks like their performance benchmark is including multithreading, which although a useful feature, makes performance comparisons more difficult - would love to see a baseline single threaded performance as well.

Do you have any sources for this? I have also heard of rabbit starvation many times over the years, and it has always been in the context of too taking in too little fat -- essential fatty acids -- as well, due to the extreme leanness of the meat.

I agree with you, but also:

outside of anything else, amdahls law means that as the parallel performance grows, we become _more_ limited by the inherently serial code, and thus single core performance, not less.

Given that single core performance is "harder" (can't just throw more cores/sockets at the problem), it's also critically important.

It's a little dramatic to say avx512 is dead versus 10 - rather, I would say that avx10 finalizes a universally available set of avx512 extensions. For AVX 10.1, there's essentially, no difference after Intel backed out of reducing the vector length.

For at least the next decade AVX 512 will be the high performance target, reaching all of the zen4/5/6 CPUs as well as whatever avx-10 enabled CPUs Intel producers.

There's a whole lot of us out there. I don't know if there's still a future in the thing that I love, which is where all the malaise comes from.

I love me some isa extension, I'd love to know what these are intended and useful for for though. 1 bit inference? I hear they could be useful in crypto as well, but that's out of my field.

While you may be correct in the sense that, in a public acquisition statement, people should be inferring enormous context and not taking anything said at face value.

It's simultaneously true that this is the farthest thing from effective, honest, and clear communication. Reading between the lines here is required precisely because we all know that any acquisition statements made are, at best heavily coded, if not completely just fluff.

You can recognize that and still get angry that it's par for the course for such things to be not just devoid of useful information, but often actively deceiving.

Fort what it's worth, I had the exact same experience you did when I started writing SIMD code explicitly with intrinsics.

I avoided it for a long time because, well, it was so damn ugly and verbose to do simple things. However, in actual practice it's not nearly as painful as it looks, and you get used to it quickly.

AVX doesn't require alignment of any memory operands, with the exception of the specific load aligned instruction. So you/the compiler are free to use the reg,mem form interchangibly with unaligned data.

The penalty on modern machines is an extra cycle of latency and, when crossing a cacheline, half the throughput (AVX512 always crosses a cacheline since they are cacheline sized!). These are pretty mild penalties given what you gain! So while it's true that peak L1 cache performance is gained when everything is aligned.. the blocker is elsewhere for most real code.

There are many situations where your data is essentially _majority_ unaligned. Considerable effort by the hardware guys has gone into making that situation work well.

A great example would be a convolution-kernel style code - with AVX512 you are using 64 bytes at a time (a whole cacheline), and sampling a +- N element neighborhood around a pixel. By definition most of those reads will be unaligned!

A lot of other great use cases for SIMD don't let you dictate the buffer alignment. If the code is constrained by bandwidth over compute, I have found it to be worth doing a head/body/tail situation where you do one misaligned iteration before doing the bulk of the work in alignment, but honestly for that to be worth it you have to be working almost completely out of L1 cache which is rare... otherwise you're going to be slowed down to L2 or memory speed anyways, at which point the half rate penalty doesn't really matter.

The early SSE-style instructions often favored making two aligned reads and then extracting your sliding window from that, but there's just no point doing that on modern hardware - it will be slower.

which honestly, shouldn't be neccessary today with avx512. There's essentially no reason to prefer the aligned load/store commands over the unaligned ones - if the actual pointer is unaligned it will function correctly at half the throughput, while if it_is_ aligned you will get the same performance as the aligned-only load.

No reason for the compiler to balk at vectorizing unaligned data these days.