4 ms·
Which is really weird. All the speedups they list seem like it would run faster in general. Maybe the extra responsiveness under heavy loads is slowing it down
by spicybright 5y ago
Which is really weird. All the speedups they list seem like it would run faster in general.
Maybe the extra responsiveness under heavy loads is slowing it down?
- retrac 5y ago> Maybe the extra responsiveness under heavy loads is slowing it down? Probably. It's a basic tradeoff in multitasking. A process can be left in cache and run for hundreds of milliseconds at high efficiency. Or the kernel can constantly juggle contexts in and out quickly, wasting cycles to reduce the delay between time slices and (potentially) allow fast response.
- sedatk 5y agoI don't understand how anything other than FPS matters in a gaming oriented distro. Does that mean less input lag?
- retrac 5y agoYes, exactly. Let's imagine you were running two processes on one core, a server and a video game. The way to achieve the highest /average/ frame rate regardless of latency would be to pause the game for a good second, run the server, pause the server, run the game for a second, and repeat. This has much lower overhead than swapping between them perhaps 100 times a second. Except it's super laggy. Swap them out 100 times a second and the process only has to wait maybe 10 ms until it next executes and appears much less laggy, but total throughput decreases.
- treffer 5y ago> Maybe the extra responsiveness under heavy loads is slowing it down? Yes! Extra responsiveness is done by switching more often between tasks. This is not free, so throughput suffers. The linux kernel lists that as the downside of e.g. 1000Hz ticks (something the Liquorix kernel enables).