5 ms·

I've been running a ThreadRipper 1950X in my main box for the past 15 months or so and am generally extremely pleased with the results. However, my biggest take

I've been running a ThreadRipper 1950X in my main box for the past 15 months or so and am generally extremely pleased with the results. However, my biggest takeaway from the experience of having 32 cores has been that an embarrassingly large amount of the software I use on a daily basis for productivity runs in a single thread. My expectation was that UI blocking would be rare- it isn't, particularly with Chrome, Firefox, and Slack. Jira in the browser is terrible- even with insane resources and 1Gbps bandwidth I regularly have to wait 10-15 seconds to be able to enter text.

zozbot123 8y ago
> an embarrassingly large amount of the software I use on a daily basis for productivity runs in a single thread. My expectation was that UI blocking would be rare- it isn't, particularly with Chrome, Firefox, and Slack. Jira in the browser is terrible- even with insane resources and 1Gbps bandwidth I regularly have to wait 10-15 seconds to be able to enter text. Why would you expect anything different when JS _does_ run in a single thread? We'll have to wait for WebAssembly to have anything like real multithreading, with good-enough performance, on the Web.
- blattimwind 8y ago
  > Why would you expect anything different when JS _does_ run in a single thread? No reason for site A rendering to block site B; no reason for either to block the main UI. No reason for an issue tracker to take 10 seconds to achieve interactivity on LAN (heck, I'd consider 0.5 seconds slow).
- wongarsu 8y ago
  Not just in a single thread, in the same thread as DOM rendering. It's conceptually impossible to use a website in the time the javascript executes (except for webworkers etc). Still, javascript issues tend to cause too many hangups of other parts (browser UI or other websites). We are in the awkward position where OS threads are considered too heavyweight to use an entire thread for each tab, but browsers haven't implemented a more lightweight alternative either. So things just share threads when they really shouldn't.
  - pythonaut_16 8y ago
    Browser green threads could be amazing! Specifically an Erlang/Elixir-ish actor async implementation
  - the8472 8y ago
    layout and rendering can happen asynchronously in background threads, but you have to carefully structure your JS code to not read back layout properties any time soon after modifying the dom, otherwise it will block and turn everything back into sequential execution
vbezhenar 8y ago
UI lock-ups are because of thread locks, not because you don't have enough cores. Actually I could load all my 4 cores at 100% with some task and PC would be very responsive, it's really hard to notice a difference in most tasks. So yeah, 32 cores are nice when you have work for those cores, but it's not magic. Frequency is magic :)
moondev 8y ago
I have a 8/16 Ryzen with 64GB of memory and most of it sat idle for me as well. I ended up installing ESXi on the machine, and passing through my video card, usb and nvme to the windows vm. It works great. I then use the spare compute for running vSphere
brokenmachine 8y ago
That's why I went with a i7-8700k for my desktop which was at the time the fastest single thread performance (except i7-8086k which was IMO too much money for a tiny bit faster). It has 6 physical cores (12 virtual) which I think is enough for almost all workloads. No complaints. They've now been superseded by the i9-9700k and i9-9900k which each have 8 physical cores and are slightly faster per single threads. https://www.cpubenchmark.net/singleThread.html https://www.cpubenchmark.net/singleThread.html Software is nowhere near making use of all those threads under most circumstances IMO. Cue all the people saying how they couldn't live without their 32 threads...
- sangnoir 8y ago
  > Cue all the people saying how they couldn't live without their 32 threads I can live without 24 threads, but I love not having my computer become unusable because I'm encoding video or doing some other CPU-heavy task. having more than 4 threads has opened a whole new world of thinking of how to parallelize common tasks - not ever having to wait for your computer feels like a super-power. Paradoxically, this has freed me up to use an ARM chromebook for day-to-day usage - when I need firepower, I remote into the TR workstation (smartplug + boot on power BIOS + dynamic DNS) I'll never stop feeling a little exhilaration from typing "make -j 22"

zozbot123 8y ago

> an embarrassingly large amount of the software I use on a daily basis for productivity runs in a single thread. My expectation was that UI blocking would be rare- it isn't, particularly with Chrome, Firefox, and Slack. Jira in the browser is terrible- even with insane resources and 1Gbps bandwidth I regularly have to wait 10-15 seconds to be able to enter text. Why would you expect anything different when JS _does_ run in a single thread? We'll have to wait for WebAssembly to have anything like real multithreading, with good-enough performance, on the Web.

blattimwind 8y ago
> Why would you expect anything different when JS _does_ run in a single thread? No reason for site A rendering to block site B; no reason for either to block the main UI. No reason for an issue tracker to take 10 seconds to achieve interactivity on LAN (heck, I'd consider 0.5 seconds slow).
wongarsu 8y ago
Not just in a single thread, in the same thread as DOM rendering. It's conceptually impossible to use a website in the time the javascript executes (except for webworkers etc). Still, javascript issues tend to cause too many hangups of other parts (browser UI or other websites). We are in the awkward position where OS threads are considered too heavyweight to use an entire thread for each tab, but browsers haven't implemented a more lightweight alternative either. So things just share threads when they really shouldn't.
- pythonaut_16 8y ago
  Browser green threads could be amazing! Specifically an Erlang/Elixir-ish actor async implementation
- the8472 8y ago
  layout and rendering can happen asynchronously in background threads, but you have to carefully structure your JS code to not read back layout properties any time soon after modifying the dom, otherwise it will block and turn everything back into sequential execution

vbezhenar 8y ago

UI lock-ups are because of thread locks, not because you don't have enough cores. Actually I could load all my 4 cores at 100% with some task and PC would be very responsive, it's really hard to notice a difference in most tasks. So yeah, 32 cores are nice when you have work for those cores, but it's not magic. Frequency is magic :)

moondev 8y ago

I have a 8/16 Ryzen with 64GB of memory and most of it sat idle for me as well. I ended up installing ESXi on the machine, and passing through my video card, usb and nvme to the windows vm. It works great. I then use the spare compute for running vSphere

brokenmachine 8y ago

That's why I went with a i7-8700k for my desktop which was at the time the fastest single thread performance (except i7-8086k which was IMO too much money for a tiny bit faster). It has 6 physical cores (12 virtual) which I think is enough for almost all workloads. No complaints. They've now been superseded by the i9-9700k and i9-9900k which each have 8 physical cores and are slightly faster per single threads. https://www.cpubenchmark.net/singleThread.html https://www.cpubenchmark.net/singleThread.html Software is nowhere near making use of all those threads under most circumstances IMO. Cue all the people saying how they couldn't live without their 32 threads...

sangnoir 8y ago
> Cue all the people saying how they couldn't live without their 32 threads I can live without 24 threads, but I love not having my computer become unusable because I'm encoding video or doing some other CPU-heavy task. having more than 4 threads has opened a whole new world of thinking of how to parallelize common tasks - not ever having to wait for your computer feels like a super-power. Paradoxically, this has freed me up to use an ARM chromebook for day-to-day usage - when I need firepower, I remote into the TR workstation (smartplug + boot on power BIOS + dynamic DNS) I'll never stop feeling a little exhilaration from typing "make -j 22"