3 ms·
I think re-evaluation of biases regarding what a single computer/cpu/thread can do would go a long way for a lot of developers. Having hundreds or thousands of
by bob1029 2y ago
I think re-evaluation of biases regarding what a single computer/cpu/thread can do would go a long way for a lot of developers.
Having hundreds or thousands of cores to work with is meaningless if the state between those threads is constantly in another castle. Having to go to DRAM or another CCX is a very expensive operation compared to staying within L1/L2 on a single core.
Put differently, if the problem generally has a serialized narrative of events that must be followed (e.g., how we action the current event depends on all prior events being resolved), then spreading the problem across many threads will only slow us down. Contention will immediately dominate. This is where we get things like single writer principle from.
There aren't very many problems that a business would pay you to write software for that are not of the serialized narrative variety. Most ordinary people aren't thinking in terms of mutexes and semaphores. They are thinking in terms of what is effectively a gigantic interpreter lock over their enterprise.
- pornel 2y agoThe warp model in GPUs is great at hiding the DRAM latency. The GPU isn't idly waiting for DRAM. All threads that need a memory access are in a hardware queue, and data coming from the DRAM immediately dequeues a thread and runs the work until the next memory access. So you compute at the full throughput of your RAM. Thread scheduling done in software can't have such granularity and low overhead, and hyperthreading has too few threads to hide the latency (2 vs 768).