4 ms·

All abstractions eventually leak the higher you go. It's just about whether you want to ignore it. These leaks are usually performance related.

lumost 4y ago
As someone who works on performance sensitive code with great regularity. I would note that moore's law has beaten most attempts to be smart on performance for the last ~20+ years. If code is written correctly, with correct algorithms, in a reasonably performant language - no amount of micro-optimization will beat moore's law.
- anonymoushn 4y ago
  I have found this to be very far from the truth, with most compute-bound or memory-bound tasks getting 10x speedups from minimal work by stuffing more work into each instruction and retiring more instructions per cycle without really changing the algorithm.
- deltasevennine 4y ago
  Sure. How does this connect with what I mentioned? Not being snarky, but I think I'm missing something because this remark seems to be completely random.
  - lumost 4y ago
    An abstraction that happens to harm performance is rarely a long-term problem. Eventually the hardware catches up. More software has been retired due to crappy abstractions than poor performance.
    - deltasevennine 4y ago
      So how does this contradict what I said? The leak is still there. As I said... people just choose to ignore it. IO has not been following moores law. So you can see high level abstractions around IO leak like crazy. And also, there is no "retiring" going on. Retiring something because of a bad abstraction almost never happens, whether it's because of performance or not. The bad abstractions stay forever. You just don't notice it. You just master the abstraction and keep on using it. Learning about the leaks and learning how to manipulate the high level abstractions to get around the leaks becomes an intrinsic part of the culture. It becomes so intrinsic that most people can't even wrap their mind around the flaw in the abstraction. They get defensive if you talk about it. It's invisible, but it's still there. SQL is the most leaky abstraction I have ever seen (in terms of performance). Learning to deal with it and all it's leaks are the norm now. People don't even refer to a query planner as a leak. The technical debt is so entrenched within our culture that it's actually considered to be a great abstraction. And who knows? Maybe mastering SQL with leaks and all is not a bad way to go. But mastering SQL involves dealing with a declarative language and manipulating it in ways that leak into the underlying implementation. No amount of optimization has fixed this. SQL isn't the only thing with this issue. For SQL the crappy abstraction is just performance related. But you see other abstractions continued to be used because simply it's too hard to retire them. Javascript, CSS, HTML, C++. Python2 (finally this has been retired). Basically it's everywhere. Abstractions are rarely retired. Abstractions with leaky performance problems are also never retired.
      - deltasevennine 4y ago
        sorry IO is the wrong term. Memory has not been following moores law
- taneq 4y ago
  Yeah but why don’t we have both? (Actually I think 99% of micro optimisations are harmful, it’s the higher level algorithmic optimisation that gives the best gains.)
  - kaba0 4y ago
    Do you mean microopromizations done by programmers or the compiler? Because if the former, I agree (especially regarding old “wisdoms” like left shifting instead of multiplying by two, when that’s the first thing any compiler will do. But it is true of even more “complex” tricks, if anything they hurt performance).
    - anonymoushn 4y ago
      Why is simdjson faster than json parsers that do not contain any simd intrinsics if using pshufb and movemask for string parsing hurts performance?
    - taneq 4y ago
      The former, absolutely. The compiler can do whatever the heck it wants as long as the result is the same.
- deleted 4y ago
  [deleted]
legulere 4y ago
Some abstractions leak more than others though, and I don’t think that has that much to do with the level at which the abstraction is. ORM-mappers are very leaky and you have to regularly read what SQL they generate and sometimes even read their source code. Most programmers will never have to read assembly generated by compilers and even less compiler source code.
- deltasevennine 4y ago
  Yeah you don't have to read assembly. But a higher level abstraction of a non-compiled language like python. The leakage occurs and is shown through performance.

lumost 4y ago

As someone who works on performance sensitive code with great regularity. I would note that moore's law has beaten most attempts to be smart on performance for the last ~20+ years. If code is written correctly, with correct algorithms, in a reasonably performant language - no amount of micro-optimization will beat moore's law.

anonymoushn 4y ago
I have found this to be very far from the truth, with most compute-bound or memory-bound tasks getting 10x speedups from minimal work by stuffing more work into each instruction and retiring more instructions per cycle without really changing the algorithm.
deltasevennine 4y ago
Sure. How does this connect with what I mentioned? Not being snarky, but I think I'm missing something because this remark seems to be completely random.
- lumost 4y ago
  An abstraction that happens to harm performance is rarely a long-term problem. Eventually the hardware catches up. More software has been retired due to crappy abstractions than poor performance.
  - deltasevennine 4y ago
    So how does this contradict what I said? The leak is still there. As I said... people just choose to ignore it. IO has not been following moores law. So you can see high level abstractions around IO leak like crazy. And also, there is no "retiring" going on. Retiring something because of a bad abstraction almost never happens, whether it's because of performance or not. The bad abstractions stay forever. You just don't notice it. You just master the abstraction and keep on using it. Learning about the leaks and learning how to manipulate the high level abstractions to get around the leaks becomes an intrinsic part of the culture. It becomes so intrinsic that most people can't even wrap their mind around the flaw in the abstraction. They get defensive if you talk about it. It's invisible, but it's still there. SQL is the most leaky abstraction I have ever seen (in terms of performance). Learning to deal with it and all it's leaks are the norm now. People don't even refer to a query planner as a leak. The technical debt is so entrenched within our culture that it's actually considered to be a great abstraction. And who knows? Maybe mastering SQL with leaks and all is not a bad way to go. But mastering SQL involves dealing with a declarative language and manipulating it in ways that leak into the underlying implementation. No amount of optimization has fixed this. SQL isn't the only thing with this issue. For SQL the crappy abstraction is just performance related. But you see other abstractions continued to be used because simply it's too hard to retire them. Javascript, CSS, HTML, C++. Python2 (finally this has been retired). Basically it's everywhere. Abstractions are rarely retired. Abstractions with leaky performance problems are also never retired.
    - deltasevennine 4y ago
      sorry IO is the wrong term. Memory has not been following moores law
taneq 4y ago
Yeah but why don’t we have both? (Actually I think 99% of micro optimisations are harmful, it’s the higher level algorithmic optimisation that gives the best gains.)
- kaba0 4y ago
  Do you mean microopromizations done by programmers or the compiler? Because if the former, I agree (especially regarding old “wisdoms” like left shifting instead of multiplying by two, when that’s the first thing any compiler will do. But it is true of even more “complex” tricks, if anything they hurt performance).
  - anonymoushn 4y ago
    Why is simdjson faster than json parsers that do not contain any simd intrinsics if using pshufb and movemask for string parsing hurts performance?
  - taneq 4y ago
    The former, absolutely. The compiler can do whatever the heck it wants as long as the result is the same.
deleted 4y ago
[deleted]

legulere 4y ago

Some abstractions leak more than others though, and I don’t think that has that much to do with the level at which the abstraction is. ORM-mappers are very leaky and you have to regularly read what SQL they generate and sometimes even read their source code. Most programmers will never have to read assembly generated by compilers and even less compiler source code.

deltasevennine 4y ago
Yeah you don't have to read assembly. But a higher level abstraction of a non-compiled language like python. The leakage occurs and is shown through performance.