Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Sesse__
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
21 ms
·
361.
▲
by
Sesse__
1y ago
> The kindergartners were cute, they'd all where hi viz overalls on their afternoon walks and be tied together like sled dogs. They're typically not tied together. There's a rope and everybody is told to hold on to it (thi
362.
▲
by
Sesse__
1y ago
You can run stateless DHCPv6, i.e., without handing out prefixes. It's a fairly normal situation that clients choose their own addresses from prefixes handed out via RA, but that they get auxiliary configuration (such as UEFI boot, or
363.
▲
by
Sesse__
1y ago
Given that even LWN, with its consistently high-quality reporting, is struggling to make it, would there be room for a second one?
364.
▲
by
Sesse__
1y ago
Twice as much information. My go-to for I/Q is: Having two allows you to represent negative frequencies. With a normal, real signal, this is of course impossible (negative frequencies will automatically mirror the positive ones), but i
365.
▲
by
Sesse__
1y ago
Haha, yes, autovectorization is so much in the way sometimes. I have a bunch of hard-coded AVX2/AVX512 intrinsics lying around since the compiler can do it fine on Compiler Explorer but not in context. Still, having a stall on a single
366.
▲
by
Sesse__
1y ago
It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instru
367.
▲
by
Sesse__
1y ago
It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD. Then I moved stuff into huge precalced arrays instead, and it bec
368.
▲
by
Sesse__
1y ago
Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports. Perhaps instr
369.
▲
by
Sesse__
1y ago
I've used Intel PT several times; it's completely unbeatable for some things. In general, Intel is _way_ ahead of AMD in the performance monitoring game. For instance, IBS is a really poor replacement for PEBS (it still hits the w
370.
▲
by
Sesse__
1y ago
I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.
371.
▲
by
Sesse__
1y ago
The absl tables (the canonical Swisstables) are good, but not the fastest. Of course, everything will depend on your hardware, compiler and usage patterns, but if you look at an all-round benchmark like https://martin.ankerl.com&
372.
▲
by
Sesse__
1y ago
I was there in the 2000s and remember several people saying that.
373.
▲
by
Sesse__
1y ago
As someone who's been hired by Google twice, I'm very happy that I spent 99% of my time actually programming. (I did a day or two of Leetcode before the second time, just to make sure I was appropriately calibrated. It didn't
374.
▲
by
Sesse__
1y ago
It depends on having two CPU teams, though. There are not that many teams in the world that can design a high-performance microprocessor; I would assume that AMD has two and Apple has only one (which is why you got all these fillers with ju
375.
▲
by
Sesse__
1y ago
Great, now we just need the uops.info team to do the same. :-)
376.
▲
by
Sesse__
1y ago
I had real code that ran with IPC > 6 on Zen 3; I think that's the first time I've seen a modern CPU _really_ be ALU-bound. :-) But it was very unusual, and when I vectorized it, it ran completely different.
377.
▲
by
Sesse__
1y ago
Yeah, sure, you can iterate over the dense vector and check in the other side's sparse vector, that's correct.
378.
▲
by
Sesse__
1y ago
https://en.wikipedia.org/wiki/Argument_from_authority
379.
▲
by
Sesse__
1y ago
You are being downvoted because pasting AI output with no attempt at fact-checking is not bringing any real value to the discussion.
380.
▲
by
Sesse__
1y ago
True. The constant factor is nasty, though, compared to the 256-bits-per-instruction of normal bit sets.
381.
▲
by
Sesse__
1y ago
Sorry, I meant iterating over the sparse vector, not the dense vector (I find the nomenclature in the article somehow inverted).
382.
▲
by
Sesse__
1y ago
Yes, I'd say that the strongest part of autovectorization is that you can get more-or-less automatic support for wider/newer instruction sets than what you had when you wrote the code; older SIMD, like all other code, tends to rot
383.
▲
by
Sesse__
1y ago
So I looked at these briefly without AVX512, because only a tiny fraction of people have anything like that and the claim was that this would be a great way of making portable SIMD :-) Also, obviously you cannot use -ffast-math in real code
384.
▲
by
Sesse__
1y ago
An elegant optimization, but how would you intersect two of these efficiently? It sounds like you'd need to iterate over the entire dense vector and do a sparse-vector check for each and every value (O(m) with a very high constant fact
385.
▲
by
Sesse__
1y ago
Case in point, git is already much less confusing than it was at 1.0 and nobody complains it has gotten less powerful. (“Less confusing” does not mean “not confusing”, of course.)
386.
▲
by
Sesse__
1y ago
Yes? That's not in conflict with anything I said.
387.
▲
by
Sesse__
1y ago
Let me give you the last couple of routines that I was involved in vectorizing, no cherry-picking: - Skip to the first unmatched } (i.e., if there's two { in there, you are looking for the third }), ignoring anything inside "&
388.
▲
by
Sesse__
1y ago
> It's really not, things can be powerful and easy to use. I'd even say some parts of ffmpeg are well designed in this way like `ffmpeg -i ./video.mp4 ./video.wav` working is well designed. I'd argue that even th
389.
▲
by
Sesse__
1y ago
> Modern compilers all autovectorize really well. Usually writing plain canonical loops with plain C arrays is a good way to write portable optimal SIMD code. I don't think I've seen this happen once at work (always using recen
390.
▲
by
Sesse__
1y ago
At some point, one would imagine just making a less confusing FFmpeg CLI would be a better use of everyone's time. (I've sort-of understood it now, but the learning curve is pretty steep.)
More ›