4 ms·

> If you're sad about all of your RAM being eaten, you'll be despondent if you think about about your poor L1 and L2 caches--they're all being 100% used all of

> If you're sad about all of your RAM being eaten, you'll be despondent if you think about about your poor L1 and L2 caches--they're all being 100% used all of the time! You mean wasted all the time. With all the over-abstraction and layers of indirection that are rampant in modern software, I doubt your CPU caches are used anywhere near as efficiently as they could be.

Dave_Rosenthal 4y ago
You'll get no argument from me that most software is bloated and slow compared to what is possible. (I spent a lot of my career working on making code run fast!) But it feels wrong to say that the caches are wasted. The code we write do not explicitly control the L1/L2 caches. So whether the code we are running is super-optimized or super-bloated, the caches are responding to what's actually being accessed to make that code run as efficiently as it can.
- karmakaze 4y ago
  But we do influence how effectively L1/L2 caches are used. Each time we have a choice to split some fields into two objects or not, they can be allocated/cached together or separately. This is one of the huge outcomes of Java's project Valhalla to have Value objects that live 'in-place' rather than separately, the way embedded structs do in Go.
sebazzz 4y ago
> With all the over-abstraction and layers of indirection that are rampant in modern software Can you expand on that? Is .NET and Java, or Electron/Javascript an over-abstraction or too many layers? Or are certain patterns that, like CQRS or React?
- not_your_vase 4y ago
  Java is frequently a good example (but not the only one). For some reason many senior Java developers abuse OO principles, and make sure that when they throw an exception from Hello World, the stacktrace won't fit on the screen. Those lines are not free: each abstraction layer adds extra cpu cycles, and uses bytes on the stack.
  - kaba0 4y ago
    You get those stack frames because Java actually properly handles errors (instead of writing out the last error without any further context) - you definitely has at least that amount of stacktrace in pretty much every CRUD app built on top of your framework of choice. Frameworks solve a litany of mainstream problems with CRUD apps so imo it is absolutely well warranted. And frankly, java trivially optimizes those virtual calls away, so it unlikely to have any serious performance impact. Add to it that the overabstraction you talk about hasn’t been as prevalent in the last decade anymore (it actually came from the C++ times, .COM, etc), and you are left with memory layout as the only serious performance bottleneck in most managed languages and that is not as significant in every kind of workload (you are not writing simulations all the time)

Dave_Rosenthal 4y ago

You'll get no argument from me that most software is bloated and slow compared to what is possible. (I spent a lot of my career working on making code run fast!) But it feels wrong to say that the caches are wasted. The code we write do not explicitly control the L1/L2 caches. So whether the code we are running is super-optimized or super-bloated, the caches are responding to what's actually being accessed to make that code run as efficiently as it can.

karmakaze 4y ago
But we do influence how effectively L1/L2 caches are used. Each time we have a choice to split some fields into two objects or not, they can be allocated/cached together or separately. This is one of the huge outcomes of Java's project Valhalla to have Value objects that live 'in-place' rather than separately, the way embedded structs do in Go.

sebazzz 4y ago

> With all the over-abstraction and layers of indirection that are rampant in modern software Can you expand on that? Is .NET and Java, or Electron/Javascript an over-abstraction or too many layers? Or are certain patterns that, like CQRS or React?

not_your_vase 4y ago
Java is frequently a good example (but not the only one). For some reason many senior Java developers abuse OO principles, and make sure that when they throw an exception from Hello World, the stacktrace won't fit on the screen. Those lines are not free: each abstraction layer adds extra cpu cycles, and uses bytes on the stack.
- kaba0 4y ago
  You get those stack frames because Java actually properly handles errors (instead of writing out the last error without any further context) - you definitely has at least that amount of stacktrace in pretty much every CRUD app built on top of your framework of choice. Frameworks solve a litany of mainstream problems with CRUD apps so imo it is absolutely well warranted. And frankly, java trivially optimizes those virtual calls away, so it unlikely to have any serious performance impact. Add to it that the overabstraction you talk about hasn’t been as prevalent in the last decade anymore (it actually came from the C++ times, .COM, etc), and you are left with memory layout as the only serious performance bottleneck in most managed languages and that is not as significant in every kind of workload (you are not writing simulations all the time)