3 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 th

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! But seriously, RAM should be used for caching purposes and a lot of the RAM usage you see in various monitoring tools is just that. Likewise, with SSDs being so fast these days, the strategy of just bringing everything you need "into RAM" and then letting the paging system handle the loading/unloading as you actually need it is a reasonable strategy. To your original point, honestly, it kind of seems like the "hunger for RAM" kind of has been satisfied! Mainstream computers have been coming with 8/16 GB of RAM for a decade now and it seems like there isn't much upwards pressure on that. More RAM can be useful for special use cases like intensive graphics/media tasks, running VMs, etc. but doesn't really make a difference day-to-day, where the RAM is just acting as a layer of caching, and no normal applications have a big enough working set to cause an issue.

Narishma 4y ago
> 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)

Narishma 4y ago

> 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)