On Tue, Jan 7, 2014 at 2:27 PM, Rüdiger Möller <[email protected]> wrote:
> > > 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]> 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://stackoverfl >>>> ow.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. > nanoTime is supposedly monotonic, where is your reference to the "same thread" claim? > > >> >> >>> >>> >>>> 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 >> > Did you apply this? > >> >> >>> >>> >>>> >>>> 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. > What configuration have you been using? > > >> (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 ;-) > Single-machine performance is only interesting if you are after single points of failure. Cheers, √ > > >> >> 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/grou >>>>>> p/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/grou >>>>> p/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]. >>> 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]. > 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]. 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.
