5 ms·

It's not a big deal. People give up more than 1% in suboptimal compiler flags alone. People give up far more than that by using unoptimized or lightly optimized

It's not a big deal. People give up more than 1% in suboptimal compiler flags alone. People give up far more than that by using unoptimized or lightly optimized code. People give up more than that by being too lazy to use profile guided optimization. Or by using the system malloc. To say that a 1% loss in performance disqualifies something as a systems language is absurd.

mumblemumble 4y ago
One important difference in all of those is that they are decisions made by the user of the programming language, not the author. Sub-optimal performance decisions made by the user are their own business (and, perhaps, their customers'), and not really the language authors' concern. The converse is not true. Sub-optimal performance decisions made by the language authors end up affecting everybody. I agree that saying a 1% difference would disqualify it as a systems language is hyperbolic. I disagree with the assertion that it's not a big deal. Having a core development team that considers 1% to be a big deal is a very desirable trait in a systems language. Achieving very high performance goals often comes through an accretion of many such 1% (and sub-1%) decisions.
- eloff 4y ago
  The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language based on a 1% performance difference. It's so far down the list of considerations that it's a total non-issue.
  - WalterBright 4y ago
    Would Linus accept a language for core Linux work that came with a 1% penalty?
    - diffxx 4y ago
      This question is impossible to answer in a vacuum. What if the language made developers 90% more productive or 90% less likely to introduce a memory bug or offered 3x faster compiler times? A 1% runtime performance hit would be well worth it if that were the case. Perhaps with the extra time available, developers could find better algorithms/ways of expressing their programs that would ultimately lead to faster runtime performance on average even with the 1% hit in certain microbenchmarks.
    - darksaints 4y ago
      He certainly hasn't accepted D as a language for core Linux work, despite the benefits without any supposed performance tradeoffs. And he uses GCC for compilation, despite the existence of specialized compilers that offer better runtime performance.
      - WalterBright 4y ago
        Would Linus accept a C compiler that replaced malloc/free with a GC? It's only 1%.
        darksaints 4y ago
        No, but not because of performance. Malloc/free is required for deterministic runtime behavior. A GC would take that away. Would Linus accept a language that is more than 1% slower than optimal? Yes, he already does. It's called C. C is slower than optimal assembly. He chose C because it is easier to write large systems in a higher level language, and it is far easier to write cross platform code in.
        pjmlp 4y ago
        That is a common mistake, malloc()/free() aren't deterministic, specially in threaded code, heaviliy loaded system, ISO C doesn't even provide guarantees of how deterministic they should come back to the caller across C implementations.
        cozzyd 4y ago
        Sure but you control when you call them.
        WalterBright 4y ago
        In D you also control when to call the GC.
        pjmlp 4y ago
    - arcticbull 4y ago
      I think the larger issue for Linux would be lack of determinism and memory bloat due to the presence of a collector.
    - eloff 4y ago
      He just did, it's called Rust. And if someone invented a language 5% faster than C. He'd still use C. If someone had invented a language faster than C when he started working on Linux, he would still have chosen C. He didn't pick it because it was the fastest (and it likely wasn't back then - C compilers have come a long way.)
      - int_19h 4y ago
        The whole point of Rust is to not require runtime checks by pushing safety to the type system; why would it be slower than C?
        slashdev 4y ago
        Because practice is not the same as theory. It's both faster and slower than C, depending on the program, but overall slower. The answer to why is deeply complex and varies on a case-by-case basis. Rust is far more complex than C, so some language features compile down to a LOT more IR (intermediate representation) than C, and LLVM is left to try and make the best of it. Many problems in compilers are NP-complete, and the compiler will use heuristics and other techniques to get an approximately good enough answer. Like register allocation. The more complex the starting state, the less well that tends to work out. But there's other things too, Rust has bounds checks for example, while C often does not. C has null-terminated strings, while Rust strings store a length. Rust doesn't have aliasing, but doesn't yet (last I checked anyway) optimize for that. It will one day though. This is just touching on an extremely nuanced and complex subject. But C is typically faster than Rust, and will likely stay that way.
- LeFantome 4y ago
  I agree that it is not the 1% that matters but rather the 10% hit that comes from multiple failures to see a 1% hit as material.
  - eloff 4y ago
    I would argue that 10% still doesn't matter as much as other things. But it's starting to matter.
- deleted 4y ago
  [deleted]
KerrAvon 4y ago
At system scale, a 1% loss is a huge deal. Perf teams on operating systems do things for systemwide performance with small percentage wins all the time. Whether this is the right trade off for D, whether it’s feasible to flip a global switch for “slower code but optimal GC” or whether it’s an intractable problem I can’t say, but Walter is correct on this point.
- dwaite 4y ago
  It is contextual. The things like system IPC where 1% would be huge are also typically not written in C, but in a mix of C and assembly. But writing at that level of specificity for an entire system greatly increases creation and maintenance time costs. You may lose the opportunity to make future performance improvements as a result.
- diffxx 4y ago
  > Perf teams on operating systems do things for systemwide performance with small percentage wins all the time. And they evidently spend very little time on the things that would actually improve the lives of their users in macroscopic ways. The fact that our dominant model of an operating system is essentially c + shell is a tragedy. The operating system does almost nothing for us to help write fast, correct programs in a reasonable amount of time. It is of course for this reason that unix itself has barely improved in a material way in 30 years except in these kinds of microbenchmarks. Third party tooling and languages have of course improved, but largely to cover the gaps that the operating system has largely failed to address in a meaningful way.
  - WalterBright 4y ago
    > The operating system does almost nothing for us to help write fast, correct programs in a reasonable amount of time. Um, when the PC computers switched from real mode to protected mode operating systems, that was an enormous boost to programming. It's hard to understate it.
WalterBright 4y ago
How much would Boeing pay to reduce the weight of an airplane by 1%? How much would Ferrari pay to make their F1 cars 1% faster? How much would car companies pay to be able to make 1% more fuel efficient cars? How much would your electric bill save if rates were reduced 1%? 1% is a lot of leverage. One reason I got paid well when I worked in industry is because I could write code that ran faster. Shaving 1% off execution speed is a big deal.
- morelisp 4y ago
  > How much would Boeing pay to reduce the weight of an airplane by 1%? I don't know but this seems like a trivial decision given how many metrics they must track about the relationship between weight and capacity/fuel cost - either you pay less than you save, or you don't pay it. > How much would Ferrari pay to make their F1 cars 1% faster? Probably a lot, but this is a (somewhat literal) Red Queen's race. > How much would car companies pay to be able to make 1% more fuel efficient cars? Probably nothing, their precision is already several times that. Empirically, they also don't care much. > How much would your electric bill save if rates were reduced 1%? Less than 5 euros a year - though this year maybe more, could be as high as 10. So, negligible - not even worth the time to write this comment, probably. Overall it seems like "1%" is often a fairly meaningless measure and I'm not sure what any of these examples are supposed to illustrate to me about compiler design or language choice since the context for each seems to matter more than anything else.
  - Kukumber 4y ago
    > Less than 5 euros a year - though this year maybe more, could be as high as 10. So, negligible - not even worth the time to write this comment, probably. Then apply this 1% saved logic to everything else, food, clothing, leisure, insurance, medical bills, sport 1% is a lot, cumulatively
    - morelisp 4y ago
      Electricity is not 100% of the cost of "everything else". Nor are those part of my electricity bill. If you want to make a point about where 1% efficiency matters, go ahead and make it! I might even agree! But it still won't have anything to do with systems programming languages.
glouwbug 4y ago
Breh, the guy you’re responding to wrote D. Unless you’ve written something similar your argument is moot
- morelisp 4y ago
  This kind of sycophancy is disgusting.
  - glouwbug 4y ago
    How? OP made a claim but OP hasn’t written a systems programming language as prevalent as D. It’s a baseless claim that’s either the result of inexperience or attempted flame bait. Walter is the only compiler expert on HN and our arguments should at least be thoughtful
    - morelisp 4y ago
      > Walter is the only compiler expert on HN What the fuck?

mumblemumble 4y ago

One important difference in all of those is that they are decisions made by the user of the programming language, not the author. Sub-optimal performance decisions made by the user are their own business (and, perhaps, their customers'), and not really the language authors' concern. The converse is not true. Sub-optimal performance decisions made by the language authors end up affecting everybody. I agree that saying a 1% difference would disqualify it as a systems language is hyperbolic. I disagree with the assertion that it's not a big deal. Having a core development team that considers 1% to be a big deal is a very desirable trait in a systems language. Achieving very high performance goals often comes through an accretion of many such 1% (and sub-1%) decisions.

eloff 4y ago
The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language based on a 1% performance difference. It's so far down the list of considerations that it's a total non-issue.
- WalterBright 4y ago
  Would Linus accept a language for core Linux work that came with a 1% penalty?
  - diffxx 4y ago
    This question is impossible to answer in a vacuum. What if the language made developers 90% more productive or 90% less likely to introduce a memory bug or offered 3x faster compiler times? A 1% runtime performance hit would be well worth it if that were the case. Perhaps with the extra time available, developers could find better algorithms/ways of expressing their programs that would ultimately lead to faster runtime performance on average even with the 1% hit in certain microbenchmarks.
  - darksaints 4y ago
    He certainly hasn't accepted D as a language for core Linux work, despite the benefits without any supposed performance tradeoffs. And he uses GCC for compilation, despite the existence of specialized compilers that offer better runtime performance.
    - WalterBright 4y ago
      Would Linus accept a C compiler that replaced malloc/free with a GC? It's only 1%.
      - darksaints 4y ago
        No, but not because of performance. Malloc/free is required for deterministic runtime behavior. A GC would take that away. Would Linus accept a language that is more than 1% slower than optimal? Yes, he already does. It's called C. C is slower than optimal assembly. He chose C because it is easier to write large systems in a higher level language, and it is far easier to write cross platform code in.
        pjmlp 4y ago
        That is a common mistake, malloc()/free() aren't deterministic, specially in threaded code, heaviliy loaded system, ISO C doesn't even provide guarantees of how deterministic they should come back to the caller across C implementations.
        cozzyd 4y ago
        Sure but you control when you call them.
        WalterBright 4y ago
        In D you also control when to call the GC.
        pjmlp 4y ago
  - arcticbull 4y ago
    I think the larger issue for Linux would be lack of determinism and memory bloat due to the presence of a collector.
  - eloff 4y ago
    He just did, it's called Rust. And if someone invented a language 5% faster than C. He'd still use C. If someone had invented a language faster than C when he started working on Linux, he would still have chosen C. He didn't pick it because it was the fastest (and it likely wasn't back then - C compilers have come a long way.)
    - int_19h 4y ago
      The whole point of Rust is to not require runtime checks by pushing safety to the type system; why would it be slower than C?
      - slashdev 4y ago
        Because practice is not the same as theory. It's both faster and slower than C, depending on the program, but overall slower. The answer to why is deeply complex and varies on a case-by-case basis. Rust is far more complex than C, so some language features compile down to a LOT more IR (intermediate representation) than C, and LLVM is left to try and make the best of it. Many problems in compilers are NP-complete, and the compiler will use heuristics and other techniques to get an approximately good enough answer. Like register allocation. The more complex the starting state, the less well that tends to work out. But there's other things too, Rust has bounds checks for example, while C often does not. C has null-terminated strings, while Rust strings store a length. Rust doesn't have aliasing, but doesn't yet (last I checked anyway) optimize for that. It will one day though. This is just touching on an extremely nuanced and complex subject. But C is typically faster than Rust, and will likely stay that way.
LeFantome 4y ago
I agree that it is not the 1% that matters but rather the 10% hit that comes from multiple failures to see a 1% hit as material.
- eloff 4y ago
  I would argue that 10% still doesn't matter as much as other things. But it's starting to matter.
deleted 4y ago
[deleted]

KerrAvon 4y ago

At system scale, a 1% loss is a huge deal. Perf teams on operating systems do things for systemwide performance with small percentage wins all the time. Whether this is the right trade off for D, whether it’s feasible to flip a global switch for “slower code but optimal GC” or whether it’s an intractable problem I can’t say, but Walter is correct on this point.

dwaite 4y ago
It is contextual. The things like system IPC where 1% would be huge are also typically not written in C, but in a mix of C and assembly. But writing at that level of specificity for an entire system greatly increases creation and maintenance time costs. You may lose the opportunity to make future performance improvements as a result.
diffxx 4y ago
> Perf teams on operating systems do things for systemwide performance with small percentage wins all the time. And they evidently spend very little time on the things that would actually improve the lives of their users in macroscopic ways. The fact that our dominant model of an operating system is essentially c + shell is a tragedy. The operating system does almost nothing for us to help write fast, correct programs in a reasonable amount of time. It is of course for this reason that unix itself has barely improved in a material way in 30 years except in these kinds of microbenchmarks. Third party tooling and languages have of course improved, but largely to cover the gaps that the operating system has largely failed to address in a meaningful way.
- WalterBright 4y ago
  > The operating system does almost nothing for us to help write fast, correct programs in a reasonable amount of time. Um, when the PC computers switched from real mode to protected mode operating systems, that was an enormous boost to programming. It's hard to understate it.

WalterBright 4y ago

How much would Boeing pay to reduce the weight of an airplane by 1%? How much would Ferrari pay to make their F1 cars 1% faster? How much would car companies pay to be able to make 1% more fuel efficient cars? How much would your electric bill save if rates were reduced 1%? 1% is a lot of leverage. One reason I got paid well when I worked in industry is because I could write code that ran faster. Shaving 1% off execution speed is a big deal.

morelisp 4y ago
> How much would Boeing pay to reduce the weight of an airplane by 1%? I don't know but this seems like a trivial decision given how many metrics they must track about the relationship between weight and capacity/fuel cost - either you pay less than you save, or you don't pay it. > How much would Ferrari pay to make their F1 cars 1% faster? Probably a lot, but this is a (somewhat literal) Red Queen's race. > How much would car companies pay to be able to make 1% more fuel efficient cars? Probably nothing, their precision is already several times that. Empirically, they also don't care much. > How much would your electric bill save if rates were reduced 1%? Less than 5 euros a year - though this year maybe more, could be as high as 10. So, negligible - not even worth the time to write this comment, probably. Overall it seems like "1%" is often a fairly meaningless measure and I'm not sure what any of these examples are supposed to illustrate to me about compiler design or language choice since the context for each seems to matter more than anything else.
- Kukumber 4y ago
  > Less than 5 euros a year - though this year maybe more, could be as high as 10. So, negligible - not even worth the time to write this comment, probably. Then apply this 1% saved logic to everything else, food, clothing, leisure, insurance, medical bills, sport 1% is a lot, cumulatively
  - morelisp 4y ago
    Electricity is not 100% of the cost of "everything else". Nor are those part of my electricity bill. If you want to make a point about where 1% efficiency matters, go ahead and make it! I might even agree! But it still won't have anything to do with systems programming languages.

glouwbug 4y ago

Breh, the guy you’re responding to wrote D. Unless you’ve written something similar your argument is moot

morelisp 4y ago
This kind of sycophancy is disgusting.
- glouwbug 4y ago
  How? OP made a claim but OP hasn’t written a systems programming language as prevalent as D. It’s a baseless claim that’s either the result of inexperience or attempted flame bait. Walter is the only compiler expert on HN and our arguments should at least be thoughtful
  - morelisp 4y ago
    > Walter is the only compiler expert on HN What the fuck?