> > 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. > > > 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 ! 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. > >> 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. > 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 ... :-) - 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.
