Here's the reference to GraphLab. http://graphlab.org/

On Fri, Sep 9, 2011 at 8:20 AM, Claudio Martella <claudio.marte...@gmail.com
> wrote:

> sounds like a DataFlow paradigm. Could you please provide a reference to
> this "they"? :)
>
>
> On Fri, Sep 9, 2011 at 5:03 PM, Avery Ching <ach...@apache.org> wrote:
>
>> The GraphLab model is more asynchronous than BSP  They allow you to update
>> your neighbors rather than the BSP model of messaging per superstep.  Rather
>> than one massive barrier in BSP, they implement this with vertex locking.
>>  They also all a vertex to modify the state of its neighbors.  We could
>> certainly add something similar as an alternative computing model, perhaps
>> without locking.  Here's one idea:
>>
>> 1) No explicit supersteps (asynchronous)
>> 2) All vertices execute compute() (and may or may not send messages)
>> initially
>> 3) Vertices can examine their neighbors or any vertex in the graph (issue
>> RPCs to get their state)
>> 4) When messages are received by a vertex, compute() is executed on it
>> (and state is locally locked to compute only)
>> 5) Vertices stlll vote to halt when done, indicating the end of the
>> application.
>> 6) Combiners can still be used to reduce the number of messages sent (and
>> the number of times compute is executed).
>>
>> This could be fun.  And provide an interesting comparison platform barrier
>> based vs vertex based synchronization.
>>
>> On Fri, Sep 9, 2011 at 6:36 AM, Jake Mannix <jake.man...@gmail.com>wrote:
>>
>>>
>>>
>>> On Fri, Sep 9, 2011 at 3:22 AM, Claudio Martella <
>>> claudio.marte...@gmail.com> wrote:
>>>
>>>> One misunderstanding my side. Isn't it true that the messages have to be
>>>> buffered as they all have to be collected before they can be processed (by
>>>> definition of superstep)? So you cannot really process them as they come?
>>>
>>>
>>> This is the current implementation, yes, but I'm trying to see if an
>>> alternative is also possible in this framework, for Vertex implementations
>>> which are able to handle asynchronous updates.  In this model, a vertex
>>> would be required to be able to handle multiple calls to compute() in a
>>> single "superstep", and would instead signal that it's superstep
>>> computations are done at some (application specific) point.
>>>
>>> I know this goes outside of the concept of a "BSP" model, but I didn't
>>> want to get into too many details before I figure out how possible it was to
>>> implement some of this.
>>>
>>>    -jake
>>>
>>
>>
>
>
> --
>     Claudio Martella
>     claudio.marte...@gmail.com
>

Reply via email to