4 ms·
Single-thread performance is only relevant for workloads that can't be parallelized, or for software that will never be adapted. It has been well known for more
by samus 3y ago
Single-thread performance is only relevant for workloads that can't be parallelized, or for software that will never be adapted. It has been well known for more than a decade now that parallelization is the only way forward.
Edit: application-specific accellerators are another promising approach that has been in vogue for a long time and which achieves speedups that are obviously not easily visible by looking at simple GHz metrics
- pjc50 3y ago> only relevant for workloads that can't be parallelized This ends up dominating anyway. Partly because the easy stuff does get parallelized. So you're left with things like "browser layout engine" being single threaded. Almost all systems have single-threaded UIs, because trying to do anything else becomes unreasonably hard to reason about. The UI thread will delegate work to other threads, but there is nearly always a single "UI thread" bottleneck.
- samus 3y agoFor most desktop applications, this bottleneck is not that restricting though. Almost any noticeable UI delay is due to stuff that ought to be offloaded into a background thread, but isn't. For example, IntelliJ often freezes up when I enter a search string in the settings dialog, which is probably due to a search index being loaded or built on the UI thread. Layout engines for browsers do get parallelized though. And the point of modern 3D APIs like Vulkan APIs is precisely to allow calling it from more than one thread.