while less important, I'm curious what the impact was on compile times.
Negligible
Google ML Compiler Inlining Achieves 3-7% Reduction in Size
21–30 of 84 posts
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#22Earlier quoted context omitted.
I think for >99% of folks, ML means machine learning, even if you put compiler after it.
Eh, the OCaml crowd is surely reasonably large, and they would all be familiar with ML. I had the same question as the parent commenter and had to wait until the page loaded before determining whether the article was about machine learning or the programming language.
> the OCaml crowd is surely reasonably large
...and other things HNers tell themselves. More at 11.
Seriously tho, I’m unable to find market share numbers because most survey results only list the top 35 or so languages. The last one is COBOL at 0.5%. For comparison, the Lizardman Constant is 4%: https://slatestarcodex.com/2013/04/12/noisy-poll-results-and...
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#23Earlier quoted context omitted.
The thing is that GCC successfully shot its own head off via Stallman so no one cares about doing research with it anymore. The licence doesn't help but most of this work is open source anyway
What do you mean about GCC shooting itself in the head? What do you mean about its license?
GCC was for many years designed to be hard to work on/with => LLVM steals it's lunch
GCC is under the GPLv3. This does not bother me so much combined with the former it's bad for getting corporations to spend money on you
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#24Using ML inside compilers has a lot of untapped potential I think. People think of a compiler as an AI when they're actually very stupid in terms of the number of decisions available to them. Feedback is the lifeblood of intelligent performance, it is more than possible to fake that feedback using AI. E.g. Your error callback is on the balance of probability going to be called less than the (say) core matrix multiply…
you might be interested in CompilerGym https://compilergym.com
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#25Compilers have soooo many heuristics. And a lot of it looks like a chess or Go game: You have a list of 100s of AST optimization passes (possible moves) that preserve the semantics of the program but you have limited compute with which to run iterations of these passes. What order and combination of these should you use?
In general, every heuristic in systems programming --- kernels z compilers, databases, whatever --- is an opportunity to substitute an ML system.
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#26Compilers have soooo many heuristics. And a lot of it looks like a chess or Go game: You have a list of 100s of AST optimization passes (possible moves) that preserve the semantics of the program but you have limited compute with which to run iterations of these passes. What order and combination of these should you use?
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 the entire space the heuristic operates in, it can be scary to trust it on unseen data.
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#27The (current) title used on HN ( “Google ML Compiler Inlining Achieves 3-7% Reduction in Size” ) is confusing. It made me think Google is using ML ( https://en.wikipedia.org/wiki/ML_(programming_language) ) It also is not the one of the referred page, which is “MLGO: A Machine Learning Framework for Compiler Optimization” . This is about an LLVM extension that uses Machine Learning. I think it would be better to chan…
I think for >99% of folks, ML means machine learning, even if you put compiler after it.
A quick google search on the subject is not so clear cut (try ML compiler and Compiler ML).
In either case, this is a discussion of compilers where audience skews toward an interest in programming languages. In this context abbreviation is ambiguous.
I think a rename would be helpful in clearly outlining the subject. Something like 'Google Deep Learning based Compiler Achieves 3-7% reduction in size' would get the point across clearly.
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#28Earlier 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…
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 ML model, is the future of society.
The key is the ML "suggests." ML must keep "suggesting."
Never have ML choose a parameter autonomously.
That's exactly how you get self driving cars running over children.
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#29[deleted]
Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size
#30while less important, I'm curious what the impact was on compile times.
I would imagine it was essentially nil, if not an occasional speedup.
For one thing, the heuristics it replaces are not always super-cheap to compute.