[HN Gopher] Scalable self-improvement for compiler optimization
       ___________________________________________________________________
        
       Scalable self-improvement for compiler optimization
        
       Author : matt_d
       Score  : 75 points
       Date   : 2024-11-01 20:55 UTC (4 days ago)
        
 (HTM) web link (research.google)
 (TXT) w3m dump (research.google)
        
       | pvillano wrote:
       | Someone once said the most fruitful research in AI is making
       | models scale to larger compute/data.
       | 
       | I think the same could become true for compilers, and I think
       | equality saturation is the key. AI + equality saturation could
       | scale the optimization of a single program to an entire data
       | center
        
         | namibj wrote:
         | Happy to collaborate towards such.
        
         | algo_trader wrote:
         | I feel there is only so much you can squeeze out of a compiler
         | 
         | IMHO we need to accept profile-based compiling or dynamic JIT
         | to keep making progress on performance
         | 
         | EDIT: of course there is still lots of low hanging fruit for
         | exploiting specific instruction sets or memory architectures
        
       | vanderZwan wrote:
       | I find it a little annoying that in the paper[0] they show
       | various graphs of megabytes _saved_ in the paper, but no actual
       | _size_ of the binaries that these policies are applied to, as far
       | as I can tell.
       | 
       | So when they say the inline policies end up saving 20 MiB on the
       | training data, and then only a few megabyte on a different binary
       | not in the training data, I lack the context to really judge what
       | that says. Is the other binary much smaller? The same size? What
       | if it's _bigger_ and therefore hides a much smaller relative size
       | savings?
       | 
       | At the very end of the paper do they mention one binary size:
       | namely that they save about 3 MB on the Chrome on Android binary,
       | which is 213.32 MB after implementing the policy. A solid 1%,
       | probably makes an enormous difference at Google Scale, especially
       | for their main Android browser, so I hope it's obvious that I'm
       | not trying to diminish the achievement of these people. But I
       | find the other benchmarks kind of hard to interpret.
       | 
       | [0] https://arxiv.org/pdf/2403.19462
        
         | KolmogorovComp wrote:
         | They mention an overhaul improvement of 1% > After seven
         | iterations of our algorithm we find a size reduction of
         | approximately 1% compared to the evolutionary strategy
         | baseline. See the paper for more detailed results
        
       ___________________________________________________________________
       (page generated 2024-11-05 23:00 UTC)