4 ms·

Artificial benchmarks show a 4% improvement in some cases, which is huge. There aren't many tests to demonstrate the improvements on common use cases but there

Artificial benchmarks show a 4% improvement in some cases, which is huge. There aren't many tests to demonstrate the improvements on common use cases but there are already reports of subjective improvements with games having less stutter: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1253763-updated-futex2-system-call-patches-posted-for-helping-wine-proton-other-use-cases?p=1253803#post1253803 https://www.phoronix.com/forums/forum/phoronix/latest-phoron...

savant_penguin 6y ago
Really curious, why is 4% improvement huge?
- k1rcher 6y ago
  This is interesting. Does anyone know of previous figures on Windows virtualization improvement?
  - delroth 6y ago
    It's not 4% improvement for the wine use case, it's 4% improvement in existing synthetic benchmarks for the futex syscall. And a 21% regression in performance in another synthetic benchmark. It's likely the wine WMO implementation is getting a much more significant increase in performance than 4%, but the patch description doesn't provide numbers.
- deleted 6y ago
  [deleted]
- marcodiego 6y ago
  Because you don't have to change one line of your previously running software to get this benefit or replace your hardware. Of course, will need a new version of the kernel and wine, but that is a matter of time to hit distro repositories. Also, consider that this will accumulate when combined with new user space libs, servers, compilers, drivers... Software will improve without any change just by keeping your distro updated. Yes, a 4% improvement is huge.
- sp332 6y ago
  Well, it's a relative measure. There's been a ton of optimization already. All the low-hanging fruit is gone. It's probably been a long time since a single optimization gained 4%.
- tombert 6y ago
  I don't know much about Wine, but I'm speaking in generalities, but I've worked jobs where we spend weeks to get <10% performance increases. Very often that last bit of optimization is the hardest part.
- chalst 6y ago
  "Huge" means different things in different contexts. A compiler optimisation that delivered a 4% increase in speed for a whole class of well-tuned C programs would be regarded as huge by people who follow compiler technology, but would not strike most users of computers as a big deal. I take it "huge" is meant in this sense of extraordinary within a class of potential improvements. If you can accumulate a series of 4% improvements, then even the computer consumer will start to see the significance.
  - jhgb 6y ago
    A 4% improvement of the 100m dash world record would have been considered phenomenal, I imagine.
    - alexeldeib 6y ago
      This reminded me of the 4 minute mile. The first 4 minute mile was a 3:59 run by Roger Bannister in 1954. Prior to that, the record was a 4:01 run in 1945. A 4% improvement on the 4:01 would be a 3:51. A 3:51 wasn't achieved until 1966, about 20 years later. So 4% can be quite a jump!
      - dbpatterson 6y ago
        Extending your point, 4% more would go down to just under 3:42.... which has not yet happened, over a half century later.
    - zimpenfish 6y ago
      To put that into context, Bolt's 9.58s (current WR, considered phenomenal in and of itself, I think?) is about 1.7% faster than Powell's 9.74s (last pre-Bolt WR). A 4% improvement on Bolt's 9.58s would be about 9.19s - probably not something we'll see for several decades, if ever.
      - jamiek88 6y ago
        I wonder if I’ll ever see a Bolt again in my lifetime. Such dominance and grace. He jogged over the line with that record too.
- fefe23 6y ago
  Intel Xeons have huge price differences at the top tier for relatively minor performance differences. So if you get 4% for free here, that could mean hundreds of dollars savings compared to having to buy the next tier hardware. Multiplied by the number of Intel customers. 4% could mean the difference between "I can still use my old computer" and "I need to buy an upgrade".
  - ltbarcly3 6y ago
    The price difference is due to artificial market segmentation, for example only xeons support ecc. It is not due to performance. (consumer chips are usually basically identical, just with functionality disabled)
phkahler 6y ago
- For requeue, I measured an average of 21% decrease in performance compared to the original futex implementation. This is expected given the new design with individual flags. The performance trade-offs are explained at patch 4 ("futex2: Implement requeue operation"). It's not clear that this is a win overall. But hey, if Windows games run better under wine...
- derefr 6y ago
  Better yet, since Wine is there to serve as a “smart” shim, it can offer a launch config parameter for the app, that will get Wine to point its futex symbols at its previous userland impl. (Sort of like the various Windows compatibility-mode flags.) So even Windows apps that do tons of requeues (and so presumably would be slowed down by unilaterally being made to do kernel futexes) would be able to be tuned back up to speed. And distros of Wine that provide pre-tuned installer scripts for various apps, like CrossOver, can add that flag to their scripts, so users don’t even have to know.
  - deleted 6y ago
    [deleted]
- gpderetta 6y ago
  IIRC glibc stopped using requeue a while ago for cobdution variables wait morphing, so maybe requeue is not a hugely important use case anymore.
- Denvercoder9 6y ago
  The old interface will remain available, so if requeue performance is important, you can keep using that. Also at least one kernel maintainer considers requeue to be historical ballast [1], so it's probably not used much anymore. [1] https://lwn.net/ml/linux-kernel/87o8thg031.fsf@nanos.tec.linutronix.de/ https://lwn.net/ml/linux-kernel/87o8thg031.fsf@nanos.tec.lin...
xxs 6y ago
> 4% performance improvement for up to 800 threads. 800 threads on similar WaitForMultipleObject is already a horrific design if you even remotely care about performance. The only viable case for 800 threads (and wine) would be blocking IO which is an extremely boring one.
- usefulcat 6y ago
  Sure, but that's irrelevant for wine, which doesn't get to choose how the things that it's running (e.g. games) are implemented.
  - xxs 6y ago
    Of course. Yet, I am be massively surprised to see so heavily multithreaded games with massive contention on WaitForMultipleObjects. No one programs that way (again, save for blocking IO... and then it totally doesn't matter)
    - monocasa 6y ago
      Unfortunately, people do program that way, and I've seen it way more in closed source Windows code than in the open source world where someone will (rightly) call them out. For instance, in a previous job, a C++ codebase existed where the architect had horrendously misunderstood the actor model and had instated a "all classes must extend company::Thread" rule in the coding standard. So close, yet so incredibly far away. At the end of the day, wine (like windows) still has to run these programs and do it's best with terrible choices that were made in the past.
      - xxs 6y ago
        Having a policy to have to extend something is proper bad already. For actors likely you need lock-free queue and much preferably a bounded one - so each message is a CAS (very likely uncontended) and there is an upper limit how much stuff can be enqueued. I do believe there are tons of incredible horrid code (esp. when it comes to concurrency) - but most games tend to use already established engines, less likely to have glaring concurrency design blunders.

savant_penguin 6y ago

Really curious, why is 4% improvement huge?

k1rcher 6y ago
This is interesting. Does anyone know of previous figures on Windows virtualization improvement?
- delroth 6y ago
  It's not 4% improvement for the wine use case, it's 4% improvement in existing synthetic benchmarks for the futex syscall. And a 21% regression in performance in another synthetic benchmark. It's likely the wine WMO implementation is getting a much more significant increase in performance than 4%, but the patch description doesn't provide numbers.
deleted 6y ago
[deleted]
marcodiego 6y ago
Because you don't have to change one line of your previously running software to get this benefit or replace your hardware. Of course, will need a new version of the kernel and wine, but that is a matter of time to hit distro repositories. Also, consider that this will accumulate when combined with new user space libs, servers, compilers, drivers... Software will improve without any change just by keeping your distro updated. Yes, a 4% improvement is huge.
sp332 6y ago
Well, it's a relative measure. There's been a ton of optimization already. All the low-hanging fruit is gone. It's probably been a long time since a single optimization gained 4%.
tombert 6y ago
I don't know much about Wine, but I'm speaking in generalities, but I've worked jobs where we spend weeks to get <10% performance increases. Very often that last bit of optimization is the hardest part.
chalst 6y ago
"Huge" means different things in different contexts. A compiler optimisation that delivered a 4% increase in speed for a whole class of well-tuned C programs would be regarded as huge by people who follow compiler technology, but would not strike most users of computers as a big deal. I take it "huge" is meant in this sense of extraordinary within a class of potential improvements. If you can accumulate a series of 4% improvements, then even the computer consumer will start to see the significance.
- jhgb 6y ago
  A 4% improvement of the 100m dash world record would have been considered phenomenal, I imagine.
  - alexeldeib 6y ago
    This reminded me of the 4 minute mile. The first 4 minute mile was a 3:59 run by Roger Bannister in 1954. Prior to that, the record was a 4:01 run in 1945. A 4% improvement on the 4:01 would be a 3:51. A 3:51 wasn't achieved until 1966, about 20 years later. So 4% can be quite a jump!
    - dbpatterson 6y ago
      Extending your point, 4% more would go down to just under 3:42.... which has not yet happened, over a half century later.
  - zimpenfish 6y ago
    To put that into context, Bolt's 9.58s (current WR, considered phenomenal in and of itself, I think?) is about 1.7% faster than Powell's 9.74s (last pre-Bolt WR). A 4% improvement on Bolt's 9.58s would be about 9.19s - probably not something we'll see for several decades, if ever.
    - jamiek88 6y ago
      I wonder if I’ll ever see a Bolt again in my lifetime. Such dominance and grace. He jogged over the line with that record too.
fefe23 6y ago
Intel Xeons have huge price differences at the top tier for relatively minor performance differences. So if you get 4% for free here, that could mean hundreds of dollars savings compared to having to buy the next tier hardware. Multiplied by the number of Intel customers. 4% could mean the difference between "I can still use my old computer" and "I need to buy an upgrade".
- ltbarcly3 6y ago
  The price difference is due to artificial market segmentation, for example only xeons support ecc. It is not due to performance. (consumer chips are usually basically identical, just with functionality disabled)

phkahler 6y ago

- For requeue, I measured an average of 21% decrease in performance compared to the original futex implementation. This is expected given the new design with individual flags. The performance trade-offs are explained at patch 4 ("futex2: Implement requeue operation"). It's not clear that this is a win overall. But hey, if Windows games run better under wine...

derefr 6y ago
Better yet, since Wine is there to serve as a “smart” shim, it can offer a launch config parameter for the app, that will get Wine to point its futex symbols at its previous userland impl. (Sort of like the various Windows compatibility-mode flags.) So even Windows apps that do tons of requeues (and so presumably would be slowed down by unilaterally being made to do kernel futexes) would be able to be tuned back up to speed. And distros of Wine that provide pre-tuned installer scripts for various apps, like CrossOver, can add that flag to their scripts, so users don’t even have to know.
- deleted 6y ago
  [deleted]
gpderetta 6y ago
IIRC glibc stopped using requeue a while ago for cobdution variables wait morphing, so maybe requeue is not a hugely important use case anymore.
Denvercoder9 6y ago
The old interface will remain available, so if requeue performance is important, you can keep using that. Also at least one kernel maintainer considers requeue to be historical ballast [1], so it's probably not used much anymore. [1] https://lwn.net/ml/linux-kernel/87o8thg031.fsf@nanos.tec.linutronix.de/ https://lwn.net/ml/linux-kernel/87o8thg031.fsf@nanos.tec.lin...

xxs 6y ago

> 4% performance improvement for up to 800 threads. 800 threads on similar WaitForMultipleObject is already a horrific design if you even remotely care about performance. The only viable case for 800 threads (and wine) would be blocking IO which is an extremely boring one.

usefulcat 6y ago
Sure, but that's irrelevant for wine, which doesn't get to choose how the things that it's running (e.g. games) are implemented.
- xxs 6y ago
  Of course. Yet, I am be massively surprised to see so heavily multithreaded games with massive contention on WaitForMultipleObjects. No one programs that way (again, save for blocking IO... and then it totally doesn't matter)
  - monocasa 6y ago
    Unfortunately, people do program that way, and I've seen it way more in closed source Windows code than in the open source world where someone will (rightly) call them out. For instance, in a previous job, a C++ codebase existed where the architect had horrendously misunderstood the actor model and had instated a "all classes must extend company::Thread" rule in the coding standard. So close, yet so incredibly far away. At the end of the day, wine (like windows) still has to run these programs and do it's best with terrible choices that were made in the past.
    - xxs 6y ago
      Having a policy to have to extend something is proper bad already. For actors likely you need lock-free queue and much preferably a bounded one - so each message is a CAS (very likely uncontended) and there is an upper limit how much stuff can be enqueued. I do believe there are tons of incredible horrid code (esp. when it comes to concurrency) - but most games tend to use already established engines, less likely to have glaring concurrency design blunders.