24 ms·

Make LLVM Fast Again

582 points by notriddle 6y ago

simonw 6y ago
As a general rule, "Make X Y again" is worth avoiding - it has connotations that are likely to distract from the message you are trying to put across. This is a great post full of really interesting technical details. Don't be put off by the title!
- aogl 6y ago
  .. yet it's the exact click bait that will make many visit..
- Thorentis 6y ago
  It's become a well-known catch phrase now. It's only a distraction if you find yourself offended by it, which frankly with everything that's going on right now, is pretty thin-skinned.
  - simonw 6y ago
    I stand by my comment. If you want people to read your content, you should avoid phrases like this. Hence why I called it "distracting" - it is.
    - echelon 6y ago
      Being offended by things is dangerous to our culture. You can stand up for the rights and freedoms of others without turning your nose. Showing that something doesn't bother you reduces the power bullies and oppressors have over you. You can even reframe it. Make America Socialist Again. See what I did there?
      - simonw 6y ago
        Once again: if you are writing an article about LLVM performance, and you have the choice between the title "Make LLVM fast again" and something else, you will likely have more success with your article if you pick something else. Do you disagree with the advice I'm giving here?
        snazz 6y ago
        My mind did not immediately jump to MAGA, and I'm an American. It's not a significant issue for most people.
        simonw 6y ago
        You're the target audience for my comment then! I'm advising writers that some people reading their content may make this association, so they should avoid the phrase unless that is their deliberate intent.
        StavrosK 6y ago
        I personally don't disagree (and don't like that you're being downvoted for making a point), I just think the delta between the two is so small that it's not even worth discussing, let alone self-censoring for.
        jcims 6y ago
        You read it despite this sensitivity. What audience are you describing that won't read this based on the title? What is the net loss to the author and to them of them missing out on the content because of their decision? What is the long term implication of developing a social contract that requires you avoid any speech that is similar to any speech of political platforms that some portion, potentially a majority, of your audience opposes? It sounds like a linguistic death spiral to me. Good luck.
      - klyrs 6y ago
        > Being offended by things is dangerous to our culture. You kinda sound offended. Is there a Popperian analogue here, that we must be unoffended by everything but offense itself?
        echelon 6y ago
        I'm not offended, and I don't mind if I get pushback. This is just where I am in my current understanding of life and things. Hostility breeds hostility. Cultural segregation raises the barrier for empathy. I don't always practice what I preach, though. In a recent thread I admitted a preference for language that puts censors on edge.
        user982 6y ago
        > I love and appreciate swear words. They're incredibly important as an act of protest and defiance against the prudes and the cultural censors. > The eventual normalization of swear words will show that we have won the battle. As an exercise: Do you love and appreciate racial slurs? Is it incredibly important to use them against those who would take offense at them? Will the normalization of ethnic slurs show that you have won the battle? Why or why not?
        dependenttypes 6y ago
        Language evolves. It is time to accept that certain slurs evolved into just general-purpose insults.
    - irishcoffee 6y ago
      "If you want people to read your content, conform." The borg are looking for recruits.
    - mirekrusin 6y ago
      It's not just a title, it's what the article is about, making llvm fast again is the whole point of author's effort. He presents reason for regression in this area throughout the time (regressions on compile time are not captured vs ie. regressions on produced binary performance are). This is a problem ie. julia is heavily dependant on llvm compile times and julia authors mention that every time they're bumping llvm version they're scared about how much performance will degrade.
  - skavi 6y ago
    As it currently stands, 15 out of 24 comments in this thread are about the phrasing in the title. It has demonstrably become a distraction, at least in this post.
  - DagAgren 6y ago
    Who are you to call people thin-skinned, when you are not on the receiving end of the hatred represented by that phrase?
- RandomBacon 6y ago
  I didn't even think about the possible similarity until you pointed it out. Perhaps it's just that I'm not letting politics take over my life.
  - DagAgren 6y ago
    That's great. That means that current politics aren't focused on making your life worse, or making you feel unwelcome. That means things are pretty good for you. This is not the case for every one else. For many people, "Make America great again" is the slogan of people who hate you, who don't think you belong in your home, or who might even want you literally dead. For them, it's not great hearing that phrase used as a joke. The fact that this does not apply to you, personally, is not a reason to dismiss them.
    - RandomBacon 6y ago
      > politics aren't focused on making your life worse, or making you feel unwelcome. Oh they are, I just prefer to focus on good things rather than bad things. > things are pretty good for you. Things are pretty good for me, but it's not because of politics. I'm not refuting your generalization about the slogan and how some people perceive it. It's definitely not good that we're in a situation where this is happening. Please be very careful about assuming things about other people, else you will fall into the same trap as people of hate. I never indicated that the slogan and its background don't apply to me, and I'm not dismissing it. I don't want this to become an arguement or be dismissive of anyone's views, I just want to make sure that people don't drag politics into a place where it doesn't belong, and not to make bad assumptions which don't help at all.
      - deleted 6y ago
        [deleted]
      - DagAgren 6y ago
        > Oh they are, I just prefer to focus on good things rather than bad things. If you can afford not to focus on them, then trust me, they are absolutely not focused on doing that. Your experiences is very different from those who are actually suffering from them. > Things are pretty good for me, but it's not because of politics. Only because you class those things that go in your favour as "not politics" and only those that challenge your position as "politics".
- jpxw 6y ago
  It’s a joke. Good grief, people on this site have no sense of humour.
- pnako 6y ago
  "Our patience has its limits: improving LLVM performance"
- battery_cowboy 6y ago
  Only for folks who cannot differentiate between a specific combination of words and another similar combination. I used to be that guy, but I realized that all of my negative thoughts about my views and politics were bleeding over into areas where there was no connection. This article is clearly not associated with Trump or politics at all, and even if they use the "make x great again" phrase. The only sinewy, tenuous connection you can even make between them is 3 words, so if a person takes such a negative view of Trump (very relatable) that anything with those 3 words plus another noun offends them so much that they cannot read the article, they really need to reassess their mental stability (much like I did recently thanks to @dang taking the time to discuss some mean comments I made here when my account was being throttled for them).
  - simonw 6y ago
    Exactly. It's not associated with Trump - so why not pick a title that doesn't risk people even having to ask that question? The author of this piece is based in Berlin. I'm certain they weren't thinking about any negative potential connotations that this title could hold - they were just reusing a common phrase.
    - deleted 6y ago
      [deleted]
    - battery_cowboy 6y ago
      But why change it then? If the article has no connection, then the people complaining are the issue, they should fix themselves, it's not the author's job to cater to that.
      - junke 6y ago
        By using this title, it is the author, not readers, that brings politics into the discussion. It has a connection, right there in the title. Maybe it is just a joke, a way to boost clicks, or some kind of myopic view that says technical people are above politics, a mix of that, none of the above, I don't know. But let's not pretend it was not made on purpose. Authors constantly adapt their writing to their audience. Alternative titles that convey more information, invites no political discussion, and don't break HN guidelines: - "Speeding up LLVM by 10%" - "Reducing compilation times for LLVM 11" - "10 optimisations for LLVM" (ok this one is click-baity) Alternative titles the author would probably have self-consored to cater to audiences: - "Guess what LLVM? hash tables faster than linear lookup" (accusatory, rude) - "LLVM getting a Summer Body" (fatphobic) - "Honey I Shrunk the Compilation Time", "Oh Hi CTMark" (pop-culture is generational, and frankly those jokes are horrible)
- jsf01 6y ago
  I like it. If it’s intentional and kind of cheeky the way I interpreted it then I see no issue. It’s funnier and less bland than some strictly technical alternative. If it’s just an innocent call to action and just coincidentally happened to be a nod to the campaign slogan then that’s fine, too. There’s really nothing worth pointing out here.
- dang 6y ago
  All: come on you guys, please stop the offtopicness now.
  - _Microft 6y ago
    One has to admit that the parent commenter is correct in that the title does detract from the actual message, inviting off-topic comments. It could have been easily avoided by picking a different title. Pointing this out might save others from making the same mistake.
    - dang 6y ago
      The parent comment started the distraction it was complaining about. This is common enough on the internet that there's a name for it: concern trolling. Of course I don't mean that the GP was trolling in the classical sense of trying to ruin the thread, but we have to judge these things by effects (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20troll%20effects&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), not intent, and the effects were clear. If you care about threads not becoming distracted, the primary thing to cultivate is restraint. There's also downvoting and flagging. And anyone who notices a major distraction in a thread is very welcome to email hn@ycombinator.com so we can look into it. That doesn't have to be a political flamewar—it could be just a generic tangent sitting as the top subthread.
- archagon 6y ago
  Thanks for saying it, even if it lands you at the bottom of the thread. Agreed completely. It's not about "being offended" (whatever that even means) but about being in poor taste. Nobody would be surprised if a post titled "All Drives Matter" elicited strong negative reactions from readers, even if it was "literally about drive selection in a RAID array" or whatever. Consciously or not, this title is doing exactly the same thing. Language has context and meaning outside of its immediate definition and will affect the perception of your written word. Don't make people think of authoritarianism and kids huddled in cages if you want to share your cool technical insights with the world.
- hashmymustache 6y ago
  What a lame comment, the tyranny of moral busybodies enacting general rules on language construction.
- deleted 6y ago
  [deleted]
- totorovirus 6y ago
  Is 'Make sth great again' became a meme..
  - tom_mellior 6y ago
    Yes, and it's a pretty terrible one. It normalizes language used by a... let's say very controversial figure. Transplanting it to contexts where it might make some sense serves to validate the original use. If someone critical of the US President "ironically" uses the phrase, as in "Foo is slow, so let's make Foo fast again", they inadvertently construct or reinforce a notion of "America was not great, which is why we needed to make America great again" -- something they might not agree with. Also, it's just constantly giving more exposure to someone who already has way too much of it. They would be running a political figure's propaganda for them. Many people will want to do that, but also very many people would not want to do it and should think a bit about a slogan's context before adopting it. (I'm aware that others across the US political spectrum have used the phrase in the past. It doesn't matter, it is currently very strongly associated with one person.)
    - yreg 6y ago
      Word. I'm working at a very diverse, politically correct European company, yet the copywriters wanted to put out a job ad which said >make banking simple, intelligent, and personal again! They said it doesn't have a controversial connotation since we are not recruiting in the US. IMO it absolutely does.
      - varjag 6y ago
        They should hang out on 4chan a bit less perhaps.
    - fastball 6y ago
      I mean, America does have serious issues that make it not nearly great as it could be. Trump doesn't seem to be addressing those issues, but there is nothing wrong with the implication that America has lost some of its lustre. Just like the author of a post called "Make LLVM Fast Again" may have identified a problem without actually fixing it. The first step to improvement is identifying the problem. LLVM has problems, America has problems. Seems fine to me.
jeffbee 6y ago
Pretty cool improvements. For any large project profiling it, making it faster, and preventing or reverting regressions can be a full-time job. Perhaps LLVM project needs such a person in such a role. Still, I question the utility of timing optimized builds. Usually when I have to wait for the compiler it's an incremental fastbuild to execute unit tests. Optimized builds usually happen while I'm busy doing something else.
- tbodt 6y ago
  The problem with that is LLVM non-optimized codegen is so bad that many projects build with -O2 even in debug mode.
  - jeffbee 6y ago
    Really? It's good enough that Google used clang for fastbuild (tests) for many years before switching release builds off GCC.
aogl 6y ago
Well this is interesting. I thought I was the only one who noticed things getting slower. For a couple releases now I've been thinking I was going crazy, as if something was only ever getting slower on my own machines. Glad to realise someone else illustrating some data to prove it. Thanks, I'll definitely watch this conversation play out as others realise the obvious..
The_rationalist 6y ago
The root cause of the issue is that they should make mandatory for each pull request merged into llvm to (almost) not regress performance. The CI should have a bunch of canonical performance tests. If it was made mandatory from the start llvm could have been far faster, it is not too late but it's time to put an end to this mediocrity
- yjftsjthsd-h 6y ago
  Although tracking it would help, I see 2 issues (in opposite directions): I think there are times when slower performance is an acceptable cost. And, I think that if you allow tiny slowdowns, over time we'll get back here. There's judgment involved.
  - m463 6y ago
    You could make the argument that: - a slower build time should not be made at the expense of a more extensible compiler - one that can be modified easily to add capabilities and features to the build output - a slower build time is acceptable if the build result executes faster or more efficiently. One slower compile vs one million faster executions is keeping your eye on the prize.
    - rubber_duck 6y ago
      This all depends on build scenario/configuration. -O3 - take all the time you need, -O2 and below - please don't regress the performance of the compiler - as article states - we are happy enough with the level of output we currently get.
      - eru 6y ago
        Yes, exactly, it's a question of what you ask from the compiler. Not sure whether the -O2 and -O3 system is the exact right choice to communicate that. But any better system would also preserve the user's ability to make this trade-off. Though I don't think there's necessarily anything magic about -O2. They could conceivably also only protect -O0 and perhaps -O1. Or give finer grained control over the trade-offs.
gameswithgo 6y ago
to Nikic, thank you for this effort.
dangwu 6y ago
LLVM has devolved into complete garbage in Xcode for large Swift projects. Slowless aside, at least half the time it won't display values for variables after hitting a breakpoint, and my team has to resort to using print statements to debug issues.
- saagarjha 6y ago
  That would be the LLDB Swift integration specifically.
- jeffbee 6y ago
  Perhaps you should try using JetBrains AppCode, from the company that employs the author of this article.
- mmm_grayons 6y ago
  That's probably a swift issue rather than LLVM. LLDB works great for me on C code.
- bla3 6y ago
  Given that it works reasonably well for rust and c++, maybe that's more a problem on the Xcode or Swift side?
- MobiusHorizons 6y ago
  Are you debugging optimized builds? I have definitely had variables be unavailable at debug time, due to optimization in C in lldb. I would guess that the same could be true for swift's integration.
  - dman 6y ago
    Anecdotally gcc + gdb does release with debug info builds a lot better than clang + lldb. In general quality of debug info is one place I have had fewer issues with gcc/gdb than I have with clang/lldb.
  - loeg 6y ago
    Clang loses a lot of information for values that are still available or computable in its optimization passes. It's not purely the values being completely lost to optimization. GCC continues to emit relatively better debuginfo at similar optimization levels. Samy Al Bahra has written and talked about this a couple of times over the years.
Myrmornis 6y ago
Shameless plug: https://github.com/dandavison/chronologer https://github.com/dandavison/chronologer runs a benchmark (using hyperfine) over every commit in a repository (or specified git revision range) and produces a boxplot-time-series graph using vega-lite. It works but is rough and I haven't tried to polish it -- does another tool exist that does this?
- The_Amp_Walrus 6y ago
  This is interesting. I'm working in epidemiological modelling atm and something this would be pretty useful to run in a github action CI-style to find performance regressions over time. I did a quick Google and found this: https://github.com/marketplace/actions/continuous-benchmark https://github.com/marketplace/actions/continuous-benchmark
  - mhh__ 6y ago
    This is something that I've been meaning to work on for a while - I'm doing a hardware project ATM so it won't be for a while - but there seems to be a strong use case for a generic software-tracker app. Lots of projects have "are we fast yet" type graphs but I'm not aware of a generic tool that also allows you to set alerts for fine grained benchmarks (I made a toy that alerts you to x-sigma increases in cache misses when testing compiler backend patches for example). One of those projects that I actually want to build but slightly too dull to finish.
dgentile 6y ago
The Rust is 10% slower metric I think is unfair. If you look on godbolt, the LLVM IR that rustc emits isn't that great, so LLVM has to take some extra time to optimize that, compared to the output of clang.
- est31 6y ago
  It's not 10% slower compared to clang but slower compared to the prior version of LLVM. That comparison IS fair as LLVM specifically invites people to target it.
drivebycomment 6y ago
Good read. One thought-provoking bit for me was: > Waymarking was previously employed to avoid explicitly storing the user (or “parent”) corresponding to a use. Instead, the position of the user was encoded in the alignment bits of the use-list pointers (across multiple pointers). This was a space-time tradeoff and reportedly resulted in major memory usage reduction when it was originally introduced. Nowadays, the memory usage saving appears to be much smaller, resulting in the removal of this mechanism. (The cynic in me thinks that the impact is lower now, because everything else uses much more memory.) Any seasoned programmers would remember a few of such things - you undo a decision made years ago because the assumptions have changed. Programmers often make these kinds of trade-off choices based on the current state (typical machines the program runs, and typical inputs the program deals with, and the current version of everything else in the program). But all of those environmental factors change over time, which can make the input to the trade-off quite different. Yet, it's difficult to revisit all those decisions systematically as they require too much human analysis. If we can encode those trade-offs in the code itself in a form that's accessible to programmatic API, one can imagine implementing a machine learning system that can make those trade-off decisions automatically over time as everything else changes via traversing the search space of all those parameters. The programming language of today doesn't allow encoding such a high-level semantic unfortunately, but maybe it's possible to start small - e.g. which of the associative data structure to use can be chosen relatively easily, the initial size of datastructure can also be potentially chosen automatically based on some benchmarks or even metric from the real world metric, etc.
- adrianN 6y ago
  I don't think that exploding the state space of your program by making the history of your design decisions programmatically accessible (and changing them regularly to reflect new assumptions) would be good for the quality of the result.
  - gugagore 6y ago
    I don't think it's as simple as saying "the state space explodes, and that's bad". When you say state space, I think about what is dynamically changing. If you can select one of two design decisions e.g. at compile time then, yes, your state space is bigger, but you don't have to reason about the whole state space jointly. The decision isn't changing at run time.
nh2 6y ago
> I’m not sure whether this has been true in the past Phoronix.com has a lot of Clang benchmarks over the years. I recall seeing some benchmark that showed that as Clang approached GCC in performance of compiled output, the compile speed also went down to approach GCC levels. But I haven't managed to find that exact benchmark yet.
- baybal2 6y ago
  An expected result when they copy GCC's features, and functionality. Isn't it? Pretty much the sole point of Clang/LLVM to the corporate sponsors is to get the GCC, but without GPL
  - the_pwner224 6y ago
    I've heard this said before. Why would someone want this? AFAIK the GPL isn't really relevant unless you're modifying and redistributing GCC itself. Even if you use modified GCC internally for compiling for-profit software you just need to allow the employees who use GCC to see your modified code, which doesn't seem like a big deal since you already trust them with your application code.
    - saagarjha 6y ago
      Because Apple modifies and distributes LLVM in their proprietary developer tools.
    - redwatch 6y ago
      It is somewhat easy to work and modify llvm tools: an optimization pass for instance. Also, LLVM tools were designed to be interchangeable. One can pick specific parts of LLVM and integrate into the workflow of others.
    - redis_mlc 6y ago
      Because Apple is intensely allergic to the GPL. The reasons are: - As somebody else mentioned, Apple redistributes developer tools, clang being the poster child - Since they releases OS products, they don't want to co-mingle their software with GPL code. (So they use an older bash on Mac OS X.) - fear of an Apple developer quietly copying GPL source into a commercial product (well-founded, actually) - Apple Legal exerting an "abundance of caution" on IP - at this point, it's institutional. When I worked there, Linux and MySQL were forbidden, for example, but that has relaxed recently. Also, I think you misunderstand the GPL. If you distribute modified gcc, anybody receiving it can ask for sources. So employees plus end-users. (One of the strangest examples is that Yamaha uses real-time linux in their synths, and you can download the GPL portions. I can't imagine a musician ever wanting to do that!) Source: ex-Apple.
ndesaulniers 6y ago
We plan on starting to track compile times for Linux kernel builds with llvm. If you have ideas for low hanging fruit in LLVM, we'd love to collaborate.
xvilka 6y ago
Reimplementing LLVM in Rust could make a big difference as well.
- adrianN 6y ago
  Why do you think that? Rust and C++ are reasonably close in performance.
  - tom_mellior 6y ago
    Not the OP here, but AFAIK LLVM has been struggling with parallelizing compilation of independent functions due to some shared global context that ideally wouldn't be there. A full rewrite would allow a redesign of this part in a more concurrency-friendly way. So it's conceivable that a concurrency-oriented rewrite would bring nice speedups in wall time, not total CPU time. And Rust might give some more guarantees that there really aren't any hidden shared corners.
    - gizmondo 6y ago
      Given that parallelizing rustc is also kinda struggling, it seems unfair to think that C++ is necessarily the culprit in LLVM case.
      - est31 6y ago
        In Firefox there've been two failed attempts to make css styling parallel while using C++. Only the parallel rust rewrite, stylo, succeeded. Rust doesn't replace careful planning of parallel infrastructure or performance optimization, but it makes it possible to maintain the parallel system.
    - CyberDildonics 6y ago
      Rust isn't going to make fast, lock free, shared memory data structures magically appear.
    - ninkendo 6y ago
schlupa 6y ago
Building llvm+clang from source is also ludicrous. 70 GB of diskspace usage and takes an hour to build, ridiculous. It's the static linking which is the culprit here, hundred of MB big binaries are a catastrophe for cache and memory subsystem. The funny thing is that my project also uses modules in D. Building the D compiler takes 10 seconds including unpacking of the tarball.
- uluyol 6y ago
  Can you clarify how using dynamic linking would be better for the cache? The amount of code that's in memory/cached would be the same, no?
  - atq2119 6y ago
    LLVM is both a library and a collection of many tools building on that library. Static linking means that almost all of the library code is linked into all of those tools. That's extremely wasteful, especially for debug builds. Luckily, shared library builds of LLVM are easy. And gp might want to invest in a Threadripper. It's possible to compile all of LLVM in a few minutes nowadays :)
    - schlupa 6y ago
      I do not choose the hardware (big bureaucratic organization). I will try the LLVM_LINK_LLVM_DYLIB and LLVM_BUILD_LLVM_DYLIB options next time. By default it builds static binaries and libraries requiring gigabytes of disk space.
  - schlupa 6y ago
    A shared object, even if mapped in 300 running apps will be loaded only once in physical memory (at least for the code segment). Statically built binaries will have each another copy of the code that will be loaded every time the binary is started. So it will be loaded in memory 300 times. I just checked the size of the clang-10 binary that was built. It is fucking 1.9 GB big (gcc 9.2 on the same machine is 6.1 MB).
khan2020 6y ago
https://akcrack.com/spyhunter-5-crack-license-key/ https://akcrack.com/spyhunter-5-crack-license-key/
DerSaidin 6y ago
This work is critical to compile times improving. As the author of one of the changes which could have unknowingly causing a 1% regression, I really appreciate this work measuring and monitoring compile times. Thanks to nikic for noticing the regression and finding a solution to avoid it.
- fluffything 6y ago
  I really hope this type of infrastructure gets moved into LLVM itself, and people start adding more benchmarks for all the frontends, and somehow integrating this into the CI infrastructure, to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc. But I guess the LLVM project should probably start by making code-reviews mandatory, gating PRs on passing tests so that master doesn't get broken all the time, etc. I really hate it when I update my LLVM locally from git master, and it won't even build because somebody pushed to master without even testing that their changes compile... For Rust, I hope Cranelift really takes off someday, and we can start to completely ditch LLVM and make it opt-in, only for those cases in which you are willing to trade-off huge compile-times for that last 1% run-time reduction.
  - pietroalbini 6y ago
    > to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc. rustc's CI doesn't prevent merging PRs that impact performance: while the reviewer can request benchmarks beforehand and choose not to approve the PR if it introduces a regression, all other benchmarks are run after the commits are merged to master.
  - bluGill 6y ago
    Unfortunately sometimes losing performance is the correct tradeoff. However it needs to be carefully considered before you just make it.
    - fluffything 6y ago
      Accepting a performance loss is almost always the right trade-off. If it weren't, everybody would be writting their code in assembly at 5LOC/day.
moonchild 6y ago
> I can’t say a 10% improvement is making LLVM fast again, we would need a 10x improvement for it to deserve that label. But it’s a start… It’s a shame, one of the standout feature of llvm/clang used to be that it was faster than GCC. Today, an optimized build with gcc is faster than a debug build with clang. I don’t know if a 10x improvement is feasible, though; tcc is between 10-20x faster than gcc and clang, and part of the reason is that it does a lot less. The architecture of such a compiler may by necessity be too generic. Here’s a table listing build times for one of my projects with and without optimizations in gcc, clang, and tcc. Tcc w/optimizations shown only for completeness; the time isn’t appreciably different. 20 runs each. ┌─────────────────────────────┬──────────┬──────────┬──────────┬─────────┬────────────┬────────────┐ │ │Clang -O2 │Clang -O0 │GCC -O2 │GCC -O0 │TCC -O2 │TCC -O0 │ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Average time (s) │1.49 ±0.11│1.24 ±0.08│1.06 ±0.08│0.8 ±0.04│0.072 ±0.011│0.072 ±0.014│ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Speedup compared to clang -O2│ - │ 1.20 │ 1.40 │ 1.86 │ 20.59 │ 20.69 │ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Slowdown compared to TCC │ 20.68 │ 17.20 │ 17.72 │ 11.12 │ - │ - │ └─────────────────────────────┴──────────┴──────────┴──────────┴─────────┴────────────┴────────────┘
- judofyr 6y ago
  > Today, an optimized build with gcc is slower than a debug build with clang. Did you mean "an optimized build with gcc is faster than a debug build with clang"?
  - fluffything 6y ago
    If that's the case, an optimized build with clang is also often faster than a debug build with... clang itself. The reason is that many of the optimization passes that run first, like dead code elimination, can remove a lot of code early on, so "optimized" builds end up processing significantly less code, which is inherently faster. The OP might just not be aware of what a "debug build" is. The goal of a debug build is for the binary to execute your code as closely to how you wrote it as possible, so that you can easily debug it. Their goal isn't "fast compile-times". If you want fast compile-times, try using -O1. At that level, both clang and gcc do optimizations that are known to be cheap and remove a lot of code, which speeds up compile-times significantly. Another trick to speed-up compile-times is to use -g0, and if you do not need exceptions, use -fno-exceptions, since those make the front-end emit much less data, which results in less data having to be processed by the backends.
londons_explore 6y ago
Am I the only one who wants to see a split into a "fast compile" mode and a "spend hours making every optimization possible" mode? Most code is executed a lot more frequently than it is compiled, so if I can get a 1% speed increase with a 100x compile slowdown, I'll take it. I don't want to see good PR's that improve LLVM delayed simply because they cause a speed regression.
- worldsayshi 6y ago
  Yeah this seems like two very different use cases. Stating the obvious: when debugging I want as fast builds as possible. When shipping I want as fast software as possible.
  - bflesch 6y ago
    The only problem being if you want to debug the optimized code ;)
    - khalladay 6y ago
      This is true a lot in games - often the "debug" version of a game is literally too slow to reproduce issues, so you have to work with the optimized builds. ...even if the actual debugging would be much easier with a debug build.
      - bluGill 6y ago
        Understood. However even then I would hope that games have unit tests and other module tests that can run just a subset of code and not the entire game. When I'm writing code I want to know it builds and the basics work before I run the entire program. I work on seasonal programs. I can only do fully realistic tests in the month of April (depending on the weather it shifts a few weeks) , meaning my window to test is closed for the next 11 months. I have learned to find ways to run my code in less realistic situations.
        6y ago
RX14 6y ago
I would greatly greatly appreciate an effort to benchmark builds without optimizations too. We've seen some LLVM-related slowdowns in Crystal, and --release compile times are far less important than non-release builds to us.
nickcw 6y ago
I think this is a worthy effort :-) I find the compile times of rust to be quite a big negative point. However: > For every tested commit, the programs are compiled in three different configurations: O3, ReleaseThinLTO and ReleaseLTO-g. All of these use -O3 in three different LTO configurations (none, thin and fat), with the last one also enabling debuginfo generation. I would have thought for developer productivity tracking -O1 compile times would be better wouldn't it? I'm happy for the CI to spend ages crunching out the best possible binary, but taking time out of the edit-compile-test loop would really help developers.
- bluGill 6y ago
  Both are worth tracking. If O3 is doing useless work then I'll take the speed up. If it is twice as long for a 1% improvement I'll take it.
NCG_Mike 6y ago
A couple of things a C++ developer can do is to put template instantiation code into a .cpp file, where possible. "#pragma once" in the header files helps as does using a pre-compiled header file. Obviously, removing header files that aren't needed makes a difference too.
- brandmeyer 6y ago
  `pragma once` doesn't do anything that a well-written header guard does.
thu2111 6y ago
Hmm. This is one of the unexpected upsides to systems using JIT compilation that I guess we tend to take for granted. The very fact that a JITC runs in parallel to the app means the compiler developers care intensely about the performance of the compiler itself - any regression increases warmup time which is a closely tracked metric. As long as you can tolerate the warmup, and at least for Java it's not really a big deal for many apps these days because C1/C2 are just so fast, you get fast iteration speeds with pretty good code generation too. The remaining performance pain points in Java apps are things like the lack of explicit vectorisation, value types etc, which are all being worked on.

582 points by notriddle 6y ago

As a general rule, "Make X Y again" is worth avoiding - it has connotations that are likely to distract from the message you are trying to put across. This is a great post full of really interesting technical details. Don't be put off by the title!

aogl 6y ago
.. yet it's the exact click bait that will make many visit..
Thorentis 6y ago
It's become a well-known catch phrase now. It's only a distraction if you find yourself offended by it, which frankly with everything that's going on right now, is pretty thin-skinned.
- simonw 6y ago
  I stand by my comment. If you want people to read your content, you should avoid phrases like this. Hence why I called it "distracting" - it is.
  - echelon 6y ago
    Being offended by things is dangerous to our culture. You can stand up for the rights and freedoms of others without turning your nose. Showing that something doesn't bother you reduces the power bullies and oppressors have over you. You can even reframe it. Make America Socialist Again. See what I did there?
    - simonw 6y ago
      Once again: if you are writing an article about LLVM performance, and you have the choice between the title "Make LLVM fast again" and something else, you will likely have more success with your article if you pick something else. Do you disagree with the advice I'm giving here?
      - snazz 6y ago
        My mind did not immediately jump to MAGA, and I'm an American. It's not a significant issue for most people.
        simonw 6y ago
        You're the target audience for my comment then! I'm advising writers that some people reading their content may make this association, so they should avoid the phrase unless that is their deliberate intent.
      - StavrosK 6y ago
        I personally don't disagree (and don't like that you're being downvoted for making a point), I just think the delta between the two is so small that it's not even worth discussing, let alone self-censoring for.
      - jcims 6y ago
        You read it despite this sensitivity. What audience are you describing that won't read this based on the title? What is the net loss to the author and to them of them missing out on the content because of their decision? What is the long term implication of developing a social contract that requires you avoid any speech that is similar to any speech of political platforms that some portion, potentially a majority, of your audience opposes? It sounds like a linguistic death spiral to me. Good luck.
    - klyrs 6y ago
      > Being offended by things is dangerous to our culture. You kinda sound offended. Is there a Popperian analogue here, that we must be unoffended by everything but offense itself?
      - echelon 6y ago
        I'm not offended, and I don't mind if I get pushback. This is just where I am in my current understanding of life and things. Hostility breeds hostility. Cultural segregation raises the barrier for empathy. I don't always practice what I preach, though. In a recent thread I admitted a preference for language that puts censors on edge.
        user982 6y ago
        > I love and appreciate swear words. They're incredibly important as an act of protest and defiance against the prudes and the cultural censors. > The eventual normalization of swear words will show that we have won the battle. As an exercise: Do you love and appreciate racial slurs? Is it incredibly important to use them against those who would take offense at them? Will the normalization of ethnic slurs show that you have won the battle? Why or why not?
        dependenttypes 6y ago
        Language evolves. It is time to accept that certain slurs evolved into just general-purpose insults.
  - irishcoffee 6y ago
    "If you want people to read your content, conform." The borg are looking for recruits.
  - mirekrusin 6y ago
    It's not just a title, it's what the article is about, making llvm fast again is the whole point of author's effort. He presents reason for regression in this area throughout the time (regressions on compile time are not captured vs ie. regressions on produced binary performance are). This is a problem ie. julia is heavily dependant on llvm compile times and julia authors mention that every time they're bumping llvm version they're scared about how much performance will degrade.
- skavi 6y ago
  As it currently stands, 15 out of 24 comments in this thread are about the phrasing in the title. It has demonstrably become a distraction, at least in this post.
- DagAgren 6y ago
  Who are you to call people thin-skinned, when you are not on the receiving end of the hatred represented by that phrase?
RandomBacon 6y ago
I didn't even think about the possible similarity until you pointed it out. Perhaps it's just that I'm not letting politics take over my life.
- DagAgren 6y ago
  That's great. That means that current politics aren't focused on making your life worse, or making you feel unwelcome. That means things are pretty good for you. This is not the case for every one else. For many people, "Make America great again" is the slogan of people who hate you, who don't think you belong in your home, or who might even want you literally dead. For them, it's not great hearing that phrase used as a joke. The fact that this does not apply to you, personally, is not a reason to dismiss them.
  - RandomBacon 6y ago
    > politics aren't focused on making your life worse, or making you feel unwelcome. Oh they are, I just prefer to focus on good things rather than bad things. > things are pretty good for you. Things are pretty good for me, but it's not because of politics. I'm not refuting your generalization about the slogan and how some people perceive it. It's definitely not good that we're in a situation where this is happening. Please be very careful about assuming things about other people, else you will fall into the same trap as people of hate. I never indicated that the slogan and its background don't apply to me, and I'm not dismissing it. I don't want this to become an arguement or be dismissive of anyone's views, I just want to make sure that people don't drag politics into a place where it doesn't belong, and not to make bad assumptions which don't help at all.
    - deleted 6y ago
      [deleted]
    - DagAgren 6y ago
      > Oh they are, I just prefer to focus on good things rather than bad things. If you can afford not to focus on them, then trust me, they are absolutely not focused on doing that. Your experiences is very different from those who are actually suffering from them. > Things are pretty good for me, but it's not because of politics. Only because you class those things that go in your favour as "not politics" and only those that challenge your position as "politics".
jpxw 6y ago
It’s a joke. Good grief, people on this site have no sense of humour.
pnako 6y ago
"Our patience has its limits: improving LLVM performance"
battery_cowboy 6y ago
Only for folks who cannot differentiate between a specific combination of words and another similar combination. I used to be that guy, but I realized that all of my negative thoughts about my views and politics were bleeding over into areas where there was no connection. This article is clearly not associated with Trump or politics at all, and even if they use the "make x great again" phrase. The only sinewy, tenuous connection you can even make between them is 3 words, so if a person takes such a negative view of Trump (very relatable) that anything with those 3 words plus another noun offends them so much that they cannot read the article, they really need to reassess their mental stability (much like I did recently thanks to @dang taking the time to discuss some mean comments I made here when my account was being throttled for them).
- simonw 6y ago
  Exactly. It's not associated with Trump - so why not pick a title that doesn't risk people even having to ask that question? The author of this piece is based in Berlin. I'm certain they weren't thinking about any negative potential connotations that this title could hold - they were just reusing a common phrase.
  - deleted 6y ago
    [deleted]
  - battery_cowboy 6y ago
    But why change it then? If the article has no connection, then the people complaining are the issue, they should fix themselves, it's not the author's job to cater to that.
    - junke 6y ago
      By using this title, it is the author, not readers, that brings politics into the discussion. It has a connection, right there in the title. Maybe it is just a joke, a way to boost clicks, or some kind of myopic view that says technical people are above politics, a mix of that, none of the above, I don't know. But let's not pretend it was not made on purpose. Authors constantly adapt their writing to their audience. Alternative titles that convey more information, invites no political discussion, and don't break HN guidelines: - "Speeding up LLVM by 10%" - "Reducing compilation times for LLVM 11" - "10 optimisations for LLVM" (ok this one is click-baity) Alternative titles the author would probably have self-consored to cater to audiences: - "Guess what LLVM? hash tables faster than linear lookup" (accusatory, rude) - "LLVM getting a Summer Body" (fatphobic) - "Honey I Shrunk the Compilation Time", "Oh Hi CTMark" (pop-culture is generational, and frankly those jokes are horrible)
jsf01 6y ago
I like it. If it’s intentional and kind of cheeky the way I interpreted it then I see no issue. It’s funnier and less bland than some strictly technical alternative. If it’s just an innocent call to action and just coincidentally happened to be a nod to the campaign slogan then that’s fine, too. There’s really nothing worth pointing out here.
dang 6y ago
All: come on you guys, please stop the offtopicness now.
- _Microft 6y ago
  One has to admit that the parent commenter is correct in that the title does detract from the actual message, inviting off-topic comments. It could have been easily avoided by picking a different title. Pointing this out might save others from making the same mistake.
  - dang 6y ago
    The parent comment started the distraction it was complaining about. This is common enough on the internet that there's a name for it: concern trolling. Of course I don't mean that the GP was trolling in the classical sense of trying to ruin the thread, but we have to judge these things by effects (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20troll%20effects&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), not intent, and the effects were clear. If you care about threads not becoming distracted, the primary thing to cultivate is restraint. There's also downvoting and flagging. And anyone who notices a major distraction in a thread is very welcome to email hn@ycombinator.com so we can look into it. That doesn't have to be a political flamewar—it could be just a generic tangent sitting as the top subthread.
archagon 6y ago
Thanks for saying it, even if it lands you at the bottom of the thread. Agreed completely. It's not about "being offended" (whatever that even means) but about being in poor taste. Nobody would be surprised if a post titled "All Drives Matter" elicited strong negative reactions from readers, even if it was "literally about drive selection in a RAID array" or whatever. Consciously or not, this title is doing exactly the same thing. Language has context and meaning outside of its immediate definition and will affect the perception of your written word. Don't make people think of authoritarianism and kids huddled in cages if you want to share your cool technical insights with the world.
hashmymustache 6y ago
What a lame comment, the tyranny of moral busybodies enacting general rules on language construction.
deleted 6y ago
[deleted]
totorovirus 6y ago
Is 'Make sth great again' became a meme..
- tom_mellior 6y ago
  Yes, and it's a pretty terrible one. It normalizes language used by a... let's say very controversial figure. Transplanting it to contexts where it might make some sense serves to validate the original use. If someone critical of the US President "ironically" uses the phrase, as in "Foo is slow, so let's make Foo fast again", they inadvertently construct or reinforce a notion of "America was not great, which is why we needed to make America great again" -- something they might not agree with. Also, it's just constantly giving more exposure to someone who already has way too much of it. They would be running a political figure's propaganda for them. Many people will want to do that, but also very many people would not want to do it and should think a bit about a slogan's context before adopting it. (I'm aware that others across the US political spectrum have used the phrase in the past. It doesn't matter, it is currently very strongly associated with one person.)
  - yreg 6y ago
    Word. I'm working at a very diverse, politically correct European company, yet the copywriters wanted to put out a job ad which said >make banking simple, intelligent, and personal again! They said it doesn't have a controversial connotation since we are not recruiting in the US. IMO it absolutely does.
    - varjag 6y ago
      They should hang out on 4chan a bit less perhaps.
  - fastball 6y ago
    I mean, America does have serious issues that make it not nearly great as it could be. Trump doesn't seem to be addressing those issues, but there is nothing wrong with the implication that America has lost some of its lustre. Just like the author of a post called "Make LLVM Fast Again" may have identified a problem without actually fixing it. The first step to improvement is identifying the problem. LLVM has problems, America has problems. Seems fine to me.

jeffbee 6y ago

Pretty cool improvements. For any large project profiling it, making it faster, and preventing or reverting regressions can be a full-time job. Perhaps LLVM project needs such a person in such a role. Still, I question the utility of timing optimized builds. Usually when I have to wait for the compiler it's an incremental fastbuild to execute unit tests. Optimized builds usually happen while I'm busy doing something else.

tbodt 6y ago
The problem with that is LLVM non-optimized codegen is so bad that many projects build with -O2 even in debug mode.
- jeffbee 6y ago
  Really? It's good enough that Google used clang for fastbuild (tests) for many years before switching release builds off GCC.

aogl 6y ago

Well this is interesting. I thought I was the only one who noticed things getting slower. For a couple releases now I've been thinking I was going crazy, as if something was only ever getting slower on my own machines. Glad to realise someone else illustrating some data to prove it. Thanks, I'll definitely watch this conversation play out as others realise the obvious..

The_rationalist 6y ago

The root cause of the issue is that they should make mandatory for each pull request merged into llvm to (almost) not regress performance. The CI should have a bunch of canonical performance tests. If it was made mandatory from the start llvm could have been far faster, it is not too late but it's time to put an end to this mediocrity

yjftsjthsd-h 6y ago
Although tracking it would help, I see 2 issues (in opposite directions): I think there are times when slower performance is an acceptable cost. And, I think that if you allow tiny slowdowns, over time we'll get back here. There's judgment involved.
- m463 6y ago
  You could make the argument that: - a slower build time should not be made at the expense of a more extensible compiler - one that can be modified easily to add capabilities and features to the build output - a slower build time is acceptable if the build result executes faster or more efficiently. One slower compile vs one million faster executions is keeping your eye on the prize.
  - rubber_duck 6y ago
    This all depends on build scenario/configuration. -O3 - take all the time you need, -O2 and below - please don't regress the performance of the compiler - as article states - we are happy enough with the level of output we currently get.
    - eru 6y ago
      Yes, exactly, it's a question of what you ask from the compiler. Not sure whether the -O2 and -O3 system is the exact right choice to communicate that. But any better system would also preserve the user's ability to make this trade-off. Though I don't think there's necessarily anything magic about -O2. They could conceivably also only protect -O0 and perhaps -O1. Or give finer grained control over the trade-offs.

gameswithgo 6y ago

to Nikic, thank you for this effort.

dangwu 6y ago

LLVM has devolved into complete garbage in Xcode for large Swift projects. Slowless aside, at least half the time it won't display values for variables after hitting a breakpoint, and my team has to resort to using print statements to debug issues.

saagarjha 6y ago
That would be the LLDB Swift integration specifically.
jeffbee 6y ago
Perhaps you should try using JetBrains AppCode, from the company that employs the author of this article.
mmm_grayons 6y ago
That's probably a swift issue rather than LLVM. LLDB works great for me on C code.
bla3 6y ago
Given that it works reasonably well for rust and c++, maybe that's more a problem on the Xcode or Swift side?
MobiusHorizons 6y ago
Are you debugging optimized builds? I have definitely had variables be unavailable at debug time, due to optimization in C in lldb. I would guess that the same could be true for swift's integration.
- dman 6y ago
  Anecdotally gcc + gdb does release with debug info builds a lot better than clang + lldb. In general quality of debug info is one place I have had fewer issues with gcc/gdb than I have with clang/lldb.
- loeg 6y ago
  Clang loses a lot of information for values that are still available or computable in its optimization passes. It's not purely the values being completely lost to optimization. GCC continues to emit relatively better debuginfo at similar optimization levels. Samy Al Bahra has written and talked about this a couple of times over the years.

Myrmornis 6y ago

Shameless plug: https://github.com/dandavison/chronologer https://github.com/dandavison/chronologer runs a benchmark (using hyperfine) over every commit in a repository (or specified git revision range) and produces a boxplot-time-series graph using vega-lite. It works but is rough and I haven't tried to polish it -- does another tool exist that does this?

The_Amp_Walrus 6y ago
This is interesting. I'm working in epidemiological modelling atm and something this would be pretty useful to run in a github action CI-style to find performance regressions over time. I did a quick Google and found this: https://github.com/marketplace/actions/continuous-benchmark https://github.com/marketplace/actions/continuous-benchmark
- mhh__ 6y ago
  This is something that I've been meaning to work on for a while - I'm doing a hardware project ATM so it won't be for a while - but there seems to be a strong use case for a generic software-tracker app. Lots of projects have "are we fast yet" type graphs but I'm not aware of a generic tool that also allows you to set alerts for fine grained benchmarks (I made a toy that alerts you to x-sigma increases in cache misses when testing compiler backend patches for example). One of those projects that I actually want to build but slightly too dull to finish.

dgentile 6y ago

The Rust is 10% slower metric I think is unfair. If you look on godbolt, the LLVM IR that rustc emits isn't that great, so LLVM has to take some extra time to optimize that, compared to the output of clang.

est31 6y ago
It's not 10% slower compared to clang but slower compared to the prior version of LLVM. That comparison IS fair as LLVM specifically invites people to target it.

drivebycomment 6y ago

Good read. One thought-provoking bit for me was: > Waymarking was previously employed to avoid explicitly storing the user (or “parent”) corresponding to a use. Instead, the position of the user was encoded in the alignment bits of the use-list pointers (across multiple pointers). This was a space-time tradeoff and reportedly resulted in major memory usage reduction when it was originally introduced. Nowadays, the memory usage saving appears to be much smaller, resulting in the removal of this mechanism. (The cynic in me thinks that the impact is lower now, because everything else uses much more memory.) Any seasoned programmers would remember a few of such things - you undo a decision made years ago because the assumptions have changed. Programmers often make these kinds of trade-off choices based on the current state (typical machines the program runs, and typical inputs the program deals with, and the current version of everything else in the program). But all of those environmental factors change over time, which can make the input to the trade-off quite different. Yet, it's difficult to revisit all those decisions systematically as they require too much human analysis. If we can encode those trade-offs in the code itself in a form that's accessible to programmatic API, one can imagine implementing a machine learning system that can make those trade-off decisions automatically over time as everything else changes via traversing the search space of all those parameters. The programming language of today doesn't allow encoding such a high-level semantic unfortunately, but maybe it's possible to start small - e.g. which of the associative data structure to use can be chosen relatively easily, the initial size of datastructure can also be potentially chosen automatically based on some benchmarks or even metric from the real world metric, etc.

adrianN 6y ago
I don't think that exploding the state space of your program by making the history of your design decisions programmatically accessible (and changing them regularly to reflect new assumptions) would be good for the quality of the result.
- gugagore 6y ago
  I don't think it's as simple as saying "the state space explodes, and that's bad". When you say state space, I think about what is dynamically changing. If you can select one of two design decisions e.g. at compile time then, yes, your state space is bigger, but you don't have to reason about the whole state space jointly. The decision isn't changing at run time.

nh2 6y ago

> I’m not sure whether this has been true in the past Phoronix.com has a lot of Clang benchmarks over the years. I recall seeing some benchmark that showed that as Clang approached GCC in performance of compiled output, the compile speed also went down to approach GCC levels. But I haven't managed to find that exact benchmark yet.

baybal2 6y ago
An expected result when they copy GCC's features, and functionality. Isn't it? Pretty much the sole point of Clang/LLVM to the corporate sponsors is to get the GCC, but without GPL
- the_pwner224 6y ago
  I've heard this said before. Why would someone want this? AFAIK the GPL isn't really relevant unless you're modifying and redistributing GCC itself. Even if you use modified GCC internally for compiling for-profit software you just need to allow the employees who use GCC to see your modified code, which doesn't seem like a big deal since you already trust them with your application code.
  - saagarjha 6y ago
    Because Apple modifies and distributes LLVM in their proprietary developer tools.
  - redwatch 6y ago
    It is somewhat easy to work and modify llvm tools: an optimization pass for instance. Also, LLVM tools were designed to be interchangeable. One can pick specific parts of LLVM and integrate into the workflow of others.
  - redis_mlc 6y ago
    Because Apple is intensely allergic to the GPL. The reasons are: - As somebody else mentioned, Apple redistributes developer tools, clang being the poster child - Since they releases OS products, they don't want to co-mingle their software with GPL code. (So they use an older bash on Mac OS X.) - fear of an Apple developer quietly copying GPL source into a commercial product (well-founded, actually) - Apple Legal exerting an "abundance of caution" on IP - at this point, it's institutional. When I worked there, Linux and MySQL were forbidden, for example, but that has relaxed recently. Also, I think you misunderstand the GPL. If you distribute modified gcc, anybody receiving it can ask for sources. So employees plus end-users. (One of the strangest examples is that Yamaha uses real-time linux in their synths, and you can download the GPL portions. I can't imagine a musician ever wanting to do that!) Source: ex-Apple.

ndesaulniers 6y ago

We plan on starting to track compile times for Linux kernel builds with llvm. If you have ideas for low hanging fruit in LLVM, we'd love to collaborate.

xvilka 6y ago

Reimplementing LLVM in Rust could make a big difference as well.

adrianN 6y ago
Why do you think that? Rust and C++ are reasonably close in performance.
- tom_mellior 6y ago
  Not the OP here, but AFAIK LLVM has been struggling with parallelizing compilation of independent functions due to some shared global context that ideally wouldn't be there. A full rewrite would allow a redesign of this part in a more concurrency-friendly way. So it's conceivable that a concurrency-oriented rewrite would bring nice speedups in wall time, not total CPU time. And Rust might give some more guarantees that there really aren't any hidden shared corners.
  - gizmondo 6y ago
    Given that parallelizing rustc is also kinda struggling, it seems unfair to think that C++ is necessarily the culprit in LLVM case.
    - est31 6y ago
      In Firefox there've been two failed attempts to make css styling parallel while using C++. Only the parallel rust rewrite, stylo, succeeded. Rust doesn't replace careful planning of parallel infrastructure or performance optimization, but it makes it possible to maintain the parallel system.
  - CyberDildonics 6y ago
    Rust isn't going to make fast, lock free, shared memory data structures magically appear.
  - ninkendo 6y ago

schlupa 6y ago

Building llvm+clang from source is also ludicrous. 70 GB of diskspace usage and takes an hour to build, ridiculous. It's the static linking which is the culprit here, hundred of MB big binaries are a catastrophe for cache and memory subsystem. The funny thing is that my project also uses modules in D. Building the D compiler takes 10 seconds including unpacking of the tarball.

uluyol 6y ago
Can you clarify how using dynamic linking would be better for the cache? The amount of code that's in memory/cached would be the same, no?
- atq2119 6y ago
  LLVM is both a library and a collection of many tools building on that library. Static linking means that almost all of the library code is linked into all of those tools. That's extremely wasteful, especially for debug builds. Luckily, shared library builds of LLVM are easy. And gp might want to invest in a Threadripper. It's possible to compile all of LLVM in a few minutes nowadays :)
  - schlupa 6y ago
    I do not choose the hardware (big bureaucratic organization). I will try the LLVM_LINK_LLVM_DYLIB and LLVM_BUILD_LLVM_DYLIB options next time. By default it builds static binaries and libraries requiring gigabytes of disk space.
- schlupa 6y ago
  A shared object, even if mapped in 300 running apps will be loaded only once in physical memory (at least for the code segment). Statically built binaries will have each another copy of the code that will be loaded every time the binary is started. So it will be loaded in memory 300 times. I just checked the size of the clang-10 binary that was built. It is fucking 1.9 GB big (gcc 9.2 on the same machine is 6.1 MB).

khan2020 6y ago

https://akcrack.com/spyhunter-5-crack-license-key/ https://akcrack.com/spyhunter-5-crack-license-key/

DerSaidin 6y ago

This work is critical to compile times improving. As the author of one of the changes which could have unknowingly causing a 1% regression, I really appreciate this work measuring and monitoring compile times. Thanks to nikic for noticing the regression and finding a solution to avoid it.

fluffything 6y ago
I really hope this type of infrastructure gets moved into LLVM itself, and people start adding more benchmarks for all the frontends, and somehow integrating this into the CI infrastructure, to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc. But I guess the LLVM project should probably start by making code-reviews mandatory, gating PRs on passing tests so that master doesn't get broken all the time, etc. I really hate it when I update my LLVM locally from git master, and it won't even build because somebody pushed to master without even testing that their changes compile... For Rust, I hope Cranelift really takes off someday, and we can start to completely ditch LLVM and make it opt-in, only for those cases in which you are willing to trade-off huge compile-times for that last 1% run-time reduction.
- pietroalbini 6y ago
  > to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc. rustc's CI doesn't prevent merging PRs that impact performance: while the reviewer can request benchmarks beforehand and choose not to approve the PR if it introduces a regression, all other benchmarks are run after the commits are merged to master.
- bluGill 6y ago
  Unfortunately sometimes losing performance is the correct tradeoff. However it needs to be carefully considered before you just make it.
  - fluffything 6y ago
    Accepting a performance loss is almost always the right trade-off. If it weren't, everybody would be writting their code in assembly at 5LOC/day.

moonchild 6y ago

> I can’t say a 10% improvement is making LLVM fast again, we would need a 10x improvement for it to deserve that label. But it’s a start… It’s a shame, one of the standout feature of llvm/clang used to be that it was faster than GCC. Today, an optimized build with gcc is faster than a debug build with clang. I don’t know if a 10x improvement is feasible, though; tcc is between 10-20x faster than gcc and clang, and part of the reason is that it does a lot less. The architecture of such a compiler may by necessity be too generic. Here’s a table listing build times for one of my projects with and without optimizations in gcc, clang, and tcc. Tcc w/optimizations shown only for completeness; the time isn’t appreciably different. 20 runs each. ┌─────────────────────────────┬──────────┬──────────┬──────────┬─────────┬────────────┬────────────┐ │ │Clang -O2 │Clang -O0 │GCC -O2 │GCC -O0 │TCC -O2 │TCC -O0 │ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Average time (s) │1.49 ±0.11│1.24 ±0.08│1.06 ±0.08│0.8 ±0.04│0.072 ±0.011│0.072 ±0.014│ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Speedup compared to clang -O2│ - │ 1.20 │ 1.40 │ 1.86 │ 20.59 │ 20.69 │ ├─────────────────────────────┼──────────┼──────────┼──────────┼─────────┼────────────┼────────────┤ │Slowdown compared to TCC │ 20.68 │ 17.20 │ 17.72 │ 11.12 │ - │ - │ └─────────────────────────────┴──────────┴──────────┴──────────┴─────────┴────────────┴────────────┘

judofyr 6y ago
> Today, an optimized build with gcc is slower than a debug build with clang. Did you mean "an optimized build with gcc is faster than a debug build with clang"?
- fluffything 6y ago
  If that's the case, an optimized build with clang is also often faster than a debug build with... clang itself. The reason is that many of the optimization passes that run first, like dead code elimination, can remove a lot of code early on, so "optimized" builds end up processing significantly less code, which is inherently faster. The OP might just not be aware of what a "debug build" is. The goal of a debug build is for the binary to execute your code as closely to how you wrote it as possible, so that you can easily debug it. Their goal isn't "fast compile-times". If you want fast compile-times, try using -O1. At that level, both clang and gcc do optimizations that are known to be cheap and remove a lot of code, which speeds up compile-times significantly. Another trick to speed-up compile-times is to use -g0, and if you do not need exceptions, use -fno-exceptions, since those make the front-end emit much less data, which results in less data having to be processed by the backends.

londons_explore 6y ago

Am I the only one who wants to see a split into a "fast compile" mode and a "spend hours making every optimization possible" mode? Most code is executed a lot more frequently than it is compiled, so if I can get a 1% speed increase with a 100x compile slowdown, I'll take it. I don't want to see good PR's that improve LLVM delayed simply because they cause a speed regression.

worldsayshi 6y ago
Yeah this seems like two very different use cases. Stating the obvious: when debugging I want as fast builds as possible. When shipping I want as fast software as possible.
- bflesch 6y ago
  The only problem being if you want to debug the optimized code ;)
  - khalladay 6y ago
    This is true a lot in games - often the "debug" version of a game is literally too slow to reproduce issues, so you have to work with the optimized builds. ...even if the actual debugging would be much easier with a debug build.
    - bluGill 6y ago
      Understood. However even then I would hope that games have unit tests and other module tests that can run just a subset of code and not the entire game. When I'm writing code I want to know it builds and the basics work before I run the entire program. I work on seasonal programs. I can only do fully realistic tests in the month of April (depending on the weather it shifts a few weeks) , meaning my window to test is closed for the next 11 months. I have learned to find ways to run my code in less realistic situations.
      - 6y ago

RX14 6y ago

I would greatly greatly appreciate an effort to benchmark builds without optimizations too. We've seen some LLVM-related slowdowns in Crystal, and --release compile times are far less important than non-release builds to us.

nickcw 6y ago

I think this is a worthy effort :-) I find the compile times of rust to be quite a big negative point. However: > For every tested commit, the programs are compiled in three different configurations: O3, ReleaseThinLTO and ReleaseLTO-g. All of these use -O3 in three different LTO configurations (none, thin and fat), with the last one also enabling debuginfo generation. I would have thought for developer productivity tracking -O1 compile times would be better wouldn't it? I'm happy for the CI to spend ages crunching out the best possible binary, but taking time out of the edit-compile-test loop would really help developers.

bluGill 6y ago
Both are worth tracking. If O3 is doing useless work then I'll take the speed up. If it is twice as long for a 1% improvement I'll take it.

NCG_Mike 6y ago

A couple of things a C++ developer can do is to put template instantiation code into a .cpp file, where possible. "#pragma once" in the header files helps as does using a pre-compiled header file. Obviously, removing header files that aren't needed makes a difference too.

brandmeyer 6y ago
`pragma once` doesn't do anything that a well-written header guard does.

thu2111 6y ago

Hmm. This is one of the unexpected upsides to systems using JIT compilation that I guess we tend to take for granted. The very fact that a JITC runs in parallel to the app means the compiler developers care intensely about the performance of the compiler itself - any regression increases warmup time which is a closely tracked metric. As long as you can tolerate the warmup, and at least for Java it's not really a big deal for many apps these days because C1/C2 are just so fast, you get fast iteration speeds with pretty good code generation too. The remaining performance pain points in Java apps are things like the lack of explicit vectorisation, value types etc, which are all being worked on.