Re: Java UI performance WSL vs Windows
Hi, On Tue, Jul 7, 2020 at 10:15 AM va...@lem-one.nl wrote: > > Hi, > > I recently got involved to get an existing Java Swing UI to perform better. I > have incrementally been making minor changes till now and getting > improvements. > Since we are mostly developing on Linux/OSx boxes we were already aware that > there is a significant difference in performance between these, where Windows > would be least responsive. > At some point we decided to run a crazy experiment and just run our Java UI > on WSL (Ubuntu), on a Windows machine side by side with the same Java UI on > plain Windows. > It turns out that the WSL UI outperforms the Windows UI by miles. > > I want to start digging into details as soon as I have time but I was > wondering if someone has any intuition on what's going on here. I would not > expect a performance gain by adding an extra level of indirection. Make sure the Java2D rendering pipeline you are using is the same across tests. OpenJDK is based on Marlin (https://openjdk.java.net/jeps/265), but Oracle's JDK may be different, and same for other vendors. See also: https://www.azul.com/blog/performance-rendered-visual/ -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ37nzKV7Dfjjwj5ZET3D1wQqPAwb_MO1iS%3DzDANX4jDNg%40mail.gmail.com.
Re: Volatile semantic for failed/noop atomic operations
Hi, On Sun, Sep 15, 2019 at 2:24 AM Vitaly Davidovich wrote: > In your snippet, terminate() sets the field - it can be visible immediately > (or terminate() thread is descheduled). decrement runs, decrements to 0, > sees action != null. terminate() also now sees 0, and likewise proceeds to > run the action. > > The AR I was suggesting would allow ownership protocol over the action. Read > it, if not null, try to CAS a null in there. If CAS succeeds, you’ve claimed > ownership. If it fails, someone else claimed it. Whoever claims it runs the > action. I see, thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ1o9FM0wbNm5TWk_wzR59RCevgBxoM9%3D4L%3DEtO3VmtSFw%40mail.gmail.com.
Re: Volatile semantic for failed/noop atomic operations
Hi, On Sat, Sep 14, 2019 at 8:28 PM Vitaly Davidovich wrote: > > Unlike C++, where you can specify mem ordering for failure and success > separately, Java doesn’t allow that. But, the mem ordering is the same for > failure/success there. Unfortunately it doesn’t look like the javadocs > mention that, Unfortunately so. > but I recall Doug Lea saying that’s the case on the concurrency-interest > mailing list (btw that’s probably the more appropriate channel for this > Java-centric question). > > For your case, it seems like an AtomicReference is more appropriate. But then I would have 2 volatile accesses instead of one. > terminate() sets it, then checks the count via a volatile load (or maybe it > can decrement() itself?); if zero, CAS null into the action field to > take/claim the action. decrement() likewise tries to claim the action via a > CAS. The snippet you have now would allow for concurrent action execution, > which is likely unsafe/wrong. I don't see the difference between 2 atomics and my snippet WRT concurrent execution. They can both be executed concurrently with arbitrary interleaving, no? I think my snippet is safe as long as in terminate() there is a volatile write after setting the action (it is admittedly weird to add zero just to obtain a memory effect, I could have used VarHandle.releaseFence() if I were in JDK 11), since the action would be visible from decrement() because it does a volatile read on the same variable, no? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ0gh54BKzEQcbTAyb%3DRpa41c8mpiQSGVc5xsYno-qbzVw%40mail.gmail.com.
Volatile semantic for failed/noop atomic operations
Hi,
I have an atomic counter that gets incremented and decremented over
time (non monotonically).
At a certain point, I would like to enter a termination protocol where
increments are not possible anymore and I set an action to run if/when
the counter reaches zero.
Trivial when using synchronized/lock, but I'd like to give it a try
without them.
class A {
private final AtomicLong counter;
// Non-volatile
private Runnable action;
void terminate(Runnable action) {
this.action = action;
// Volatile write needed here for visibility.
if (counter.addAndGet(0) == 0) {
action.run();
}
}
void decrement() {
// Volatile read required to see this.action.
if (counter.decrementAndGet() == 0) {
Runnable a = this.action;
if (a != null) {
a.run()
}
}
}
}
Is addAndGet(0) a volatile write? Can the write be optimized away?
Similarly (although not relevant for this particular example), a
_failed_ compareAndSet() has the semantic of a volatile write even if
the set part was not done because the compare part failed?
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ3qGJ_qqrXmAHNDZ6ro01BQwe8czHZP7b-SoZ%2BrULhJAw%40mail.gmail.com.
Re: Question about SBE and DirectBuffer
Hi, On Tue, Sep 27, 2016 at 2:36 AM, Wayne wrote: > Hi Simone, > > I made the ThreadLocal initialValue() method synchronized and the problem > appears to go away so far. That's weird ! > I am doing more test before opening the issue in > Agrona. Ok, we are also trying to replicate. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Question about SBE and DirectBuffer
Hi, On Sat, Sep 24, 2016 at 7:42 PM, Wayne wrote: > Thanks, Todd. I will open an issue there. So you don't think java > ByteBuffer.allocateDirect() is the potential problem? Has the issue been opened, as I'd like to follow the discussion ? Coincidentally, we have seen similar buffer corruptions in Jetty, but could not pinpoint yet the cause. Would be interesting to figure out if it's a JVM issue. What JVM version are you using ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
