4 ms·

It depends... On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. The only reasonable option

It depends... On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.

deleted 6y ago
[deleted]
freeone3000 6y ago
-j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.
- c-smile 6y ago
  I know how to tackle such problems. My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful. And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
  - chrisseaton 6y ago
    I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem. Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
  - freeone3000 6y ago
    It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.
hedora 6y ago
If make -j4 makes your UI unresponsive, it is probably due to swapping. The CPU scheduler lowers the priority of CPU intensive tasks over time. It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)
gruez 6y ago
>On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. Have you tried using nice(1) to set the make's priority lower?

deleted 6y ago

[deleted]

freeone3000 6y ago

-j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.

c-smile 6y ago
I know how to tackle such problems. My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful. And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
- chrisseaton 6y ago
  I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem. Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
- freeone3000 6y ago
  It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.

hedora 6y ago

If make -j4 makes your UI unresponsive, it is probably due to swapping. The CPU scheduler lowers the priority of CPU intensive tasks over time. It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)

gruez 6y ago

>On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. Have you tried using nice(1) to set the make's priority lower?