Trivial patch for (sometimes) faster STM
176 views
Skip to first unread message
Stefan Kamphausen
Sep 9, 2011, 4:51:00 AM9/9/11
to clo...@googlegroups.com
TL;DR: There is small patch which improves speed of STM
Hi,
in the light of the upcoming 1.3 you might be interested in a rather trivial patch which can lead to significant speedup of STM processing.
1. Background
I was studying the implementation of STM for a talk at this year's SourceTalk [1] and thus became a little bit familiar with the inner workings. By accident I stumbled upon a note saying that System.currentTimeMillis() can be slow.
This is used in CLojure's implementation of STM in Ref.java and LockingTransaction.java. As far as I understand those files, the information is written but never used. It may be a relict of older days when the implementation was based upon time instead of an AtomicLong.
2. Description of patch
It just removes the field msecs from TVal and adjusts all constructors accordingly.
3. Description of test
I wrote a small benchmarking/testing suite [2] which uses the example from clojure.org/refs, some self-written tests and one inspired by [3]. Some of these functions also make sure that they don't encounter an invalid state in the refs used.
4. Results and Patch
I tried it on two machines. The slower laptop with Java 1.6.0.21 always ends up about 20-25% faster with the patch. The desktop however, which is faster and has a newer Java, has a wider range of results with speedups between 0-20%. I can only assume that the newer Java detects the unused field and optimizes it away or that the tests should be run with more repetitions or higher counts in each test.
The details test results and the patch can be found on [4].
5. CA
CA was sent last week and should arrive shortly. (I wanted to post this to clojure-dev originally and waited for membership over there, but a gentle push by Christopher made write this post.)
Kind regards,
Stefan
[1] www.sourcetalk.de (German)
[2] https://github.com/ska2342/clj-stm-perf-test/
[3] http://vbn.aau.dk/files/32587755/report.pdf
[4] http://www.skamphausen.de/stm/
Hi,
in the light of the upcoming 1.3 you might be interested in a rather trivial patch which can lead to significant speedup of STM processing.
1. Background
I was studying the implementation of STM for a talk at this year's SourceTalk [1] and thus became a little bit familiar with the inner workings. By accident I stumbled upon a note saying that System.currentTimeMillis() can be slow.
This is used in CLojure's implementation of STM in Ref.java and LockingTransaction.java. As far as I understand those files, the information is written but never used. It may be a relict of older days when the implementation was based upon time instead of an AtomicLong.
2. Description of patch
It just removes the field msecs from TVal and adjusts all constructors accordingly.
3. Description of test
I wrote a small benchmarking/testing suite [2] which uses the example from clojure.org/refs, some self-written tests and one inspired by [3]. Some of these functions also make sure that they don't encounter an invalid state in the refs used.
4. Results and Patch
I tried it on two machines. The slower laptop with Java 1.6.0.21 always ends up about 20-25% faster with the patch. The desktop however, which is faster and has a newer Java, has a wider range of results with speedups between 0-20%. I can only assume that the newer Java detects the unused field and optimizes it away or that the tests should be run with more repetitions or higher counts in each test.
The details test results and the patch can be found on [4].
5. CA
CA was sent last week and should arrive shortly. (I wanted to post this to clojure-dev originally and waited for membership over there, but a gentle push by Christopher made write this post.)
Kind regards,
Stefan
[1] www.sourcetalk.de (German)
[2] https://github.com/ska2342/clj-stm-perf-test/
[3] http://vbn.aau.dk/files/32587755/report.pdf
[4] http://www.skamphausen.de/stm/
Stefan Kamphausen
Sep 9, 2011, 5:34:52 AM9/9/11
to clo...@googlegroups.com
FWIW I just could run the test-suite on a quad-core VMWare which lead to 12-15% speed-up. (No detailed report available)
Reply all
Reply to author
Forward
0 new messages