[jira] [Updated] (HAMA-788) Graph Aggregator Restracturing
[ https://issues.apache.org/jira/browse/HAMA-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anastasis Andronidis updated HAMA-788: -- Attachment: HAMA-788-v1.patch A first approach. I would really like some comments. Work to be done: 1) load peerAggregators with Java reflection 2) migrate dynamic vertex additions and deletes as peerAggregator 3) create lazy aggregators to minimize supersteps 4) stabilize peerAggregator API P.S. I believe that we can add a reset() method on the Aggregator interface so we don't create a new object every time in AggregatorRunner. We might get a speedup. Graph Aggregator Restracturing -- Key: HAMA-788 URL: https://issues.apache.org/jira/browse/HAMA-788 Project: Hama Issue Type: New Feature Components: graph Affects Versions: 0.6.2 Reporter: Anastasis Andronidis Assignee: Anastasis Andronidis Priority: Minor Labels: features Attachments: HAMA-788-v1.patch I think that we should add a second type of aggregators that will be able to act on top of BSP peers instead of vertices. This will give the advantage to graph framework programmers and users to add features easier. The interface that I was thinking: // This will run on slave peers // Get the value of the peer we want to monitor and act on it public Writable getPeerValue(GraphJobRunnerV, E, M graphJobRunner); // This will run on master aggregator // Compose values public void aggregate(Writable v); // Get the composed value public Writable getValue(); // This will run on slave peers // Set the composed value to the peer public void setPeer(GraphJobRunnerV, E, M graphJobRunner, Writable v); // Reset the instance so we don't need to recreate object public void reset(); e.g. 1) The graph framework stop condition can act as a peer aggregator a) we check on every peer if we have vertex changes (an int variable) b) send all integers to the master aggregator and check if we need to stop c) slaves get a message to stop the peer or continue 2) Count all vertices in every superstep (if we have dynamic changes in vertices) can act as a peer aggregator a) get the number of vertices on every peer b) sum all vertices count on master aggregator c) slaves update their values For aggregators to work properly, we need to make a sync (superstep) before every graph iteration. But we can also introduce a lazy way to do the aggregations so the user code run at same time of the aggregation. (the stop condition works this way). -- 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
Re: [DISCUSS] Hama 0.7.0
+1 BTW, are we going to prioritize tasks in roadmap? On 28 August 2013 14:17, Tommaso Teofili tommaso.teof...@gmail.com wrote: sure, it looks reasonable to me. Tommaso 2013/8/28 Edward J. Yoon edwardy...@apache.org Hi all, After we release the 0.6.3 (HDFS 2.0 version), we have to work for 0.7.0 version now. I would like to suggest that we solve the messaging scalability issue. WDYT? ... And, according to my experiments, BSP framework shows very nice performance (I tested also GraphLab and Spark). Only Graph job is slow. So, I'll mainly work on improving the performance of GraphJobRunner. -- Best Regards, Edward J. Yoon @eddieyoon
[jira] [Commented] (HAMA-789) BspPeer launched fail because port is bound by others
[ https://issues.apache.org/jira/browse/HAMA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756135#comment-13756135 ] MaoYuan Xian commented on HAMA-789: --- The fix works well I think. BspPeer launched fail because port is bound by others - Key: HAMA-789 URL: https://issues.apache.org/jira/browse/HAMA-789 Project: Hama Issue Type: Bug Components: bsp core Affects Versions: 0.6.2 Reporter: MaoYuan Xian Assignee: Suraj Menon Attachments: HAMA-789.patch In GroomServer, we call BSPNetUtils.getNextAvailable to assigning the bsppeer listening port. After figures out an available port, the GroomServer release the port and launches the BspPeer(Child), then the child listens to this port. However, during the GroomServer release the port and peer listens the port, if other process in the operation system binds to the same port occasionally, the bsppeer will fail to start up because of Address already in use exception. -- 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
Re: HybridBSP (CPU and GPU) Task Integration
Sorry replying late.
For scheduling, sorry I can't remember the detail now. IIRC
scheduling is done by dispatching tasks to all GroomServers. The code
in SimpleTaskScheduler.java has a class TaskWorker which dispatches
GroomServerAction to GroomServer through GroomProtocol.
At GroomServer side, a task is launched by launchTaskForJob() where it
calls TaskInProgress's launchTask(); then a seperated process will be
forked for running bsp logic.
For input logic, other developers can provide more insight on how the
data is split. My understanding is that the split mechanism resembles
to MapReduce's as you mentioned by number of tasks; so you might need
to provide input logic that can split corresponded data (80% for gpu
20% for cpu) and the tasks launched can correctly read those input
data according to their type (bsp or gpu). I could be wrong regarding
to input logic mechanism.
The split logic seems to be nearby BSPJobClient.partition() function.
What I can see at the moment is - if launched gpu tasks do not
arbitrary talk (in direct way) to other external gpu processes, which
runs wthin other bsp tasks, it seems that we can treat it as a normal
bsp task without too much modification. But that would be subjected to
how the implementation is done.
On 25 August 2013 22:08, Martin Illecker millec...@apache.org wrote:
Thanks, your picture [1] illustrates this scenario very good!
In short I have to modify the runBSP in BSPTask, check if the submitted
task extends HybridBSP.
If so, start a PipesBSP server and wait for incoming connections. And run
the bspGpu method within
the HybridBSP task.
Regarding to scheduling:
1) I have to decide within the runBSP should I execute the bspGpu or
default bsp method
of HybridBSP.
e.g., having numTaskBsp set to 8, Hama will start 8 separate Java threads
If I set an additional conf numTaskBspGpu property to 1, I want to have 9
bsp tasks.
(I don't know where these bsp threads are started. Add property check
for numTaskBspGpu and start more bsp tasks.)
8 tasks should execute the default bsp method within runBSP and only one
task should run bspGpu.
2) It should be possible to schedule input data for bsp tasks. (belongs to
the partitioning job)
e.g, having 8 cpu bsp tasks and 1 gpu bsp task, I wish to have a property
to control which amount of input belongs to
which task. Default: Hama's partinioning job will divide the input data
(e.g., sequence file) by the number of tasks?
It might happen that e.g., 80% of input data should go to gpu task and only
20% to cpu tasks.
By the way do you think a HybridBSP based task which extends BSP will work
on Hama without any changes.
Normally it should work because of inheritance of BSP.
Thanks!
Martin
[1] http://i.imgur.com/RP3ETBW.png
2013/8/24 Chia-Hung Lin cli...@googlemail.com
It seems to me that an additional process or thread will be launched
for running a GPU-based bsp task, which will then communicate with
PipesBSP process, as [1]. Please correct me if it is wrong.
If this is the case, BSPTask looks like the place to work on. When
BSPTask process is running, it can check (e.g. in runBSP) if
additional GPU process/ thread is needed to be created; then launch/
destroy such task accordingly.
By the way, it is mentioned that scheduling is needed. Can you please
give a bit more detail on what kind of scheduling is required?
[1]. http://i.imgur.com/RP3ETBW.png
On 24 August 2013 00:59, Martin Illecker mar...@illecker.at wrote:
What's the difference between launching `bsp task' and `gpu bsp task'?
Will gpu bsp task fork and execute c/ c++ process?
The GPU bsp task can also be executed within a Java process.
In detail I want to run a Rootbeer Kernel (e.g., PiEstimationKernel [1])
within the bspGpu method.
A Rootbeer Kernel is written in Java and converted to CUDA. (the entry
point is the gpuMethod)
Finally there is a Java wrapper around the CUDA code, so it can be
invoked
within the JVM.
So far there is no difference between a normal bsp task execution but I
want to use Hama Pipes to communicate via sockets.
The GPU bsp task should start like the default one but I will have to
establish the Pipes Server for communication.
And of course I need scheduling for theses GPU and CPU tasks.
I hope the following source will illustrate my scenario better:
public class MyHybridBSP extends
HybridBSPNullWritable, NullWritable, NullWritable, NullWritable,
Text {
@Override
public void bsp(BSPPeerNullWritable, NullWritable, NullWritable,
NullWritable, Text peer)
throws IOException, SyncException, InterruptedException {
MyGPUKernel kernel = new MyGPUKernel();
Rootbeer rootbeer = new Rootbeer();
rootbeer.setThreadConfig(BLOCK_SIZE, GRID_SIZE,
BLOCK_SIZE*GRID_SIZE);
// Run GPU Kernels
rootbeer.runAll(kernel);
}
@Override
public void bspGpu(BSPPeerNullWritable,
Re: [DISCUSS] Hama 0.7.0
According to Suraj's dependency diagram, asynchronous messaging is most important and highest priority for us at the moment. How about we focus on this one? (Of course, some committers can dedicated on doing GPU, ML algorithms, or Interface Refactoring issues, regardless of *core* roadmap). If we agree with this plan, I think we can separate the async messaging into smaller sub-tasks: * Decision of whether we will use existing open source, or not. * Design the asynchronous messaging interface (maybe (spilling) message queue also should be considered together?). * Implementation of asynchronous messaging functions, such as send or flush. * Evaluation and adopt asynchronous messaging as a default messenger system. WDYT? On Mon, Sep 2, 2013 at 11:31 PM, Chia-Hung Lin cli...@googlemail.com wrote: +1 BTW, are we going to prioritize tasks in roadmap? On 28 August 2013 14:17, Tommaso Teofili tommaso.teof...@gmail.com wrote: sure, it looks reasonable to me. Tommaso 2013/8/28 Edward J. Yoon edwardy...@apache.org Hi all, After we release the 0.6.3 (HDFS 2.0 version), we have to work for 0.7.0 version now. I would like to suggest that we solve the messaging scalability issue. WDYT? ... And, according to my experiments, BSP framework shows very nice performance (I tested also GraphLab and Spark). Only Graph job is slow. So, I'll mainly work on improving the performance of GraphJobRunner. -- Best Regards, Edward J. Yoon @eddieyoon -- Best Regards, Edward J. Yoon @eddieyoon
