I never thought of processor affinity as a VLSI topic. I mean you can muck about with it just using your OS, right? Also I did EE in college and it seemed a lot more low-level than that. Semiconductor principles, digital filters, JK Flip-flops, that kind of thing. I guess you end up meeting NUMA and affinity somewhere along the way.
The point the guy is making is that when you're coding this type of thing you need to understand how the computer actually calculates things, rather than just have a vague idea of a machine like you might if you code python. In python and those types of languages a lot of the inner workings are abstracted away. You can sort of just imagine an Oompa Loompa (a thread) reading the code, seeing the instructions (x = a + 2 if y==3 else a - 2 ) and going out to find the value of a in a box and putting in the value of x in another box. No idea where a and x boxes are, how close they are to each other. No idea about how that branching instruction works either, he just checks at the time and decides.
By contrast when you're writing for performance you want stuff to be in cache, so you need to have an idea of a machine that includes cache. Specifically the idea that the further away you are from the registers, the longer things take, and that some cache is shared while some isn't. You also want to think about a machine that can speculate and do branch prediction, so you'll need to think about how to write the code so the branch predictor mostly gets it right. I think the top stackoverflow answer is about that.
Affinity and NUMA are talking to this kind of machine (which is still abstract of course) which has a bit more detail than the Oompa Loompa.
You are probably better off learning more about what Martin Thompson calls 'mechanical sympathy'. Check out the LMAX/Disruptor talks. There are some blog around high performance/low latency computing.
The point the guy is making is that when you're coding this type of thing you need to understand how the computer actually calculates things, rather than just have a vague idea of a machine like you might if you code python. In python and those types of languages a lot of the inner workings are abstracted away. You can sort of just imagine an Oompa Loompa (a thread) reading the code, seeing the instructions (x = a + 2 if y==3 else a - 2 ) and going out to find the value of a in a box and putting in the value of x in another box. No idea where a and x boxes are, how close they are to each other. No idea about how that branching instruction works either, he just checks at the time and decides.
By contrast when you're writing for performance you want stuff to be in cache, so you need to have an idea of a machine that includes cache. Specifically the idea that the further away you are from the registers, the longer things take, and that some cache is shared while some isn't. You also want to think about a machine that can speculate and do branch prediction, so you'll need to think about how to write the code so the branch predictor mostly gets it right. I think the top stackoverflow answer is about that.
Affinity and NUMA are talking to this kind of machine (which is still abstract of course) which has a bit more detail than the Oompa Loompa.