Microbenchmarks. A LUT will win many of them but you pessimise the rest of the code. So unless a significant (read: 20+%) portion of your code goes into the LUT, there isn't that much point to bother. For almost any pure calculation without I/O, it's better to do the arithmetic than to do memory access.
Locality within the LUT matters too: if you know you're looking up identical or nearby-enough values to benefit from caching, an LUT can be more of a win. You only pay the cache cost for the portion you actually touch at runtime.
I could imagine some graphics workloads tend compute asin() repeatedly with nearby input values. But I'd guess the locality isn't local enough to matter, only eight double precision floats fit in a cache line.
By interpolating between values you can get excellent results with LUTs much smaller than 32KB. Will it be faster than the computation from op, that I don't know.
I experimented a bit with the code. Various tables with different datatypes. There is enough noise from the Monte Carlo to not make a difference if you use smaller data types than double or float. Even dropping interpolation worked fine, and got the speed to be on par with the best in the article, but not faster.
Does your benchmark use sequential or randomly ordered inputs? That would make a substantial difference with an LUT, I would think. But I'm guessing. Maybe 32K is so small it doesn't matter (if almost all of the LUT sits in the cache and is never displaced).
> if you use smaller data types than double or float. Even dropping interpolation worked fine,
That's kinda tautological isn't it? Of course reduced precision is acceptable where reduced precision is acceptable... I guess I'm assuming double precision was used for a good reason, it often isn't :)
I didnt inspect the rest of the code but I guess the table is fetched from L2 on every call?
I think the L1 data cache is flooded by other stuff going on all the time.
About dropping the interpolation: Yes you are right of course. I was thinking about the speed. No noticable speed improvement by dropping interpolation. The asin calls are only a small fraction of everything.
I'm very skeptical you wouldn't get perceptible visual artifacts if you rounded the trig functions to 4096 linear approximations. But I'd be happy to be proven wrong :)
Log Base 2 of 3 = ~1.5849625, so that's the limit to how well you can pack three-state values into bits of data.
For something more practical, you can pack five three-state values within a byte because 3^5 = 243, which is smaller than 256. To unpack, you divide and modulo by 3 five separate times. This encodes data in bytes at 1.6 bits per symbol.
But the packing of 5 symbols into a byte was not done here. Instead, they packed 4 symbols into a byte to reduce computational complexity (no unpacking needed)
I guess they could model the river mathematically. I would not be surprised if there are two or more "stable" stream patterns. Perhaps it resets naturally after one year.
Sure they could... the problem is just that apparently no structural changes were made during the cleanup, but the wave was there before they turned the water off and gone after they turned it back on. And they don't have to wait for a year, they can adjust the flow - the wave is situated in a "brook" very near the point where it exits a tunnel through which it flows under much of the city, so it's heavily regulated (see this map for all Munich "brooks" on the West side of the Isar: https://upload.wikimedia.org/wikipedia/commons/f/f3/Karte_M%... - blue are the current ones, dark blue is in tunnel, the purple ones are historical, the Eisbach is #55 in the top right corner).
One of my math teachers in university always brought with him a dry sponge in a small blue bag. (a lighter sponge that you don't wet before use). Brilliant lecturer.
It’s quite common for a DOI to be assigned to a paper after it’s accepted during camera ready. However, the DOI won’t work until the conference or journal version is published on the official website (ACM in this case). The version you’re viewing now is simply a preprint directly from the authors.
AST parsing fails primarily due to installation issues, not syntax errors in your code.
TheAuditor uses a sandboxed environment (.auditor_venv/) to avoid polluting your system. When Tree-sitter
isn't properly installed in that sandbox, we fall back to regex patterns. Common causes:
1. Missing C compiler - Tree-sitter needs to compile language grammars
2. Incomplete setup - User didn't run aud setup-claude --target . which installs the AST tools
3. Old installation - Before we fixed the [ast] dependency inclusion
If your code had syntax errors, you'd get different errors entirely (and your code probably wouldn't run). The
"AST parsing fails" message specifically means Tree-sitter isn't available, so we're using the fallback regex patterns instead.
Just pushed clearer docs about this today actually. Run aud setup-claude --target . in your project and
Tree-sitter should work properly.
Conversely, I often think about the value I add by being interruptable, by helping my colleague with something that might save him more time than I lose. Good for the company.
This is a valid point. But another aspect of interruptions is if they add to the experience of stress, and thus contribute to a toxic work environment.
Well, no, the thing that should never cross your mind is prioritising the company over yourself or other human beings.
The entire reason the company is employing you is to have you do things that are good for it. If you want them to keep employing you (and also to give you more money) then you should be looking out for things that are good for the company, doing them and then making sure that management knows that it was you that did it.
