Unexpected retries / Performance

[Thomas Mauch]

Hi Peter

After you pointed me to the Akka Website, I found the information I
was looking for on http://doc.akkasource.org/stm-java. The sections
"Retries" and "Unexpected retries" explained exactly the strange
behavior I was encountering, when I added some logging statements to
your transfer method:

Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: done

Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: done

After reading these sections, I guess that I see just what has been
described in "Unexpected retries".

Is there similar content on the Multiverse web site as well and I was
just not seeing it? If not, it would surely make sense to add it (and
may be you can add information about the just release version 0.6 as
well).

I also have a question regarding the performance. I was running the
transfer method 1'000'000 times:
- using the traditional synchronized approach, it took 0.1 s
- with @TransactionalMethod, it took 2.2 s

I got the 2.2 s with version 0.6, with version 0.5 it took 2.8 s, so
this is quite an improvement. Nevertheless it is still 20 times slower
than using synchronized. What is the reason? Do you think that were
will be better performance in later releases?

Anyhow I think you work is really interesting.
Regards,
Thomas

[Peter Veentjer]

On Thu, Aug 26, 2010 at 11:02 AM, Thomas Mauch <thomas...@gmx.net> wrote:

Hi Peter

After you pointed me to the Akka Website, I found the information I
was looking for on http://doc.akkasource.org/stm-java. The sections
"Retries" and "Unexpected retries" explained exactly the strange
behavior I was encountering, when I added some logging statements to
your transfer method:

Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: done

Thread[main,5,main]: before to.SetBalance()
Thread[main,5,main]: before from.SetBalance()
Thread[main,5,main]: done

After reading these sections, I guess that I see just what has been
described in "Unexpected retries".

Yes.. It is the speculative stuff for configuration.
 

Is there similar content on the Multiverse web site as well and I was
just not seeing it? If not, it would surely make sense to add it (and
may be you can add information about the just release version 0.6 as
well).

I'll make sure it is on the website.
 

I also have a question regarding the performance. I was running the
transfer method 1'000'000 times:

- using the traditional synchronized approach, it took 0.1 s
- with @TransactionalMethod, it took 2.2 s

Depends on the size of the transaction. How many transactional objects are part
of your transaction ?

I got the 2.2 s with version 0.6, with version 0.5 it took 2.8 s, so
this is quite an improvement. Nevertheless it is still 20 times slower
than using synchronized. What is the reason? Do you think that were
will be better performance in later releases?

I'm currently working on a new beta stm that is completely is optimized for speed:
- no central clock
- object pooling to the extreme
- better tuned code
- less threadlocal access
So I think it is able to be a few times faster than the 0.5/0.6 release and also will
be better scalable.

If you want we can try the new engine and see where the bottlenecks are. I have no
instrumentation for the new engine, so the syntax is going to be a bit messy.

Anyhow I think you work is really interesting.

Thanks.
 

Regards,
Thomas

--
You received this message because you are subscribed to the Google Groups "multiverse" group.
To post to this group, send email to googlemu...@googlegroups.com.
To unsubscribe from this group, send email to googlemultiver...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/googlemultiverse?hl=en.

[Peter Veentjer]

Hi Thomas,

are you still working on the stm example? I would like to give it a try with the new beta stm.