The relationship of simplicity and performance

Topic: The Relationship of Simplicity and Performance

13:05

Hello everyone! This fishbowl (topic: https://github.com/AsafGartner/hmn_fishbowl/discussions/30) was prompted by a conversation that occurred in the Dion Systems server. The topic arose when discussing the use of standard library containers, data structures, or other APIs, and comparing that with other approaches, like writing your own allocators and data structures. My argument was that something in, say, a standard library, is not necessarily an ideal version of, say, an allocator or generic data structure implementation. Such things are often intended to span across a very wide space of use-cases, and are therefore required to be more generic. This introduces cruft and performance problems in use-cases that do not require such genericism. For instance, memory arenas versus a traditional malloc and free API. Memory arenas will always allocate faster than malloc, and it isn't because they have had more engineering time poured into optimizing them, but rather because they have a much simpler job to do. In this way, abstractions are, to some degree, coupled with their underlying implementation. I was attempting to use this point to make the case that Handmade is not anti-abstraction, it's anti-trusting-abstractions-without-evidence. That kicked off the conversation regarding performance vs. simplicity. In this fishbowl I am hoping to discuss with you all a few questions, like "how do we define simplicity?", "what are characteristics of 'simple' code?", and "how does 'simpler' code, in the way that we mean it, perhaps lead to performance advantages?" So I guess we should start with the definition of 'simple', since that seems like it's overloaded on many fronts.

13:05

Adding roles now...

13:08

I hope we don't spend the entire time discussing the definition of simplicity

but I do think it's probably good to clear up yeah.

Right---that alone is a rathole that could last hours

At the very least we have the Rich Hickey "Simple Made Easy" definitions, which are that simple means "not entangled", roughly, whereas easy means "close at hand". And those two things are pretty much completely independent. (edited)

13:10

And because this is HMN, I expect we all broadly have a decent shared understanding of what we mean by "simple". (edited)

Maybe someone should point out the etymology for complex. I'm at least thinking of these other words: simplex, duplex, complicated. The latter one especially, I think in French plier is to fold

yeah this was hinted at by ben's comment about the rich hickey definitions, in which he does just that

13:42

but it's worth making it explicit

yeah the terminology Hickey uses is "complect", a word meaning "to entangle" or "to braid together"

I was thinking about this definition of simplicity in anticipation of this conversation, and I do think it makes sense to outline some various ideas of what simplicity means to us. But I am going to propose we explore the way various kinds of simplicity relate to performance. That'll give us more to talk about and we don't have to agree on a single definition to get to good stuff.

1

Sounds good! I'm good with that route.

13:11

Yeah, I partly think that the simple or simplicity word is overloaded-enough to the point that it can be unhelpful or really muddied. But we often use it as a "hand-wavey" handle to certain ideas that, in my estimation, are more concrete.

My take on it is probably a bit of a "vulgar" way to define simple. I think some folks would like simple defined in purely abstract information-theoretic terms. Something you could write proofs or religions about...

13:15

To me I just work backwards from the reality that I want good software, and a lot of people who know what they're talking about agree that something called simple is relevant, and I arrive at something like this. Something is simple when it is easy to work with, easy to implement, easy to use, easy to understand, etc, especially when it also solves a problem that can seem hard without this "something".

1

The last bit might be the most important

I think something similar to the hickey definition, but not quite the same, is "direct"

13:13

when you want to do X you do X, not X and several other things as well (edited)

2

I see, interesting. Yeah one concrete aspect I was going to bring up had to do with number of codepaths, particularly that do non-duplicative and uniform work, and I was hoping on relating that to performance by pointing out the reality that uniform work is easier to predict, easier to optimize than an equivalent large number of codepaths with many concepts muddied. And I think that ties into easy to implement, because fewer codepaths => less implementation work. easy to use, as fewer interfaces to fewer codepaths => fewer things to understand. etc.

13:20

It's not just number of codepaths I am trying to get at, though, and I am not sure if you guys have ideas or if it's not fruitful to rathole on that. But I often think of what I am describing as "orthogonality" of codepaths. When each codepath does one slice of the problem, and can be composed with other codepaths to form all the points you need in the "space of features" that you require for your problem. In that sense, each codepath is like an axis, and you can build a "point" by composing use of those codepaths, or the lack thereof, e.g. (codepath1, codepath2, 0, codepath4). And of course, all codepaths are parameterized too (or can be). (edited)

easy to implement, because fewer codepaths => less implementation work

This is why we have @rxi here, because one of the things I've noticed is that his code is both what I would consider very simple, and probably as a result, very small (compared to what others, including myself, would probably come up with) (edited)

1