In a pointer heavy language like D, a 1% loss is a big deal. I.e. it would no longer be a systems programming language.
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.
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.
There is no control over the duration, or what third party code is doing with them.
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.
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.
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.
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.
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.
Then apply this 1% saved logic to everything else, food, clothing, leisure, insurance, medical bills, sport
1% is a lot, cumulatively
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.
your system being 1% faster mean everyone who depend on your system will be 1% faster, and if you yourself apply that logic to your system, it's commutative, and the results ends up being impressive
if you don't understand that, then there is no point arguing further
What the fuck?
1% compared to what? Hand-written assembly? C? C++?
Clang and GCC differ by way more than 1% in most benchmarks. Does that mean that one of them can't compile system languages or something?
I mean, I would agree that there definitely is a performance threshold below which you wouldn't consider a language a "systems language" - i.e. it would be silly to write an OS in the language. But 1% seems at least an order of magnitude off.
Jane Street has used OCaml for about 20 years.
Last year, OCaml merged an improvement to its GC that reduced latency by 75% (by one measure), and reduced execution time by 23% when compiling OCaml and around 6 to 7% when compiling Coq libraries:
https://github.com/ocaml/ocaml/pull/10195#issuecomment-89615...
Performance is definitely left on the table even in mature and mission-critical software.
Remember the stories about traders trying to shave milliseconds off of their trading speed?
I even met a hedge fund that ran their back test platform mostly on hardware because it allowed them to run more tests, which was a strategic advantage.
That said, 1% for free makes the ghost of Admiral Hopper happy and that’s reason enough for all of us.
moonchild's suggestion to monomorphise against GC/explicitly managed pointers might reduce that figure lower; evidently you know D programs better than I, but it doesn't seem unreasonable that the 1% can be won by a faster GC.
Of course, it depends on your coding style, but yes, that is generally true.
You won't notice it on your desktop. But you will notice it in cases I mentioned. Top shelf games also are not going to give up that 1%, or so the game devs tell me.
Unity is also the official developer SDK for Microsoft's HoloLens Virtual Reality Toolkit.
- Unity games
- NWN2 which I mentioned
- CrossCode which is an HTML5 game (while being an absolutely great game, performance wise this one was by far the worst I ever experienced, it's laggy on a fucking GTX1070 / 8750H / 32GB RAM system for a 2D pixel-art rpg and made me quit the game in rage more than once)
Doing the game in C++ certainly hasn't helped Cyberpunk 2077 performance and being bug free.
I don't think this is a reasonable remark.
The whole point is that the 1% penalty is added on top of whatever choices "the likes of Sony and Nintendo" make. If they have alternatives that ensure them a performance win just by chosing the right tool to work with Unity, they won't choose the wrong one.
D had a chance in the games industry with Remedy and lost it, instead a language that supposedly lesser one, is being adopted by major platform owners.
No, it was not a reasonable remark. Pointing someone else's choice changes nothing. The point that you keep missing is that performance is a key decision factor, one among many, and baseline performance penalties imposed by a particular choice of programing is a factor that adds up to all other choices. If you degrade the performance of your offering without any relevant tradeoff, you're making it harder to justify it's adoption.
Feel free to insist in your personal assertion. Those who care about performance feel strongly about gratuitously pile performance penalties without any meaningful tradeoff to show.
Minecraft wouldn't never have happened if Notch was busy discussing if it would be acceptable at all doing it in Java.
Just like too many in HN dream of being the next FANG, too many worry about the ultimate performance when their games would hardly win a fraction of Minecraft when placed into the market.
Getting acceptable performance in my game despite my focus on playability and time to market is one of the benefits of platform choice. I want to focus on my game, not overcoming platform limitations.
I am not saying a single 1% makes a difference but the idea that performance in the platform does not matter is wrong.
But nobody said this. Maybe we're too deep in the thread for anyone to remember, so let's refresh our memories. The claim was not that performance doesn't matter, or that 1% never matters, but that any language 1% slower than D is currently could categorically not be considered a systems programming language.
That's even more absolutist and absurd than "performance does not matter".
Especially that research OSs were written in managed languages, often with better performance!
Uh you know who’s so patiently answering your questions, right? My guess is that he’s been world famous at this since you were a twinkle in your daddy’s eye. He’s had a minute to think about it...
These API have been removed in ISO C++20, only because the biggest C++ GC customers, like Epic and Microsoft, never made use of them and carried on using their own implementions.
Your specific claim at the top of this chain is in response to someone asking "why don't you do this thing [that has 1% performance impact]", to which you respond "I cannot bundle a 1% performance hit in my language, because this would not make it a systems language". Putting aside the usual debate of what a systems language even is, if we consider the ones that are typically not up for debate: C, C++, Rust, these differ in performance by far more than 1% on typical workloads. As some commenters have mentioned, compiler optimizations alone cause pessimizations of greater than 1%, so looking at a number like this as any qualifier of how feasible something is doesn't make sense.
Taking a step back, I feel like you are missing what people actually mean when they're talking about "1%". Like, yes, 1% of Facebook's server load is $$$. Making a dozen 1% improvements to SQLite is a good improvement. But, like, you're conflating this with what you're doing, and it's not at all related. There are companies using Python in production right now trying to save 1%! The reason why this is a "rational" decision is that performance work is not actually a function of how much percent you can shave off your workload, but how you can balance a couple of people trying to wring a couple percent off of your existing code. The unfortunate truth is pretty much all code, even the stuff running billions of CPU hours in datacenters, is leaving tens of percent on the table at the very least just by using a high level language, with poor data access patterns, etc. The reason this is OK is that rewriting all of the code into perfect assembly or whatever is not a feasible task. It would be super tedious, error prone, and require huge amounts of effort. So it becomes relevant for specific people to try shave off a few percent here and there around an inherently inefficient codebase, because that's where the balance lies. Compared to the effort it took to write or migrate the code, the 1% win is always going to be a small fraction of the engineering cost. Otherwise, you'd just replace the thing altogether.
So, circling back around to your point: a 1% loss isn't actually catastrophic. If you put 1% extra code in for no reason and it was easy to get rid of it with something a little smarter, people would rightfully be up in arms. But if you bring actual benefit that is very hard to get any other way, then it's usually going to be welcomed. I mean, people are putting in specialized hardware to slow down their general C++ application code "just" 5-10% to get a fraction of the benefits of actually having memory safety. There's a limit to how much people will tolerate, and it's definitely not like 30%, but if the only penalty was 1% at runtime and you could never have to worry about freeing memory again this would probably be a good tradeoff.
(To answer your bit about why the C standard doesn't have garbage collection: multiple reasons. One is that people who use C have very picky views of how garbage collection should look like on their platform. And the other bit is that garbage collection is typically not "just" 1% CPU overhead, it has interactions with things like latency and memory usage, which I think other people have actually pointed out about this 1% figure. The reason I specifically called you out was because you accepted this and decided to argue for that number, rather than saying "oh, well, there's actually more to it than just that 1%".)
True! Duly upvoted. Although I feel his arguments are closely reasoned and don’t agree with your point. And the person I responded to brought nothing you to the table.
Where is it that Walter is obviously wrong, by the way? Not trying to be argumentative. I just did not see the holes in his argument that you do.
EDIT: you said tons of people. Well... thousands of paying customers in a market much smaller than today's, but that's probably not tons.
My guess is that it is not that big of a niche, although the players are probably big
It's like weight on an airplane. Boeing told me back in 1980 that saving one pound was worth a quarter million dollars of investment. That'd be like a million bucks today.
The boeing example is illuminating. One could conceive of infinite possibilities where it would be better to spend the extra million dollars than to get something that saved a pound but didn't meet other project requirements. What good would it be to buy a $1M cheaper 747 if the landing gear broke on each landing? Everything is a tradeoff, even things that are extremely important like weight on airplanes or runtime performance in computers.
SHR R_pointer, 9
AND R_pointer, <cards>
MOV BYTE [R_cards + R_pointer], 0
On the other hand, "Barriers revisited" does mention a pathology about how cards can introduce false sharing, but that's still more of a smear than a spike.
It's a different tradeoff if the languages primary allocation scheme is GC.
Unfortunately, it's not fast enough.