You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hama.apache.org by "Edward J. Yoon" <ed...@apache.org> on 2015/04/09 15:13:41 UTC
giraph (158 secs) vs hama (223 secs) on 300M edges graph
Just FYI, I tested giraph using same input data on 2 node cluster.
Tests are not enough yet but Hama is slightly slow.
The main reason is that hama's graph job consists of two multi
jobs:graph pre-partitioning and computing (I/O usage between jobs and
launching overheads).
If possible, I'll fix this issue before release 0.7. :)
Thanks.
--
Best Regards, Edward J. Yoon
RE: giraph (158 secs) vs hama (223 secs) on 300M edges graph
Posted by "Edward J. Yoon" <ed...@samsung.com>.
Same JSON format 300M edgea graph, 20 tasks: Hama 115.808 seconds, Giraph 139
secconds
--
Best Regards, Edward J. Yoon
-----Original Message-----
From: Julio Pires [mailto:juliocspires@gmail.com]
Sent: Monday, April 13, 2015 11:22 PM
To: dev@hama.apache.org
Subject: Re: giraph (158 secs) vs hama (223 secs) on 300M edges graph
Hi,
Interesting results!
With changes of HAMA-946 [1], the final comparation is:
Hama (160.696 seconds) and Giraph (158 seconds), right?
Thanks!
1 - https://issues.apache.org/jira/browse/HAMA-946
2015-04-09 10:13 GMT-03:00 Edward J. Yoon <ed...@apache.org>:
> Just FYI, I tested giraph using same input data on 2 node cluster.
> Tests are not enough yet but Hama is slightly slow.
>
> The main reason is that hama's graph job consists of two multi
> jobs:graph pre-partitioning and computing (I/O usage between jobs and
> launching overheads).
>
> If possible, I'll fix this issue before release 0.7. :)
>
> Thanks.
>
> --
> Best Regards, Edward J. Yoon
>
RE: giraph (158 secs) vs hama (223 secs) on 300M edges graph
Posted by "Edward J. Yoon" <ed...@samsung.com>.
Work in progress. I guess we can save more time by doing initial vertex
computations during load vertices into memory and converting records using
thread.
--
Best Regards, Edward J. Yoon
-----Original Message-----
From: Julio Pires [mailto:juliocspires@gmail.com]
Sent: Monday, April 13, 2015 11:22 PM
To: dev@hama.apache.org
Subject: Re: giraph (158 secs) vs hama (223 secs) on 300M edges graph
Hi,
Interesting results!
With changes of HAMA-946 [1], the final comparation is:
Hama (160.696 seconds) and Giraph (158 seconds), right?
Thanks!
1 - https://issues.apache.org/jira/browse/HAMA-946
2015-04-09 10:13 GMT-03:00 Edward J. Yoon <ed...@apache.org>:
> Just FYI, I tested giraph using same input data on 2 node cluster.
> Tests are not enough yet but Hama is slightly slow.
>
> The main reason is that hama's graph job consists of two multi
> jobs:graph pre-partitioning and computing (I/O usage between jobs and
> launching overheads).
>
> If possible, I'll fix this issue before release 0.7. :)
>
> Thanks.
>
> --
> Best Regards, Edward J. Yoon
>
Re: giraph (158 secs) vs hama (223 secs) on 300M edges graph
Posted by JĂșlio Pires <ju...@gmail.com>.
Hi,
Interesting results!
With changes of HAMA-946 [1], the final comparation is:
Hama (160.696 seconds) and Giraph (158 seconds), right?
Thanks!
1 - https://issues.apache.org/jira/browse/HAMA-946
2015-04-09 10:13 GMT-03:00 Edward J. Yoon <ed...@apache.org>:
> Just FYI, I tested giraph using same input data on 2 node cluster.
> Tests are not enough yet but Hama is slightly slow.
>
> The main reason is that hama's graph job consists of two multi
> jobs:graph pre-partitioning and computing (I/O usage between jobs and
> launching overheads).
>
> If possible, I'll fix this issue before release 0.7. :)
>
> Thanks.
>
> --
> Best Regards, Edward J. Yoon
>