Speed of synchronized

[Christian Köstlin via Digitalmars-d-learn]

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 at 25992ae3 expected: 2000000 got: 1000000 in: 22ms
counter.AtomicLongCounter at 2539f946 expected: 2000000 got: 1000000 in: 17ms
counter.ThreadSafe2Counter at 527d56c2 expected: 2000000 got: 1000000 in: 33ms
counter.ThreadSafe1Counter at 6fd8b1a expected: 2000000 got: 1000000 in: 173ms
counter.ThreadUnsafeCounter at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: threads.tar.gz
Type: application/x-gzip
Size: 7108 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20161017/0a304c41/attachment-0001.bin>