5 ms·

> the cost is extremely small until it isn't, i've seen branches eat 10-15% of hotspots sometimes. but honestly, in practical terms, I shouldn't complain if pe

> the cost is extremely small until it isn't, i've seen branches eat 10-15% of hotspots sometimes. but honestly, in practical terms, I shouldn't complain if people want that: that's literally more consulting money in performance consulting for me afterwards :-) let me repost one of my own past comments with a quick and dirty benchmark: https://news.ycombinator.com/item?id=30867368 https://news.ycombinator.com/item?id=30867368 I have been paid hard money for performance improvements much smaller than something like this in my life

tialaramex 4y ago
But at the end of those comments you linked, what you concede is that the reason people often end up with code that has lousy performance isn't, in fact, because of a language defect but because programming isn't their "real" job anyway - these are non-experts and so you'd often be fixing the same problems in C++ too. Or maybe more often. From what I've seen those "not really a programmer" types write much better Rust than C++. Such non-expert practitioners are going to lean on defaults more often than an expert, and of course the C++ defaults are all wrong, so that's a problem both for correctness and performance. Well, not a problem for you maybe, you get paid. But clients might wonder if they can't just avoid this problem...
- jcelerier 4y ago
  when non-experts give me C++ code to optimize most of the time there are enough low-, sometimes very-low- hanging fruits which we can incrementally refactor piece by piece into something that performs better. when it's JS or python code.. like my man, here's your invoice for the rewrite. > much better Rust than C++. I really do not thing we'd agree on what is good code so I don't see a point in arguing more on this > Such non-expert practitioners are going to lean on defaults more often than an expert i'd like to see that. what i've seen is people who were working on safety-critical code who could not write a for-loop if their life depended on it, and most of the time people who just redo what they learned in class which is likely from a 1993 textbook. code entirely written in japanese, identifiers included, or as a french/english mix sometimes in the same identifier. it's really all over the place out there.
CJefferson 4y ago
Looking at that benchmark, marking a function as "static" was enough to make the bounds checks be optimised away. One difference between C++ and Rust (yes, I know they seem to get compared a lot) I like is that the "default function" is the safe one. In Rust you disable bounds checking for a particular, but [] does bounds checking. In C++ you can do "bounds checked access", but [] does unsafe. In my opinion, it's best if the "default option" users reach for is the safe, but possibly slower option. Then, in a situation where a user is sure about what they are doing, and the boost is worth it, they can reach for the less safe option. In a program I'm currently working on we have disabled bounds checking in exactly two functions, as benchmarking showed it was worth it, and we carefully checked it would be safe to do.
- jcelerier 4y ago
  > Looking at that benchmark, marking a function as "static" was enough to make the bounds checks be optimised away. and that's nice when you can do this (or apply LTO which would likely give the same result) - you definitely can't always do this. Think proprietary vendor selling a DLL containing some very specific DSP routines.

tialaramex 4y ago

But at the end of those comments you linked, what you concede is that the reason people often end up with code that has lousy performance isn't, in fact, because of a language defect but because programming isn't their "real" job anyway - these are non-experts and so you'd often be fixing the same problems in C++ too. Or maybe more often. From what I've seen those "not really a programmer" types write much better Rust than C++. Such non-expert practitioners are going to lean on defaults more often than an expert, and of course the C++ defaults are all wrong, so that's a problem both for correctness and performance. Well, not a problem for you maybe, you get paid. But clients might wonder if they can't just avoid this problem...

jcelerier 4y ago
when non-experts give me C++ code to optimize most of the time there are enough low-, sometimes very-low- hanging fruits which we can incrementally refactor piece by piece into something that performs better. when it's JS or python code.. like my man, here's your invoice for the rewrite. > much better Rust than C++. I really do not thing we'd agree on what is good code so I don't see a point in arguing more on this > Such non-expert practitioners are going to lean on defaults more often than an expert i'd like to see that. what i've seen is people who were working on safety-critical code who could not write a for-loop if their life depended on it, and most of the time people who just redo what they learned in class which is likely from a 1993 textbook. code entirely written in japanese, identifiers included, or as a french/english mix sometimes in the same identifier. it's really all over the place out there.

CJefferson 4y ago

Looking at that benchmark, marking a function as "static" was enough to make the bounds checks be optimised away. One difference between C++ and Rust (yes, I know they seem to get compared a lot) I like is that the "default function" is the safe one. In Rust you disable bounds checking for a particular, but [] does bounds checking. In C++ you can do "bounds checked access", but [] does unsafe. In my opinion, it's best if the "default option" users reach for is the safe, but possibly slower option. Then, in a situation where a user is sure about what they are doing, and the boost is worth it, they can reach for the less safe option. In a program I'm currently working on we have disabled bounds checking in exactly two functions, as benchmarking showed it was worth it, and we carefully checked it would be safe to do.

jcelerier 4y ago
> Looking at that benchmark, marking a function as "static" was enough to make the bounds checks be optimised away. and that's nice when you can do this (or apply LTO which would likely give the same result) - you definitely can't always do this. Think proprietary vendor selling a DLL containing some very specific DSP routines.