Mailing-List: contact dev-help@hama.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hama.apache.org
Date: Sat, 15 Sep 2012 06:52:07 +1100 (NCT)
From: "Thomas Jungblut (JIRA)" <jira@apache.org>
To: dev@hama.apache.org
Message-ID: <314923812.81912.1347652327709.JavaMail.jiratomcat@arcas>
In-Reply-To: <1325717865.80098.1347628027677.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HAMA-643) Introduce BSP_OBLSYNC
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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