Tried to build it but it references a `cmake/GenerateMenuHelpHeader.cmake` that seems to be absent from the repository?
418 karma · joined July 18, 2019
That’s exactly the point. Why would you expect others to even entertain a vague claim like that if you give them no reason to find it plausible? “Just test it yourself” (test what?) i.e. “prove me right yourself” is not going to be very successful.
I too am French and I’m more puzzled by you than by the driver. Am I secretly German?
“Entity Component System”, for those like me who didn’t immediately think of it.
Modern, portable SIMD libraries are making it increasingly close to that. Highway is my personal favourite, thanks in part for its support for runtime dispatch.
(Disclaimer: I work at Google, but not on Highway, and am writing in my personal capacity.)
Yes. I advocate for doing that.
> So GPT models on the same ~intelligence level, are then 50% cheaper.
How did you reach this conclusion? Opus 5 high ($1.06) has the same “intelligence index” as GPT 5.6 Sol max ($1.04). Opus 5 medium ($0.62) performs a bit below GPT 5.6 Sol xhigh ($0.68) but slightly above GPT 5.6 Sol high ($0.45).
That the most expensive variant is expensive doesn’t really tell us much.
When it can be single-handedly responsible for an 8× speedup, you might not want to rely as much on the compiler as in the case of smaller, cumulative optimisations.
> And what is the alternative? Handroll manual SIMD code for every possible architecture you may target?
Use a library like Highway? https://github.com/google/highway
What if the “explicit acceleration library” for what you need to do doesn’t exist?
Counterpoint: https://pharr.org/matt/blog/2018/04/18/ispc-origins
> I think that the fatal flaw with the approach the compiler team was trying to make work was best diagnosed by T. Foley, who’s full of great insights about this stuff: auto-vectorization is not a programming model.
> The problem with an auto-vectorizer is that as long as vectorization can fail (and it will), then if you’re a programmer who actually cares about what code the compiler generates for your program, you must come to deeply understand the auto-vectorizer. Then, when it fails to vectorize code you want to be vectorized, you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single compiler’s implementation—something you wouldn’t otherwise need to care about one bit.
> And God help you when they release a new version of the compiler with changes to the auto-vectorizer’s implementation.
> With a proper programming model, then the programmer learns the model (which is hopefully fairly clean), one or more compilers implement it, the generated code is predictable (no performance cliffs), and everyone’s happy.
NumPy-like:
mean = np.mean(array)
maximum = np.max(np.abs(array)
return mean / maximum
Highway:
HWY_FULL(float) d;
using V = decltype(hn::Zero(d));
V sum = hn::Zero(d);
V max = hn::Zero(d);
hn::Foreach(d, values, N, hn::Zero(d), [&](auto d, auto v) HWY_ATTR {
sum = hn::Add(sum, v);
max = hn::Max(max, hn::Abs(v));
});
const float mean = hn::ReduceSum(d, sum) / N;
return mean / hn::ReduceMax(d, max);
When the actual computation is made so much faster by SIMD, memory bandwidth starts to be a significant bottleneck.
More valuable than learning to write SIMD code? When writing SIMD code is itself the remedy to lousy autovectorisation?
If you can only identify the problem, you’re left with “well, that sucks”.