3 ms·

Someone found some when this was previously posted: https://www.phoronix.com/scan.php?page=article&item=radeon-gaming-liquorix54&num=1 https://www.phoronix.com/

by cglong 5y ago

Someone found some when this was previously posted: https://www.phoronix.com/scan.php?page=article&item=radeon-gaming-liquorix54&num=1 https://www.phoronix.com/scan.php?page=article&item=radeon-g...

sedatk 5y ago
So, mostly slower than stock Linux 5.4.6? That's quite disappointing.
- damentz 5y ago
  For the most part, Liquorix should always lose on throughput benchmarks. Most of Phoronix's benchmarks focus on those. You can check the comments regarding a discovery that certain sched_yield configurations destroy performance on out-of-tree schedulers and was amended post benchmarking. This however was using MuQSS, which was notorious for poor single thread performance. Liquorix now uses PDS which attempts to use all physical cores before deferring to SMT threads. This completely changes performance for lightly threaded workloads. There's been no news-worthy benchmarks since Liquorix switched from MuQSS to PDS.
  - mise_en_place 5y ago
    Anecdotal, but I noticed a lot better browser performance when switching to no I/O scheduler, "none". I also noticed that Linux wasn't trying to use most of my RAM for buff/cache.
- 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 ago
      I don't understand how anything other than FPS matters in a gaming oriented distro. Does that mean less input lag?
      - retrac 5y ago
        Yes, 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).

by cglong 5y ago

Someone found some when this was previously posted: https://www.phoronix.com/scan.php?page=article&item=radeon-gaming-liquorix54&num=1 https://www.phoronix.com/scan.php?page=article&item=radeon-g...

sedatk 5y ago

So, mostly slower than stock Linux 5.4.6? That's quite disappointing.

damentz 5y ago
For the most part, Liquorix should always lose on throughput benchmarks. Most of Phoronix's benchmarks focus on those. You can check the comments regarding a discovery that certain sched_yield configurations destroy performance on out-of-tree schedulers and was amended post benchmarking. This however was using MuQSS, which was notorious for poor single thread performance. Liquorix now uses PDS which attempts to use all physical cores before deferring to SMT threads. This completely changes performance for lightly threaded workloads. There's been no news-worthy benchmarks since Liquorix switched from MuQSS to PDS.
- mise_en_place 5y ago
  Anecdotal, but I noticed a lot better browser performance when switching to no I/O scheduler, "none". I also noticed that Linux wasn't trying to use most of my RAM for buff/cache.
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 ago
    I don't understand how anything other than FPS matters in a gaming oriented distro. Does that mean less input lag?
    - retrac 5y ago
      Yes, 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).