stephencanon
stephencanon on Hacker News
I really don't think I was doing anything especially clever and it was running at 32% for me over 50 samples. That's much worse than chance.
> I don't think we're far from every bit of prose online, being at least edited, if not authored, by AI.
Zero chance of that happening anytime soon. I'm sure a lot of people have adopted it, and more will follow, but there are still plenty of us who enjoy writing and have no desire to let AI tools take that away from us.
> I'm not saying I find the prospect thrilling; just that it's inevitable.
I see no reason why this should be the case. All you have to do is keep writing and it's suddenly not inevitable.
I've only had a couple weeks in rentals with automatic emergency braking, and was very nearly been rear-ended twice due to false positives. Anecdotal, and I'm sure they'll improve with time, but I would never allow the system I experienced anywhere near a car I owned. It was profoundly unsafe.
I would assume that the state law protects parents against a city adding a restriction in their municipal code.
Gated communities, by their nature, attract and encourage the sort of busybodies who think that everyone needs to be protected from everything.
Our neighborhood in the northeast US does the same (minus the hard prohibition against parents going with them). Our 5 and 9 year old walk to school daily, usually picking up the neighbors' kids (6, 6, 10, 9, 7, 7) along the way. If we happen to be free sometimes an adult will walk with them, sometimes we start walking with them and then stop for coffee with a neighbor while the kids continue on, sometimes they go by themselves.
I can't imagine living somewhere where that was prohibited.
That’s exactly the same rule with more words (postfix = right, prefix = left).
This comes up every so often, and while it's sort of almost true and attractive, it isn't actually correct.
The correct rule is "follow the C grammar". An easier to remember and also correct rule is "start at the identifier being declared; work outwards from that point, reading right until you hit a closing parenthesis, then left until you hit the corresponding open parenthesis, then resume reading right..." (this is sometimes called the "right-left rule": https://cseweb.ucsd.edu/~gbournou/CSE131/rt_lt.rule.html).
It's very cool. Thank you!
"Centrist" in practice means "more or less content with the status quo." That is fundamentally a conservative position orthogonal to any notion of "facts".
The work discussed in this post shipped in the OS last year (fall 2025), so nothing here is dependent on very recent changes.
Field hockey is almost exclusively a girls sport in the US, while boys have (American) football in the fall. Both draw from the potential pool of soccer players in US middle and high schools.
“in a real race we have no actual chance of winning” is an absolutely wild thing to say in response to a link to a real race in which the human has won the last few years in a row.
What sort of engineering standards are these Cybertrucks built to?
Oh, very rigorous engineering standards. The wheels aren't supposed to fall off for a start.
We have a ground-source heat pump for our ADU. We did it because we were curious about just how efficient we could make the house, but I don't expect that it will ever break even financially vs a modern air-source system with resistive backup in our climate (northern New England, typically very few –20˚ nights, –10˚-0˚ more common with daytime highs in the single digits).
It works great, but it's hard to see a way to it making sense for most folks here.
Prior to the current generation Intel designs, Apple’s branch predictor tables were a good deal larger than Intel’s IIRC, so depending on benchmarking details it’s plausible that Apple Silicon was predicting every branch perfectly in the benchmark, while Intel had a more real-world mispredict rate. Perf counters would confirm.
The CORE-MATH project authors, most of whom are French academics (including the author of the linked paper).
I don’t know of any interesting work in this space that came out of Red Hat, why do you suggest them?
"I'd like to thank my mother, Ayn Rand, and God" is the usual example.
Yes, you can reorder the list to remove the ambiguity, but sometimes the order of the list matters. The serial comma should be used when necessary to remove ambiguity, and not used when it introduces ambiguity. Rewrite the sentence when necessary. Worth noting that this is the Oxford University Press's own style rule!
That would fall under "more constrained", due to process limits.
Enlarging a branch predictor requires area and timing tradeoffs. CPU designers have to balance branch predictor improvements against other improvements they could make with the same area and timing resources. What this tells you is that either Intel is more constrained for one reason or another, or Intel's designers think that they net larger wins by deploying those resources elsewhere in the CPU (which might be because they have identified larger opportunities for improvement, or because they are basing their decision making on a different sample of software, or both).
Your students should be able to figure out if a computation is exact or not, because they should understand binary representation of numbers.
You can often eke something out for order-four, depending on uArch details. But basically yeah.
For throughput-dominated contexts, evaluation via Horner's rule does very well because it minimizes register pressure and the number of operations required. But the latency can be relatively high, as you note.
There are a few good general options to extract more ILP for latency-dominated contexts, though all of them trade additional register pressure and usually some additional operation count; Estrin's scheme is the most commonly used. Factoring medium-order polynomials into quadratics is sometimes a good option (not all such factorizations are well behaved wrt numerical stability, but it also can give you the ability to synthesize selected extra-precise coefficients naturally without doing head-tail arithmetic). Quadratic factorizations are a favorite of mine because (when they work) they yield good performance in _both_ latency- and throughput-dominated contexts, which makes it easier to deliver identical results for scalar and vectorized functions.
There's no general form "best" option for optimizing latency; when I wrote math library functions day-to-day we just built a table of the optimal evaluation sequence for each order of polynomial up to 8 or so and each microarchitecture and grabbed the one we needed unless there were special constraints that required a different choice.
When Intel specced the rsqrt[ps]s and rcp[ps]s instructions ~30 years ago, they didn't fully specify their behavior. They just said their relative error is "smaller than 1.5 * 2⁻¹²," which someone thought was very clever because it gave them leeway to use tables or piecewise linear approximations or digit-by-digit computation or whatever was best suited to future processors. Since these are not IEEE 754 correctly-rounded operations, and there was (by definition) no software that currently used them, this was "fine".
And mostly it has been OK, except for some cases like games or simulations that want to get bitwise identical results across HW, which (if they're lucky) just don't use these operations or (if they're unlucky) use them and have to handle mismatches somehow. Compilers never generate these operations implicitly unless you're compiling with some sort of fast-math flag, so you mostly only get to them by explicitly using an intrinsic, and in theory you know what you're signing up for if you do that.
However, this did make them unusable for some scenarios where you would otherwise like to use them, so a bunch of graphics and scientific computing and math library developers said "please fully specify these operations next time" and now NEON/SVE and AVX512 have fully-specified reciprocal estimates,¹ which solves the problem unless you have to interoperate between x86 and ARM.
¹ e.g. Intel "specifies" theirs here: https://www.intel.com/content/www/us/en/developer/articles/c...
ARM's is a little more readable: https://developer.arm.com/documentation/ddi0596/2021-03/Shar...
For the asinf libcall on macOS/x86, my former colleague Eric Postpischil invented the novel (at least at the time, I believe) technique of using a Remez-optimized refinement polynomial following rsqrtss instead of the standard Newton-Raphson iteration coefficients, which allowed him to squeeze out just enough extra precision to make the function achieve sub-ulp accuracy. One of my favorite tricks.
We didn't carry that algorithm forward to arm64, sadly, because Apple's architects made fsqrt fast enough that it wasn't worth it in scalar contexts.
Ideally either one is just a library call to generate the coefficients. Remez can get into trouble near the endpoints of the interval for asin and require a little bit of manual intervention, however.
Newer rsqrt approximations (ARM NEON and SVE, and the AVX512F approximations on x86) make the behavior architectural so this is somewhat less of a problem (it still varies between _architectures_, however).
These sorts of approximations (and more sophisticated methods) are fairly widely used in systems programming, as seen by the fact that Apple's asin is only a couple percent slower and sub-ulp accurate (
https://members.loria.fr/PZimmermann/papers/accuracy.pdf). I would expect to get similar performance on non-Apple x86 using Intel's math library, which does not seem to have been measured, and significantly better performance while preserving accuracy using a vectorized library call.
The approximation reported here is slightly faster but only accurate to about 2.7e11 ulp. That's totally appropriate for the graphics use in question, but no one would ever use it for a system library; less than half the bits are good.
Also worth noting that it's possible to go faster without further loss of accuracy--the approximation uses a correctly rounded square root, which is much more accurate than the rest of the approximation deserves. An approximate square root will deliver the same overall accuracy and much better vectorized performance.