61–70 of 84 posts
I remember listening to one of the Lex Fridman interviews with Jim Keller where he said that modern branch prediction in CPUs was now done by “neural nets” in silicon. Does anyone here have any insight into this?
I think it predates that nomenclature. Google around for "perceptrons" instead. https://www.cs.utexas.edu/~lin/papers/hpca01.pdf
Of course that assumes you can profile your program with realistic "production" workloads, and it'll need two compilation passes, so having sensible ML defaults boxes sense.
But it's odd not to compare this to PGO in terms of the resulting performance.
Earlier quoted context omitted.
GCC was for many years designed to be hard to work on/with => LLVM steals it's lunch GCC is under the GPL v3 . This does not bother me so much combined with the former it's bad for getting corporations to spend money on you
Stallman hasn't been relevant to GCC in 10-15 years. If people aren't doing research projects with it, it's because they don't like the code style (which is still weird but not monolithic) or their funders aren't using it in production.
> This code is licensed under a BSD-like license [8], and LLVM itself will not initially be assigned to the FSF. If people are seriously in favor of LLVM being a long-term part of GCC, I personally believe that the LLVM community would agree to assign the copyright of LLVM itself to the FSF and we can work through these details.
The leads of the project offered LLVM to the FSF and the offer was ignored because of Stallman's incompetent approach to email.
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
GCC's irrelevance and LLVM's dominance of the field are definitely his fault (even if there are other factors involved.)
Earlier quoted context omitted.
In general, every heuristic in systems programming --- kernels z compilers, databases, whatever --- is an opportunity to substitute an ML system.
today, learned heuristics have a couple of pitfalls that make them hard to add to such systems 1. they are usually hard to run efficiently 2. they are usually hard to explain The former is definitely changing with low precision formats like fp16 and useful coprocessors that can do matrix multiplications efficiently (M1, Intel). The latter hasn't been developed much and unless you're just training a model to memorize…
I also wonder how this would look like for mainlining. Should the LLVM project depend on tensorflow now? IIRC tensorflow itself depends on LLVM so to avoid circular dependencies, does there have to be a ML-free version of LLVM that tensorflow depends on, which is then used by the proper LLVM? Or can inference be converted into simple C like it was for lpcnet? Lastly, there is the general question of integration of ML models into open source projects. Say it is merged and the old manual heuristic is deleted. What if Google one day decides they don't want to maintain the component any more? Can LLVM maintainers do any refactors of the code around it? Unless Google also shares their training infrastructure, LLVM maintainers can't re-train the model on the post-refactor data.
[0]: https://old.reddit.com/r/rust/comments/k9r3s4/fuchsia_lines_...
Earlier quoted context omitted.
From my work, I've found it's really simple and straightforward to apply. 1. Choose a parameter for your compiler, xxx. 2. Have your ML model "choose compiler config parameter yyy." After the ML model "chooses" the config parameters, work backwards. 3. Determine why yyy is a better config parameter than xxx. It might not be! This system works, brilliantly. Cyborg intelligence, a combination of the human being and the…
> Choose a parameter for your compiler, xxx Most interesting cases don't really look like this. The heuristic is applied to the user's code; it's not a one-time knob in the compiler. If it were, then you would likely be able to afford an exhaustive search to pick it & wouldn't need ml.
The analogy I'm making doesn't especially apply to compilers, which have human defined defaults in the first place.
What I've found is that it's important to not run the ML model then use its output as the default state. Have a human, heuristic choice as the default state.
Inlining by itself only decreases code size if there's provably a single call site. What's doing the work here is branch folding after the inline.
Alternative is specialising the function wrt the predicate and rewriting call sites to the specialisation when the predicate is known.
Harder than inline branchy things and hope for the best but tractable and bounds the code size increase.
I remember listening to one of the Lex Fridman interviews with Jim Keller where he said that modern branch prediction in CPUs was now done by “neural nets” in silicon. Does anyone here have any insight into this?
I think it predates that nomenclature. Google around for "perceptrons" instead. https://www.cs.utexas.edu/~lin/papers/hpca01.pdf
... and 1-2% improvement in performance via the register allocator.
It's usually done heuristically in a fashion that scales badly with how many instructions you're considering at a time so it's really easy to overfit to today's benchmark.
I remember a while back reading a paper about using superoptimizers to auto-generate peephole optimizations; anyone know if that ever got deployed anywhere?