5 ms·

But it's not unreasonable for a programmer to expect no temporaries in code that just uses references. The rules are too complex, some of this is down to the l

But it's not unreasonable for a programmer to expect no temporaries in code that just uses references. The rules are too complex, some of this is down to the language itself and some is the fault of compiler writers. I find myself using Compiler Explorer more and more for short code snippets to (obviously) see what the compiler is doing because I don't really trust my intuition that much any more. And the annoying thing is that clang and gcc can differ wildly in their codegen. I don't think anyone can call themselves a C++, or possibly Rust, programmer unless they can also understand assembly code. Just getting code to compile isn't enough. It seems like a step backwards to me.

josephg 6y ago
> I don't think anyone can call themselves a C++, or possibly Rust, programmer unless they can also understand assembly code. Slow down on the gate keeping there. It really depends what you’re trying to achieve. I’ve spent the last few days optimising a btree implementation in rust. The code runs fast, but the performance varies +/- 15% or so seemingly arbitrarily based on how I structure my code. I could hop into compiler explorer and figure out what the compiler is actually doing. But the code is long and complex, and my mostly-allocation free approach is already about 80x faster than the javascript implementation this code is trying to replace. Optimising it further is not worth my time. The fact that I don’t have the skills or the time to squeeze a few more % out of my algorithm doesn’t make me a bad rust programmer. It makes me good at planning - I’m optimising my time. There will always be a line in the sand where further optimizations based on even deeper understanding will stop being worth your effort. Where that point is depends on the project. Is it worth running benchmarks? Doing profile based hotspot optimization? Is it worth looking at the compiler’s assembly output? Are you going to hardcode asm routines? How about per-cpu variants of core algorithms for popular CPUs? No. We all stop somewhere, depending on the needs of the project at hand, depending on how our time is best spent. That is the only reasonable answer if you want to ever finish projects. You don’t get to tell me I’m not a real rust programmer because I’m not microoptimizing this project as much as you would. That’s silly.
- secondcoming 6y ago
  Actually, I don't think it's silly at all. Beating JS isn't hard to achieve, it doesn't tell you much about the quality of your code. Me beating a toddler in a 100m sprint doesn't make me an athlete. Benchmark against a C or C++ implementation. You'll be examining things on Compiler Explorer soon enough.
  - josephg 6y ago
    Beating JS by 5x is easy. Beating a good JS implementation by 80x is much harder. > Benchmark against a C or C++ implementation Alas no; I'm not going to do that. First because there aren't any implementations in C/C++ for what I'm doing. But also, because as much fun as it is to wring every last cycle out of my CPU, I've met myself. Spending every moment trying to make my code go faster is a trap. If I spend too much time optimizing for performance, I'll never finish what I'm writing. I've done it before. Performance is fun because its measurable. You get a score, and that feels great. But beyond some point, documentation, testing and features all become much more important. I could write the fastest library in the world but if its buggy, missing features or has no documentation, nobody will use it. Worse, I won't be able to build things on top of it because I'll be too distracted trying to make my benchmark numbers go up. Performance is fun, but its far from the only measure of software quality.
  - eek04_ 6y ago
    I spent a decade or so of my life writing assembly, and a few years as a performance specialist for a programming team. What you're describing is a specialist skill. There's nothing wrong with it - it's a good skill to have - but there is no need to have everybody in the team have it, and you can expect better results by having some people develop that skill and other people develop other skills.

josephg 6y ago

> I don't think anyone can call themselves a C++, or possibly Rust, programmer unless they can also understand assembly code. Slow down on the gate keeping there. It really depends what you’re trying to achieve. I’ve spent the last few days optimising a btree implementation in rust. The code runs fast, but the performance varies +/- 15% or so seemingly arbitrarily based on how I structure my code. I could hop into compiler explorer and figure out what the compiler is actually doing. But the code is long and complex, and my mostly-allocation free approach is already about 80x faster than the javascript implementation this code is trying to replace. Optimising it further is not worth my time. The fact that I don’t have the skills or the time to squeeze a few more % out of my algorithm doesn’t make me a bad rust programmer. It makes me good at planning - I’m optimising my time. There will always be a line in the sand where further optimizations based on even deeper understanding will stop being worth your effort. Where that point is depends on the project. Is it worth running benchmarks? Doing profile based hotspot optimization? Is it worth looking at the compiler’s assembly output? Are you going to hardcode asm routines? How about per-cpu variants of core algorithms for popular CPUs? No. We all stop somewhere, depending on the needs of the project at hand, depending on how our time is best spent. That is the only reasonable answer if you want to ever finish projects. You don’t get to tell me I’m not a real rust programmer because I’m not microoptimizing this project as much as you would. That’s silly.

secondcoming 6y ago
Actually, I don't think it's silly at all. Beating JS isn't hard to achieve, it doesn't tell you much about the quality of your code. Me beating a toddler in a 100m sprint doesn't make me an athlete. Benchmark against a C or C++ implementation. You'll be examining things on Compiler Explorer soon enough.
- josephg 6y ago
  Beating JS by 5x is easy. Beating a good JS implementation by 80x is much harder. > Benchmark against a C or C++ implementation Alas no; I'm not going to do that. First because there aren't any implementations in C/C++ for what I'm doing. But also, because as much fun as it is to wring every last cycle out of my CPU, I've met myself. Spending every moment trying to make my code go faster is a trap. If I spend too much time optimizing for performance, I'll never finish what I'm writing. I've done it before. Performance is fun because its measurable. You get a score, and that feels great. But beyond some point, documentation, testing and features all become much more important. I could write the fastest library in the world but if its buggy, missing features or has no documentation, nobody will use it. Worse, I won't be able to build things on top of it because I'll be too distracted trying to make my benchmark numbers go up. Performance is fun, but its far from the only measure of software quality.
- eek04_ 6y ago
  I spent a decade or so of my life writing assembly, and a few years as a performance specialist for a programming team. What you're describing is a specialist skill. There's nothing wrong with it - it's a good skill to have - but there is no need to have everybody in the team have it, and you can expect better results by having some people develop that skill and other people develop other skills.