On Tue, Jan 7, 2014 at 7:27 PM, Rüdiger Möller <[email protected]> wrote:
> No, my point is that using currentTimeMillis to obtain durations _at all_ >> is to be considered bad practice due to the shoddy accuracy. >> > > systemmillis is wall clock time. When measuring durations > 500 ms, > accuracy issues are not a problem. Modern OSes + VM have better accuracy > than older ones. I'll change to nanos just in case. > Yeah, so if you have clock drift or someone changes the wallclock between invocations you're hosed :) > > >> >> >> You're comparing apples to oranges, i.e. a transport with a model of >> computation. >> Akkas remoting transport is pluggable so you could implement an UM >> version of it if you so wish. Or even that WLLM! >> > > Ok, wasn't aware of that pluggability feature. Good. > > >> Reference? >> > > From post above (intel xeon 2 socket x 6 cores) .. > > ========================================== 1m jobs each perform > 100-pi-slice loop > AKKA > average 1 threads : 1914 > Abstraktor > average 1 threads : 1349 > synced Threading > average 1 threads : 800 > > "sync'ed threading" schedules runnables to an executor which obviously is > fastest. > Abstraktor prototype pushes methods onto a concurrentlinkedqueue and > executes calls via reflection. This already produces significant overhead. > Akka has an overhead of >2 times the single threading case. > > This would not be a problem if they scale infinitely (Threading does not > scale at all in the 1 million message case). But they don't because the > queues passing inter-thread messages create contention (to a lesser extend > compared to threading). Both abstraktor and akka stop scaling at a certain > amount of CPU cores used. > > So if the basic overhead is too high, the break even never comes ! > I'd beg to differ.Once you hit the ceiling of scaling up you scale out. And in any case, contention needs to be managed if you don't tolerate message loss (which you should). > Even worse (don't know the exact reason): Default Akka Q's seem to produce > more contention than my prototype'ish plain polled CLQ. So Akka comes with > the highest dispatch overhead and scales out worst due to contention: > double fail. You should do something about that. Fast message passing is at > the core of the system, its not a good idea to relax regarding efficiency > in such a critical part of your system. > You're basing this on unoptimized settings, please don't. > > >> >>> That's what you need for high end throughput+failover imo. Doing typed >>> actor message passing via JDK proxies e.g. is well .. you should know >>> yourself :-) >>> >> >> Absolutely, TypedActors used to be based on AspectWerkz proxies but were >> repurposed to use JDK Proxies due to the use-case. You are of course, if >> you want, free to use a JVM that ships with extreme performance JDK >> Proxies. :) >> > > 400 lines of byte code weaving can fix that. > You are absolutely free to use any weaving lib you want :-), the full Akka TypedActor impl is 1 file, 0 external dependencies and 700 lines (including whitespace and comments/documentation): https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/TypedActor.scala Akka TypedActors both works distributed and will benefit from any and all optimizations done to JDK proxies. Worth noting is that TypedActors is not a replacement for untyped actors: http://doc.akka.io/docs/akka/2.2.3/scala/typed-actors.html#When_to_use_Typed_Actors > > >> I've seen differences up to 4 magnitudes just with configuration changes. >> As you can imagine, I have spent quite some time tuning Akka. >> >> > Ok, i just have to stop posting in order to do the test now ... :-) > Cool, Cheers, √ > > - rüdiger > > -- > >>>>>>>>>> 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.
