[HN Gopher] The Elements of Cache Programming Style (2000)
___________________________________________________________________
The Elements of Cache Programming Style (2000)
Author : rramadass
Score : 38 points
Date : 2022-02-16 04:17 UTC (18 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| anko wrote:
| does anyone have any similar articles targeting arm64 (m1)?
| CalChris wrote:
| I suppose I should say ask me anything.
|
| This was written at a time when the Linux scheduler was a simple
| process loop. So Linux would come to a crawl when the process
| count hit like 64. I figured out the underlying but I didn't
| submit a patch. Then I really started looking at the problem, and
| the result of that investigation was this article which was/is a
| bit bombastic but a good tutorial on issues with caches
| nonetheless.
|
| Weird that it's on the front page lo these many years later.
| vrnvu wrote:
| Has anyone else noticed how data oriented design has became more
| common in the past years? At least it's my perception.
|
| For anyone interested on similar patterns on performance or good
| memory access practices. I highly recommend this recent talk by
| Andrew Kelly on data oriented design. It's one (if not the best)
| talk about the topic.
|
| https://media.handmade-seattle.com/practical-data-oriented-d...
| vymague wrote:
| I don't know who started the trend. I personally first heard
| about the term from Mike Acton's CppCon 2004 talk.
|
| But as pointed out by another comment, I don't think it's that
| mainstream. Outside HPC and game development. At least that's
| what came up when you google the relevant terms like cache,
| locality, etc.
| tuckerpo wrote:
| Sincerely caring about memory coherency is a totally lost art.
| Hardware gets faster, programmers add more abstractions to make
| their lives easier (read: ship more product, make companies more
| money) and the consumer is left kicking rocks with bug-riddled
| code 100x less performant than it could be.
| bob1029 wrote:
| It is astonishing to me that the most basic of memory hacks are
| regarded as dark magics these days. Many things take zero extra
| effort to make orders of magnitude faster if you are simply
| aware of some basic concepts.
|
| For instance, if you know a collection of things is going to be
| bounded by a reasonable quantity (e.g. less than 1mm) and that
| you will frequently need to perform a full linear scan of these
| things, you should consider using an array rather than some
| b-tree or other pointer-chasing type (List/Dictionary/etc).
| This is literally a simple "Should I use List<T> or
| T[MaxElements]" determination. The effects of this are very
| profound if many scans of these items need to be made per unit
| time (i.e. a game loop).
|
| You can take this one step further by trying to make the type
| used in the collection a value type rather than a reference
| type. Depending on language/runtime/problem space, this can
| give you another order of magnitude uplift. And, its pretty
| much as simple as "public [readonly] struct" vs "public class".
| throwamon wrote:
| Alright, so here's something stupid I've always wanted to
| ask: Is there some kind of library/language/paradigm where
| instead of declaring what data structures you want to use,
| you declare constraints and expectations and it guesses the
| "best" one? So even if you're uncertain, you can say "I
| _expect_ this collection to have about _n_ elements ", "this
| should be sorted", "I expect it to grow in a certain way",
| and so on (of course you might want to express much more
| advanced patterns).
| chenglou wrote:
| Some upcoming languages like Zig and Jai have features to
| allow you to easily switch from array-of-structures to
| structure-of-arrays at writing time
| (https://www.youtube.com/watch?v=zgoqZtu15kI). Some edge
| cases also require rather unique ways of chopping up data,
| that wouldn't lend themselves well to be shoehorned in one
| of the canned categories of transforms.
|
| Although constraint declaration is orthogonal to data-
| oriented development, I'd say that the philosophy of using
| generic constraint solvers (or other overly generalized CS
| ideas) goes against the spirit of DOD, which is to "just
| simply do the work". It is after all reacting against
| object-orientation (and even modern FP) which tended to
| think too much in the abstract and worrying too much about
| some form of taxonomy, as opposed to coding against plain
| data.
| jcelerier wrote:
| > Some upcoming languages like Zig and Jai have features
| to allow you to easily switch from array-of-structures to
| structure-of-arrays at writing time.
|
| no need to reach for upcoming languages, it's doable
| directly in C++: https://github.com/celtera/ahsohtoa =)
| bob1029 wrote:
| Sounds like you want SQL.
___________________________________________________________________
(page generated 2022-02-16 23:01 UTC)