On Tue, Jan 7, 2014 at 4:32 PM, √iktor Ҡlang <[email protected]> wrote:
> > > > On Tue, Jan 7, 2014 at 4:22 PM, Rüdiger Möller <[email protected]> wrote: > >> >>> nanoTime is supposedly monotonic, where is your reference to the "same >>> thread" claim? >>> >> >> Its guaranteed to be monotonic seen from a single thread, not across >> threads. systime millis is guaranteed to be monotonic across threads, so >> its more expensive and requires some fencing etc. to be generated by >> hotspot. There is a video of Cliff Click out there where he goes into that >> in great detail .. >> Anyway, the results are not skewed by that for sure. >> > > 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 around and I have not found any conclusive answer if you take old systems into account. There is this blog post (now more than 6 years old) ( https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks): "The default mechanism used by QPC is determined by the Hardware Abstraction layer(HAL), but some systems allow you to explicitly control it using options in boot.ini, such as /usepmtimer that explicitly requests use of the power management timer. This default changes not only across hardware but also across OS versions. For example Windows XP Service Pack 2 changed things to use the power management timer (PMTimer) rather than the processor timestamp-counter (TSC) due to problems *with the TSC not being synchronized on different processors in SMP system*s, and due the fact its frequency can vary (and hence its relationship to elapsed time) based on power-management settings. " Also another one (https://lkml.org/lkml/2005/11/4/173): Current AMD Opteron(tm) and Athlon(tm)64 processors provide power management mechanisms that independently adjust the performance state ("P-state") and power state ("C-state") of the processor[1][2]; these state changes can affect a processor core's Time Stamp Counter (TSC) which some operating systems may use as a part of their time keeping algorithms. *Most modern operating systems are well aware of **the effect of these state changes on the TSC and the potential for TSC drift[3] across multiple processor cores **and properly account for it*. I don't think these apply for current systems though (the above posts are really old) and I don't even see definitive answer for old systems -- unfortunately Björn is not here to ask him. Anyway this has not much relevance for this discussion. > > >> >> >> >>> >>>>> https://github.com/viktorklang/scala-vs-erlang/blob/9a124c75 >>>>> c8034d9ba90baa2751f21c51f1e64ddc/scala/src/main/resources/ >>>>> application.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. >> > > Tuning the dispatcher is not skewing the benchmarks. The whole idea of dispatchers is that you can tune subsystems of your actor system to particular load characteristics. The default throughput setting hits a particular point in the fairness-throughput tradeoff spectrum, which is not the best for batch workloads. > > >> >> | 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. >> > As for failover, if you are limited to software implementation the speed of remote failover is bounded by a timeout period, it does not matter what software framework (Akka or other) is used. If you have any side-channel information, maybe hardware solutions e.g. link failure notifications or hardware watchdogs the game is different -- but that is apples to oranges. > > >> 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. >> > > It is a bit of a strawman. For any kind of *particular *use-casethe fastest implementation is a custom hand-tuned one designed by an expert and I don't doubt that you can beat Akka in many particular scenarios. In fact, for every system there is always one more benchmark that you cannot beat. It all depends how much resources you have to throw against your problem (and maintaining it over time). > > >> 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. >> > > We could in theory play around with the example and fine-tune (I am very tempted to try it now), but the problem is that we are preparing a release and we cannot really allocate any time to this particular benchmark. Play around with the dispatcher settings a bit and see how it works out -- try tuning the throughput setting in particular. -Endre > > 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. > -- >>>>>>>>>> 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.
