| ▲ | timschmidt a day ago | ||||||||||||||||
> Now make that multi-threaded code exhaust a 32 core desktop system Switching an iter to par_iter does this. So long as there are enough iterations to work through, it'll exhaust 1024 cores or more. > all the time, not only at peak execution. What are you doing that keeps a desktop or phone at 100% utilization? That kind of workload exists in datacenters, but end user devices are inherently bursty. Idle when not in use, race to idle while in use. > As brownie points, keep the GPU busy as well... Even more points if the CPU happens to have a NPU or integrated FPGA In a recent project I serve a WASM binary from an ESP32 via Wifi / HTTP, which makes use of the GPU via WebGL to draw the GUI, perform CSG, calculate toolpaths, and drip feed motion control commands back to the ESP. This took about 12k lines of Rust including the multithreaded CAD library I wrote for the project, only a couple hundred lines of which are gated behind the "parallel" feature flag. It was way less work than the inferior C++ version I wrote as part of the RepRap project 20 years ago. Hence my stance that software has become increasingly sophisticated. https://github.com/timschmidt/alumina-firmware https://github.com/timschmidt/alumina-ui https://github.com/timschmidt/csgrs What's your point? | |||||||||||||||||
| ▲ | pjmlp a day ago | parent [-] | ||||||||||||||||
The point being those are very niche cases that still don't keep the hardware busy as it should 24h around the clock. Most consumer software even less, hence why anyone will hardly see a computer on the shopping mall with higher than 16 core count, and on average most shops will have something between 4 and 8. Also a reason why systems with built-in FPGAs failed in the consumer market, specialised tools without consumer software to help sell them. | |||||||||||||||||
| |||||||||||||||||