incubator-giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bo Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GIRAPH-185) Improve concurrency of putMsg / putMsgList
Date Mon, 23 Apr 2012 18:14:39 GMT

    [ https://issues.apache.org/jira/browse/GIRAPH-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259798#comment-13259798
] 

Bo Wang commented on GIRAPH-185:
--------------------------------

Thanks for the comments, Avery and Claudio.

I am measuring the performance, but I found the #Sent messages (reported by
counter) is always zero in both the original and changed version. Is that a
bug? In the output of Quick Start Guide, it is also zero.

I think ConcurrentHashMap is a good way to go. But for the current
approach, I think the memory overhead won't be much since most of the
vertices will receive messages except for those isolated ones and the one
whose neighbors are all inactive. In comparison, ConcurrentHashMap is much
larger than HashMap. An empty ConcurrentHashMap takes around 1673 bytes
while an empty HashMap only takes 137 bytes.

Another reason to use pre-population is to avoid the time spent on
allocating new message lists and inserting them into the map. We just need
to clear the list before the next super-step.

What's your opinion?

Thanks,
Bo



                
> Improve concurrency of putMsg / putMsgList
> ------------------------------------------
>
>                 Key: GIRAPH-185
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-185
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>    Affects Versions: 0.2.0
>            Reporter: Bo Wang
>            Assignee: Bo Wang
>             Fix For: 0.2.0
>
>         Attachments: GIRAPH-185.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Currently in putMsg / putMsgList, a synchronized closure is used to protect the whole
transientInMessages when adding the new message. This lock prevents other concurrent calls
to putMsg/putMsgList and increases the response time. We should use fine-grain locks to allow
high concurrency in message communication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message