shamsimam / savina Goto Github PK

Example code for Scala based solution: https://github.com/jesperdj/mandelactors

A possible fix is to limit the value of SOLUTION_LIMIT to the actual number of solutions
SOLUTION_LIMIT = Math.min(SOLUTION_LIMIT, SOLUTIONS[SIZE - 1]);

The busy loop just increments the counter, and returns it. For some reason it also gets currentTimeMillis, but does not use it.
If a JIT compiler performance inlining and sees that the return value is never used, the loop is easily removed, which is probably not desirable, because, I guess this is part of the 'parallel work load' in tryGenerateChildren(), traverse(), and urgentTraverse().

https://github.com/shamsmahmood/savina/blob/master/src/main/java/edu/rice/habanero/benchmarks/uct/UctConfig.java#L64

Not sure why this benchmark uses an atomic integer, seems to be overkill, no? I would expect this to be already safe: https://github.com/shamsmahmood/savina/blob/master/src/main/scala/edu/rice/habanero/benchmarks/piprecision/PiPrecisionAkkaActorBenchmark.scala#L53

The allNodes field is for some reason a HashMap. However, it seems to be densely populated so, I would kind of assume it should be an array. Any specific reason why it is a HashMap?

The busyWait function uses Math.random() and thus, sequentializes all workers on the AtomicLong seed of the shared Random object.

These two benchmarks do currently not do self-verification beside checking the results of the computation, which is there to avoid dead-code elimination.

Furthermore these two benchmarks rely (like many others) on the availability of .awaitTermination() in most incarnations. I saw in the Habanero versions the use of finish() instead.

In my version I went with returning promises with the computation result or the number of messages processed.
However, that changes the benchmark quite a bit, so I wonder whether it is an acceptable solution.

See smarr/SOMns-corelib@e2cc695 and smarr/SOMns-corelib@6d0d97e

The current GPL license makes it impossible to use the workloads from this project as test-cases in most open source projects. Please consider changing it with a more permissive license, such as MIT, Apache or BSD. Thank you.

Hi, I've been using the Savina benchmarks to evaluate an Akka feature I'm developing.

I noticed that the Akka benchmarks do not use the most efficient API for spawning actors. Namely, in FibonacciAkkaActorBenchmark, actors are spawned using context.system.actorOf instead of context.actorOf. The former API spawns actors at the top level of the supervision hierarchy, whereas the latter means that the parent supervises the child. I found that switching from the former to the latter led to a 2x performance improvement in Akka 2.6.3!

My theory is that you used the former API to simplify manual actor termination. In Akka, stopping the supervisor causes all its descendants to stop, which can sometimes mean that actors stop earlier than expected.

Is my theory correct? I'd love to hear your thoughts.