On Tue, Jan 7, 2014 at 5:26 PM, Rüdiger Möller <[email protected]> wrote:
> >> I'm not sure a hand-wavy reference to Cliff is going to quench my thirst >> for facts even though Cliff is a great guy. >> > > I googled that for you: > A JVM Does That? - YouTube <http://www.youtube.com/watch?v=uL2D3qzHtqY> > > I think you missed my point. Which was that there is no, to my knowledge, specification indicating that nanoTime shouldn't behave monotonically and non-monotonicity should be considered to be a bug. > Again: your obsession with time measurement makes sense when measuring > small amounts of ticks and adding them up, but not in the context of a > longer running test. You easily may copy the snippet and add nanotime > measurement. It will not make significant difference. > No, my point is that using currentTimeMillis to obtain durations _at all_ is to be considered bad practice due to the shoddy accuracy. > > >> >>> >>> >>> >>>> >>>>>> https://github.com/viktorklang/scala-vs-erlang/blob/9a124c75 >>>>>> c8034d9ba90baa2751f21c51f1e64ddc/scala/src/main/resources/ap >>>>>> plication.conf >>>>>> >>>>> >>>> Did you apply this? >>>> >>>> >>> >>> No, but i will try. I am not interested in presenting skewed benchmarks. >>> Abstraktor is not a competing project, its just my playground lean actor >>> impl to get a raw feeling of what should be possible. >>> >> >> The default settings is definitely not optimal for your use-case (as >> default settings rarely are). >> > > That's why I preferred talking back here :-) > :) > > >> >> >>> >>> | Single-machine performance is only interesting if you are after >>> single points of failure. >>> >>> Both things are important: single machine performance AND remote >>> messaging throughput + latency. >>> >> >> Yep, my argument was that without remote you have a spof. >> >> >>> Regarding remoting/failover there are much faster options than >>> actors/Akka today. >>> >> >> Reference? >> > > thinking of IBM WLLM or Informatika UM. Does Akka offer reliable UDP > messaging with several million msg/sec througput, from what I have seen its > challenging enough to get this on localhost. I have used the former, its > really blasting fast (at elast with kernel bypass networking equipment). > 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! > > >> >> >>> I appreciate your vision of making this transparent to the application. >>> Its a great idea, but I think your are still not there for the very high >>> end kind of application, no offence. I have built large high performance >>> distributed systems, so I know what I am talking bout. >>> >> >> What are you basing this opinion on, and what benchmark/setting are you >> comparing? >> > > Benchmarks and some public bragging with not-so-impressive numbers .. ;-). > *Also > i can see in single threaded benchmarks, Akka's message passing adds > significant overhead compared to single threaded executor and byte-weaving > based proxying as used in other libs.* > Reference? > One even can do remote messaging faster than Akka does inter thread > messaging, so there definitely is room for improvement. > Akka Remote Transport is as I said, pluggable. > Does Akka provide reliable UDP messaging (NAK based, not acknowledged ?). > Akka Remote Transport is ... > 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. :) > > >> >> >>> However regarding concurrent programming, actors can improve performance >>> and maintainability today, that's why i am currently >>> investigating/benchmarking local performance only. >>> I'll will incorporate your proposals into the test. >>> >> >> Great, let us know what the results were. >> > > Don't expect too much, as I pointed out from my POV the problem is already > inside Akkas basic message passing performance IMO, so Akka has a hard time > breaking even when scaling. We'll see. > I've seen differences up to 4 magnitudes just with configuration changes. As you can imagine, I have spent quite some time tuning Akka. Cheers, √ > > >> >> Cheers, >> √ >> >> >>> >>> regards, >>> 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. > -- 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.
