3 ms·
Perhaps the rationale is something like, “If your workload is memory-bandwidth-bound on 80 threads, this system is not for you.” Seems like its ideal workload
by twoodfin 5y ago
Perhaps the rationale is something like, “If your workload is memory-bandwidth-bound on 80 threads, this system is not for you.”
Seems like its ideal workload is lots of compute on a cache-friendly quantity of data.
- dragontamer 5y agoThe opposite. If you hit a memory-bandwidth bound on 80 threads, there's no point going up to 160 threads. In most situations, I expect code to be memory-latency bound on a single thread. (Ex: node = node->next style traversals are quite common, and you cannot progress until the memory has responded). This is exceptionally common in interpreted code (Java, Javascript, PHP, Python), especially OOP-code. So your 80 cores are sitting there waiting for RAM-latency to respond. Wouldn't it be nice if they could execute 80-other-threads in parallel while waiting? This converts a RAM-latency problem into a RAM-bandwidth problem. ------------ ONLY problems that are memory-bandwidth bound on 80 threads will benefit from this architecture.