Live data from Hacker News

Google ML Compiler Inlining Achieves 3-7% Reduction in Size

ai.googleblog.com

41–50 of 84 posts

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#41
post #40

I wonder if the ML is deterministic or not. Otherwise you compile twice and get completely different binaries.

It'll be 100% deterministic.

Reproducibility is a big part of Google's internal build system, and they wouldn't be able to deploy something that broke that.

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#42
post #40

I wonder if the ML is deterministic or not. Otherwise you compile twice and get completely different binaries.

It'll be 100% deterministic. Reproducibility is a big part of Google's internal build system, and they wouldn't be able to deploy something that broke that.

What about reproducibility of the compiler binaries? I got the impression that model training itself isn't deterministic across training hardware? Since the model is embedded in the binaries, then the binaries aren't really reproducible if the model isn't. How big is the data used to train the model? How costly is it to train the model?

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#44

Neat. It seems like it's sort of built in to LLVM right now, but not usable unless you build LLVM yourself with pretrained models as part of the build process?

How big are the models? If just a few megabytes, why not just check them into the llvm git repo?

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#45
post #12

Using 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…

Same for gc and database parameters. You can still get decent gains tweaking those and ml could help.

I also played around with using ml to optimise auto scaling of CI instances. (taking time of day and queue sizes into account)

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#46

Neat. It seems like it's sort of built in to LLVM right now, but not usable unless you build LLVM yourself with pretrained models as part of the build process?

How big are the models? If just a few megabytes, why not just check them into the llvm git repo?

I'm not sure - https://github.com/google/ml-compiler-opt#pretrained-models says the they sometimes get released on GitHub but I couldn't see anything obvious in that repo.

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#47
post #42

Earlier quoted context omitted.

It'll be 100% deterministic. Reproducibility is a big part of Google's internal build system, and they wouldn't be able to deploy something that broke that.

What about reproducibility of the compiler binaries? I got the impression that model training itself isn't deterministic across training hardware? Since the model is embedded in the binaries, then the binaries aren't really reproducible if the model isn't. How big is the data used to train the model? How costly is it to train the model?

Based on https://github.com/google/ml-compiler-opt#pretrained-models, it seems like the models are versioned, so I guess they'd update their models when updating LLVM or something like that.

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#48
post #42

Earlier quoted context omitted.

It'll be 100% deterministic. Reproducibility is a big part of Google's internal build system, and they wouldn't be able to deploy something that broke that.

What about reproducibility of the compiler binaries? I got the impression that model training itself isn't deterministic across training hardware? Since the model is embedded in the binaries, then the binaries aren't really reproducible if the model isn't. How big is the data used to train the model? How costly is it to train the model?

From the post:

> The TensorFlow model is embedded with XLA AOT, which converts the model into executable code.

Taking the TF model to executable code should be deterministic.

Generating the TF model might not be (depends on implementation and hardware).

But it's unclear from this if this is a problem in practice - it's not uncommon for non-deterministic models to end up producing the same output because you perform thresholding/quantizing or some analogous process to convert it into a classification style output.

I.E. here, you are generating operations, which you can setup as a classification problem: Given this input and this history what is the next operation.

And of course you can always got back to your saved model and generate the code from that.

While the exact scores for the next operation might be non-deterministic you always end up with the highest scoring one being the same.

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#49

Earlier quoted context omitted.

I still want to see the estimated distance heuristic ( https://dspace.library.uvic.ca/bitstream/handle/1828/7107/Bu... ) in a modern compiler.

Variants of this have been tried. What are you hoping for?

> Variants of this have been tried

Have a link?

Re: Google ML Compiler Inlining Achieves 3-7% Reduction in Size

#50

Compilers 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?

Which you should use are often unknowable because it's often about how the code is driven by the data - you need to know the characteristics of the data to know how the code will behave, only then can you meaningfully talk about picking a 'better' heuristic.

Analogy: otherwise you're just optimising the design of a car. But optimising it for what? speed, efficiency, reliability, price, weight, carrying capacity... You first need to know how it's expected to be used.

I guess local inlining might sometimes be an unconditional win, but even then only under specific circumstances.

(disclaimer: I know something but am not an expert)

Post reply on HN