On 17/10/16 06:55, Daniel Kozak via Digitalmars-d-learn wrote: > Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a): > >> My question now is, why is each mutex based thread safe variant so slow >> compared to a similar java program? The only hint could be something >> like: >> https://blogs.oracle.com/dave/entry/java_util_concurrent_reentrantlock_vs >> that >> mentions, that there is some magic going on underneath. >> For the atomic and the non thread safe variant, the d solution seems to >> be twice as fast as my java program, for the locked variant, the java >> program seems to be 40 times faster? >> >> btw. I run the code with dub run --build=release >> >> Thanks in advance, >> Christian > Can you post your timings (both D and Java)? And can you post your java > code? Hi,
thanks for asking. I attached my java and d sources.
Both try to do more or less the same thing. They spawn 100 threads, that
call increment on a counter object 10000 times. The implementation of
the counter object is exchanged, between a obviously broken thread
unsafe implementation, some with atomic operations, some with
mutex-implementations.
to run java call ./gradlew clean build
->
counter.AtomicIntCounter@25992ae3 expected: 2000000 got: 1000000 in: 22ms
counter.AtomicLongCounter@2539f946 expected: 2000000 got: 1000000 in: 17ms
counter.ThreadSafe2Counter@527d56c2 expected: 2000000 got: 1000000 in: 33ms
counter.ThreadSafe1Counter@6fd8b1a expected: 2000000 got: 1000000 in: 173ms
counter.ThreadUnsafeCounter@6bb33878 expected: 2000000 got: 562858 in: 10ms
obviously the unsafe implementation is fastest, followed by atomics.
the vrsion with reentrant locks performs very well, wheras the
implementation with synchronized is the slowest.
to run d call dub test (please mark, that the dub test build is
configured like this:
buildType "unittest" {
buildOptions "releaseMode" "optimize" "inline" "unittests" "debugInfo"
}
, it should be release code speed and quality).
->
app.AtomicCounter: got: 1000000 expected: 1000000 in 23 ms, 852 μs, and
6 hnsecs
app.ThreadSafe1Counter: got: 1000000 expected: 1000000 in 3 secs, 673
ms, 232 μs, and 6 hnsecs
app.ThreadSafe2Counter: got: 1000000 expected: 1000000 in 3 secs, 684
ms, 416 μs, and 2 hnsecs
app.ThreadUnsafeCounter: got: 690073 expected: 1000000 in 8 ms and 540 μs
from example got: 3 secs, 806 ms, and 258 μs
here again, the unsafe implemenation is the fastest,
atomic performs in the same ballpark as java
only the thread safe variants are far off.
thanks for looking into this,
best regards,
christian
threads.tar.gz
Description: GNU Zip compressed data
