[
https://issues.apache.org/jira/browse/HAMA-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456071#comment-13456071
]
Thomas Jungblut commented on HAMA-643:
--------------------------------------
The only problem is with our superstep API. So we have to support different
kinds of syncs between supersteps, maybe through an enum that can be overridden
in each superstep class? No idea currently.
I would recommend to do this along with asynchronous messaging, because it
shares soo much functionality. Let's target this for 0.7.
> Introduce BSP_OBLSYNC
> ---------------------
>
> Key: HAMA-643
> URL: https://issues.apache.org/jira/browse/HAMA-643
> Project: Hama
> Issue Type: New Feature
> Components: bsp core, messaging
> Reporter: Thomas Jungblut
>
> The PUB Library [1] a german BSP lib contains a very interesting feature
> called "oblivious synchronization" or in short "BSP_OBLSYNC".
> The signature of the method looks like this:
> bq.bsp oblsync (bsp, numMsgs)
> {{{
> The oblivious synchronization should be used if the programmer knows the
> number of messages
> each processor will receive in a superstep. E.g., if each processor sends a
> message to its right
> neighbour then every processor knows that it will receive exactly one
> message. Thus, in the oblivious
> synchronization each processor waits until nmsgs are received. This type of
> synchronization
> is much faster than the other one since no additional communication is
> needed. The standard
> synchronization should be used if the number of messages to receive is
> unknown. Supersteps with
> standard synchronization can alternate with oblivious synchronizations, but
> within one superstep
> each processor has to use the same type of synchronization
> }}}
> With such an feature, we can greatly speedup kmeans clustering by avoiding
> barrier synchronization, because the message exchanged are constant
> throughout all supersteps.
> [1] http://www2.cs.uni-paderborn.de/~pub/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
