hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Jungblut (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HAMA-643) Introduce BSP_OBLSYNC
Date Fri, 14 Sep 2012 19:52:07 GMT

    [ 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
> standard synchronization can alternate with oblivious synchronizations, but within one
> 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

View raw message