Live data from Hacker News

Viewing profile — boomanaiden154

boomanaiden154

HN member
Joined
Mon, Nov 28, 2022, 6:31 AM UTC
HN karma
103
Public activity
46 items

About boomanaiden154

No profile information was provided.

Recent public activity

  1. comment
    Comment #47597048

    Found it. It was https://www.phoronix.com/news/Intel-Thin-Layout-Optimizer . It was open source, but has since been deprecated.

  2. comment
    Comment #47597037

    Propeller can’t really do many instruction level modifications due to how it works (constructs a layout file that then gets passed to the linker). BOLT could do this, but does not …

  3. comment
    Comment #47597021

    I might be thinking of a different project then... I swore Intel had their own PLO tool, but I can only find https://github.com/clearlinux/distribution/issues/2996 .

  4. comment
    Comment #47596901

    Post link optimization (PLO) tools have been around for quite a while. In particular, Meta’s BOLT (fully upstream in LLVM) and Google’s Propeller (somewhat upstream in LLVM, but fu…

  5. story
  6. comment
    Comment #45910461

    Quite a few patches have landed. A couple features using this have already shipped in Apple’s downstream clang.

  7. comment
    Comment #40831783

    You can make the synthetic benchmarks relatively accurate, it just takes effort. The compile-time hit and additional effort is often worth it for the extra couple percent for impor…

  8. comment
    Comment #40827257

    I'm not sure where you're getting your information from. Chrome (and many other performance-critical workloads) is using instrumented PGO because it gives better performance gains,…

  9. comment
    Comment #40826417

    It's not called AutoFDO. AutoFDO refers to a specific sampling-based profile technique out of Google ( https://dl.acm.org/doi/abs/10.1145/2854038.2854044 ). Sometimes people will r…

  10. comment
    Comment #40826071

    Do you have more information on how the dataset was constructed? It seems like somehow build systems were invoked given the different targets present in the final version? Was it m…

  11. comment
    Comment #40825182

    I'm not sure it's likely that the LLM here learned from gcc. The size optimization work here is focused on learning phase orderings for LLVM passes/the LLVM pipeline, which wouldn'…

  12. comment
    Comment #40825118

    This would be difficult to deploy as-is in production. There are correctness issues mentioned in the paper regarding adjusting phase orderings away from the well-trodden O0/O1/O2/O…

  13. comment
    Comment #40825074

    Sure, performance is more interesting, but it's significantly harder. With code size, you just need to run the code through the compiler and you have a deterministic measurement fo…

  14. comment
    Comment #40825046

    I'm reasonably certain the authors are aware of alive2. The problem with using alive2 to verify LLM based compilation is that alive2 isn't really designed for that. It's an amazing…

  15. comment
    Comment #40825015

    PGO can be used in such situations, but the profile needs to be checked in. Same code + same profile -> same binary (assuming the compiler is deterministic, which is tested quite e…

  16. comment
    Comment #40824997

    I would not say we are anywhere close to perfect in compilation. Even just looking at inlining for size, there are multiple recent studies showing ~10+% improvement ( https://dl.ac…

  17. comment
    Comment #40824971

    Right, it's only solving phase ordering. In practice though, correctness even over ordering of hand-written passes is difficult. Within the paper they describe a methodology to eva…

  18. comment
    Comment #39746245

    LLVM doesn’t spend really any runtime solving the phase ordering problem since the pass pipelines are static. There have been proposals to dynamically adjust the pipeline based on …

  19. comment
    Comment #38965749

    Pretty much this. It's called Alive2. https://dl.acm.org/doi/abs/10.1145/3453483.3454030

  20. comment
    Comment #37552890

    ML for phase ordering is just one problem that ML could solve within compilers. Heuristic replacement (like loop unrolling) is another big one. For the specific case of loop unroll…

  21. comment
    Comment #37552865

    What's the benefit of having an LLM do those things in a way that guesstimates? There are big wins to be had in code-size and some wins to be had in performance related to inlining…

  22. comment
    Comment #37552794

    Most of the work in this space is not focused on neural compilation (having a ML model perform the transformation/entire compilation), but on replacing heuristics or phase ordering…

  23. comment
    Comment #37552492

    I did a bit of work on this last summer on (much) smaller models [1] and it was briefly discussed towards the end of last year's MLGO panel [2]. For heuristic replacements specific…

  24. comment
    Comment #37550820

    You're right that a decrease in code size doesn't mean a performance increase (and oftentimes they can be inversely correlated like in inlining). But LLVM targets both depending up…

  25. comment
    Comment #37550532

    I'm not sure a fully correct production optimizing compiler is that feasible. LLVM gets multiple miscompilation reports per week (from what I've haphazardly seen observing the issu…