tag:blogger.com,1999:blog-8231772264325864647.post5151954446324026563..comments2024-03-22T19:05:00.088+01:00Comments on Concurrency Freaks: Concurrency Pattern: Distributed Cache-Line CounterPedro Ramalhetehttp://www.blogger.com/profile/01340437958052998917noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-8231772264325864647.post-44118501601532146792014-01-10T11:07:46.842+01:002014-01-10T11:07:46.842+01:00Hi Neo.X,
Thanks for pointing this out! I had fixe...Hi Neo.X,<br />Thanks for pointing this out! I had fixed it a long time ago in the code, but completely forgot to edit the post<br />https://sourceforge.net/projects/ccfreaks/files/java/src/com/concurrencyfreaks/counter/DistributedCacheLineCounter.java<br /><br />If it weren't for you paying attention, we could have had this bug here for a long time. Thanks for finding it!Pedro Ramalhetehttps://www.blogger.com/profile/01340437958052998917noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-78492585258271152652014-01-09T23:59:43.189+01:002014-01-09T23:59:43.189+01:00Nice article but there is a bug I think:
in get():...Nice article but there is a bug I think:<br />in get():<br />for (int idx = 0; idx < kNumCounters; idx += COUNTER_CACHE_LINE) {<br /> sum += counters.get(idx);<br /> }<br /><br />should be <br />for (int idx = 0; idx < kNumCounters; idx++) {<br /> sum += counters.get(idx * kNumCounters);<br /> }<br /><br />same thing in clear()NEo.Xhttps://www.blogger.com/profile/14838477925031605104noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-32079617758947036752013-09-16T16:22:25.460+02:002013-09-16T16:22:25.460+02:00You were right it was due to false sharing, after ...You were right it was due to false sharing, after i added another implementation of padded counter and performance was in expected range after that.<br />Thanks.Ashkrithttps://www.blogger.com/profile/09218886398665853347noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-79856559857842567172013-09-13T20:15:53.286+02:002013-09-13T20:15:53.286+02:00correction: (...) each 16 entries share the same c...correction: (...) each 16 entries share the same cache line (...)Pedro Ramalhetehttps://www.blogger.com/profile/01340437958052998917noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-51885512988175353752013-09-13T19:24:34.246+02:002013-09-13T19:24:34.246+02:00Hi Ashkrit,
I looked at the source code you have o...Hi Ashkrit,<br />I looked at the source code you have on github and it seems to me, that the reason they all have the same performance is because all those implementations are suffering from "false sharing". Adjacent entries in the atomicArray variable of your CoreBaseCounter are usually sharing a cache line, where each 8 entries share the same cache line.<br />In addition, some of the big differences in performance are only noticeable when you go up to a large number of cores. <br />Even so, after you fix the false-sharing issue, try running with all threads doing only increment() to see how many ops you get more. On my Core i7 I see 65k ops/ms for an AtomicLong and 113k ops/ms for the DCLC when running with 4 threads.<br /><br />Btw, I've heard Doug Lea mention a couple of times that even adding "padding" on an array may not be enough to avoid false sharing. The only sure way is to use @java.sun.misc.Contended<br /><br />CheersPedro Ramalhetehttps://www.blogger.com/profile/01340437958052998917noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-61745073534992737962013-09-13T18:54:37.695+02:002013-09-13T18:54:37.695+02:00Thanks for sharing your result. I also did quick p...Thanks for sharing your result. I also did quick prototype for scalable counters inspired by your blog.<br /><br />http://ashkrit.blogspot.sg/2013/09/scalable-counters-for-multi-core.html<br /><br />Do you have access to XEON processor based desktop ?<br />Result of my test on Xeon is very surprising, on Xeon performance of all the counters is almost same, all through there is CAS failure for Atomic Long.<br />On XEON CAS failure does't make any difference in over all timing.<br />Later i will use some of the back of strategy mention by dave dice in his blog for counter and test it on XEON.<br />Ashkrithttps://www.blogger.com/profile/09218886398665853347noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-73449491482967649882013-09-11T10:55:43.050+02:002013-09-11T10:55:43.050+02:00Here is the link
http://concurrencyfreaks.blogspot...Here is the link<br />http://concurrencyfreaks.blogspot.co.uk/2013/09/longadder-and-dclc.html<br />Pedro Ramalhetehttps://www.blogger.com/profile/01340437958052998917noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-41420101798099927892013-09-07T22:51:35.864+02:002013-09-07T22:51:35.864+02:00Hi Ashkrit,
The tid2hash() is just a "randomi...Hi Ashkrit,<br />The tid2hash() is just a "randomizer" based on George Marsalia's algorithm: http://www.javamex.com/tutorials/random_numbers/xorshift.shtml<br /><br />No, I haven't compared with LongAdder... in fact, I didn't even know about it until I saw your comment ;)<br />I'll re-run the microbenchmark with LongAdder and post the results soon.<br />ThanksPedro Ramalhetehttps://www.blogger.com/profile/01340437958052998917noreply@blogger.comtag:blogger.com,1999:blog-8231772264325864647.post-70614541221743262632013-09-07T19:12:09.531+02:002013-09-07T19:12:09.531+02:00Very interesting blog, can you pls explain bit abo...Very interesting blog, can you pls explain bit about your magical tid2hash function ?<br />Did you benchmark it against LongAdder which is using Striped64 ? Ashkrithttps://www.blogger.com/profile/09218886398665853347noreply@blogger.com