3 ms·

I feel like the old adage "premature optimization is the root of all evil" needs to be amended "...unless we're talking about optimizing for the L1 cache becaus

I feel like the old adage "premature optimization is the root of all evil" needs to be amended "...unless we're talking about optimizing for the L1 cache because: do that first!" Data locality is an architecture problem - I really think it needs to be considered when you first map out the data structures. While it's great to draw attention to this and to bring any performance you can to Ruby, I'm not sure the effects of it will be felt. While the hash indices are now local to each other, the elements of the hash are still scattered all over the atmosphere. You really want hash table contents to be local as well. I wonder if we'll ever see a language grouping things in memory by type - who knows, perhaps one of you can steer me in the right direction here. My primary tool of the moment is the slotmap for this sort of thing: https://gist.github.com/kickscondor/e706145b20293dc05b0a262a007046f1 https://gist.github.com/kickscondor/e706145b20293dc05b0a262a... But it isn't a hash table in quite the same way, in that the "hash keys" are generated from the data's location in the table rather than from its content. I wonder what a hash table would look like which was designed to keep everything in cache-friendly pages.

rcthompson 10y ago
I don't think the adage needs revising. We just need to remember that it applies to programming language users, not programming language writers. The whole idea is that the writers of your programming language should be doing most of the optimizing for you by making sure the language's primitives are already well-optimized for common tasks.
- sreque 10y ago
  This fallacy props up surprisingly often. We should not treat programming language writers as a separate class of people from programming language users. We often have the same needs and require the same solutions. My Master's adviser joked that every company ends up implementing their very own ad hoc, poorly designed programming languages to meet their specific needs. After working in the industry for almost a decade I've seen the truth of this joke. A lot of the problem comes from the kind of thinking that would say "this adage applies to programming language writers, not users."
- kickscondor 10y ago
  Sure, I think what a programmer is building may allow for ignorance of performance - a microservice may be so short-lived and its memory usage so small that it all fits into 32k anyway. No point optimizing. But think about mobile developers. You aim to paint 60 times per second. If Swift doesn't give you any tools for ensuring a specific memory layout - I imagine it does, by having some kind of contiguous array of structs - then how do you optimize those heavily trodden pathways of your app that could really use keeping a certain array within that 32k? This applies to WebGL developers, too. It seems like I've seen code where folks were using arrays of integers to achieve data locality - using a kind of serialization almost to pack and unpack from this array - alas I can't seem to recall where I saw that.
stormbrew 10y ago
Systems that have a compacting copying garbage collector can, as a side effect, get good locality of data. This is because the compacted heap will be ordered by the object graph. This can also potentially happen with promotion to tenured heaps as well, but less directly so. MRI can't do this for various reasons related to its C API though.
jstimpfle 10y ago
> I wonder if we'll ever see a language grouping things in memory by type - who knows, perhaps one of you can steer me in the right direction here. Maybe head towards databases? Look into Array languages, there might be something useful.

rcthompson 10y ago

I don't think the adage needs revising. We just need to remember that it applies to programming language users, not programming language writers. The whole idea is that the writers of your programming language should be doing most of the optimizing for you by making sure the language's primitives are already well-optimized for common tasks.

sreque 10y ago
This fallacy props up surprisingly often. We should not treat programming language writers as a separate class of people from programming language users. We often have the same needs and require the same solutions. My Master's adviser joked that every company ends up implementing their very own ad hoc, poorly designed programming languages to meet their specific needs. After working in the industry for almost a decade I've seen the truth of this joke. A lot of the problem comes from the kind of thinking that would say "this adage applies to programming language writers, not users."
kickscondor 10y ago
Sure, I think what a programmer is building may allow for ignorance of performance - a microservice may be so short-lived and its memory usage so small that it all fits into 32k anyway. No point optimizing. But think about mobile developers. You aim to paint 60 times per second. If Swift doesn't give you any tools for ensuring a specific memory layout - I imagine it does, by having some kind of contiguous array of structs - then how do you optimize those heavily trodden pathways of your app that could really use keeping a certain array within that 32k? This applies to WebGL developers, too. It seems like I've seen code where folks were using arrays of integers to achieve data locality - using a kind of serialization almost to pack and unpack from this array - alas I can't seem to recall where I saw that.

stormbrew 10y ago

Systems that have a compacting copying garbage collector can, as a side effect, get good locality of data. This is because the compacted heap will be ordered by the object graph. This can also potentially happen with promotion to tenured heaps as well, but less directly so. MRI can't do this for various reasons related to its C API though.

jstimpfle 10y ago

> I wonder if we'll ever see a language grouping things in memory by type - who knows, perhaps one of you can steer me in the right direction here. Maybe head towards databases? Look into Array languages, there might be something useful.