This is the homepage of Peter Alexander. I am currently at Facebook working on AR/VR. Any opinions are my own.
Recent Posts
- Single-Threaded Parallelism
- unique_ptr Type Erasure
- The Condenser Part 1
- Cube Vertex Numbering
- Range-Based Graph Search in D
All Posts
Links
github.com/Poita@Poita_
Atom Feed
Holism
Here’s some SSE code to normalize a 3-vector:
Here’s some SSE code to normalize four 3-vectors:
As you’ve no doubt noticed, normalizing four vectors in the right format is just about as fast as normalizing one vector.
This is nothing new. It’s fairly well known that using structure of arrays opens up more optimization opportunities than arrays of structures.
The interesting thing here is that there is no API with a function called
normalize(vec3 v)
that can take advantage of this. There is no way to break
down the problem of normalizing four vectors in a way that recombining the parts
is as efficient as the whole.
Holism is the idea that systems should be viewed as wholes rather than the sum of their parts. The opposite of Holism is Reductionism. A Reductionist, when presented with the problem of normalizing 100 vectors would first find a way to normalize one vector, then apply that 100 times. A Holist would see the problem as a whole, and realize that the normalizations can be done in parallel. The Reductionist would use the first code snippet. The Holist would use the second.
I like this quote from Stepanov on the subject:
It is essential to know what can be done effectively before you can start your design. Every programmer has been taught about the importance of top-down design. While it is possible that the original software engineering considerations behind it were sound, it came to signify something quite nonsensical: the idea that one can design abstract interfaces without a deep understanding of how the implementations are supposed to work. It is impossible to design an interface to a data structure without knowing both the details of its implementation and details of its use. The first task of good programmers is to know many specific algorithms and data structures. Only then they can attempt to design a coherent system. Start with useful pieces of code. After all, abstractions are just a tool for organizing concrete code.
If I were using top-down design to design an airplane, I would quickly decompose it into three significant parts: the lifting device, the landing device and the horizontal motion device. Then I would assign three different teams to work on these devices. I doubt that the device would ever fly. Fortunately, neither Orville nor Wilbur Wright attended college and, therefore, never took a course on software engineering. The point I am trying to make is that in order to be a good software designer you need to have a large set of different techniques at your fingertips. You need to know many different low-level things and understand how they interact.
I think the take-away point here is that you should consider your problem as a whole before you begin breaking it down into smaller parts. It’s tempting to start creating a separate class for every noun in your application domain, but more often than not there is a better design involving a more holistic approach.