Am Dienstag, 7. Januar 2014 13:40:50 UTC+1 schrieb √: > > > > > On Tue, Jan 7, 2014 at 1:32 PM, Rüdiger Möller <[email protected]<javascript:> > > wrote: > >> >> >> Am Dienstag, 7. Januar 2014 11:57:54 UTC+1 schrieb √: >> >>> You definitely want to play around with the configuration and make sure >>> that you are benchmarking correctly: https:// >>> stackoverflow.com/questions/504103/how-do-i-write-a- >>> correct-micro-benchmark-in-java >>> >>> >> I know the details regarding VM warmup and how to avoid in-place JIT'ing. >> I am iterating the bench 30 times, only take the average times of last 10 >> iterations (20 iterations warmup), see mainloop i added to the original >> AKKA sample. Also the benchmark is not in the nanos, but several hundred >> millis per iteration. >> > > There is no reason at all to use currentTimeMillis (it's got accuracy > problems (I've seen up to 20-30ms), just use nanoTime. >
There is reason. System time millis is based on global system time, nanos is guaranteed to be consistent within a single thread only. The "accuracy problems" usually occur if one compares System.currentTimeMillis obtained from within different threads. Since runtimes are in the range of up to >1000 ms, and the tests are run many times i can say for sure this is not the reason why akka seems to scale not-that-good. Some historical problems with huge inaccuracy of systimemillis were with windows XP. I am using CenOS 6.4, 64bit. > > >> >> >>> dispatcher throughput, thread pool type and thread pool size, and >>> mailbox type. >>> >> >> can you be more specific pls (Code!). The use case is many short running >> computations with contention created when aggregating the result. >> > > > https://github.com/viktorklang/scala-vs-erlang/blob/9a124c75c8034d9ba90baa2751f21c51f1e64ddc/scala/src/main/resources/application.conf > > >> >> >>> >>> Also, Opterons have pretty bad cache performance for inter-core comms >>> (Intel uses inclusive L3s for faster on-package caches) >>> >>> >> Well the other benches use the same hardware. >> I am currently repeating the test on a dual socket x 6 core intel xeon >> (so 12 cores, 24Hardware-Threads). With Akka still being worst one by far. >> > > Numbers? > Opteron scaling http://imgur.com/TAt9XOf <http://imgur.com/TAt9XOf> Intel: ========================================== 1m jobs each perform 100-pi-slice loop AKKA average 1 threads : 1914 average 2 threads : 970 average 3 threads : 1032 average 4 threads : 1099 average 5 threads : 1343 average 6 threads : 1336 average 7 threads : 1470 average 8 threads : 1543 average 9 threads : 1788 average 10 threads : 1500 average 11 threads : 1509 average 12 threads : 1454 synced Threading average 1 threads : 800 average 2 threads : 951 average 3 threads : 953 average 4 threads : 1087 average 5 threads : 1087 average 6 threads : 1041 average 7 threads : 1028 average 8 threads : 982 average 9 threads : 1046 average 10 threads : 1031 average 11 threads : 1038 average 12 threads : 1015 Abstraktor average 1 threads : 1349 average 2 threads : 674 average 3 threads : 477 average 4 threads : 380 average 5 threads : 323 average 6 threads : 302 average 7 threads : 321 average 8 threads : 329 average 9 threads : 354 average 10 threads : 369 average 11 threads : 386 average 12 threads : 385 ========================================== 100k jobs each perform 1000-pi-slice loop Abstractor average 1 threads : 738 average 2 threads : 364 average 3 threads : 246 average 4 threads : 183 average 5 threads : 148 average 6 threads : 124 average 7 threads : 105 average 8 threads : 94 average 9 threads : 87 average 10 threads : 79 average 11 threads : 92 average 12 threads : 104 synced Threading average 1 threads : 674 average 2 threads : 373 average 3 threads : 231 average 4 threads : 187 average 5 threads : 152 average 6 threads : 128 average 7 threads : 117 average 8 threads : 110 average 9 threads : 115 average 10 threads : 127 average 11 threads : 135 average 12 threads : 151 AKKA average 1 threads : 772 average 2 threads : 378 average 3 threads : 295 average 4 threads : 238 average 5 threads : 201 average 6 threads : 162 average 7 threads : 139 average 8 threads : 128 average 9 threads : 118 average 10 threads : 114 average 11 threads : 128 average 12 threads : 118 As you can see when reducing the number of messages (and increase duration of a single job), Akka performance increases. This indicates that Akka has pretty slow message passing/queuing (see also difference in single threaded run in the 1million messages case) implementation. The bad scaling behaviour (well, its at least in some cases better than sync'ed threads) indicate there is serious contention somewhere in the central dispatching loop. You can see in the 1m message examples, that Multithreading does not scale at all (due to contention), but still performs better than AKKA in this scenario. So basically a single threaded solution will be faster than multithreading and Akka. Only Abstractor improves up to 6 Threads, after that it also stalls due to contention. > (I also think we have to remain quite reasonable here, akka lets you scale > out your computation up to ~2500 Jvms. Does the other solutions offer that?) > Network connected VM's :-). The computation is just a placeholder for the use case of "high rates of small events" which is typical for many real time systems. Scaling frequently does not pay-off because network (+decoding/encoding) becomes the bottleneck. Scaling is not about saturating many CPU's but about getting more throughput ;-) > > Cheers, > √ > > >> >> >>> Cheers, >>> √ >>> >>> >>> On Tue, Jan 7, 2014 at 11:49 AM, Endre Varga <[email protected]>wrote: >>> >>>> Hi Rüdiger, >>>> >>>> Have you tried to play around with the throughput setting of the >>>> dispatcher? For these kind of non-interactive jobs fairness is not an >>>> issue, so you might most likely want to increase that value. >>>> >>>> -Endre >>>> >>>> >>>> On Tue, Jan 7, 2014 at 1:26 AM, Rüdiger Möller <[email protected]>wrote: >>>> >>>>> Please checkout chart here. >>>>> >>>>> https://plus.google.com/109956740682506252532/posts/1hKcYyPuJzh >>>>> >>>>> [cut&pasted from g+]: >>>>> Hey folks, i am currently writing a blog benchmarking akka vs >>>>> traditional threading. I use the example provided by the akka java >>>>> tutorial >>>>> computing Pi. In order to compare the abillity to paralellize big amounts >>>>> of tiny jobs, i use Pi-computaional slices of 100,000 jobs with iteration >>>>> of 1000. >>>>> Hardware is dual socket AMD opteron with each 8 real cores and 8 >>>>> 'virtual' (because the test uses floating point i just scale to 16 >>>>> threads >>>>> instead of 32). >>>>> >>>>> As you can see in the chart AKKA (2.03) performs very bad compared to >>>>> threads and a homebrew actor lib. >>>>> >>>>> source of akka bench is here: https://gist.github.com/ >>>>> RuedigerMoeller/8272966 >>>>> (added outer loop to original typesafe sample) >>>>> >>>>> Is there anything I miss or is this 'normal' Akka performance ? >>>>> >>>>> Threading-style code is here: https://gist.github.com/ >>>>> RuedigerMoeller/8273307 >>>>> >>>>> I tried 2.1 with even worse results. >>>>> >>>>> http://imgur.com/TAt9XOf >>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>>>> group/akka-user >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Akka User List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> >>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> -- >>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>>> group/akka-user >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Akka User List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> >>>> Visit this group at http://groups.google.com/group/akka-user. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> >>> -- >>> Cheers, >>> √ >>> >>> * Viktor Klang* >>> *Director of Engineering* >>> Typesafe <http://www.typesafe.com/> >>> >>> Twitter: @viktorklang >>> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Cheers, > √ > > * Viktor Klang* > *Director of Engineering* > Typesafe <http://www.typesafe.com/> > > Twitter: @viktorklang > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
