Roassal scalability
Locked
12
12
 
|
Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal. Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest. In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure. So I would like to know. Stef _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
+1 :-) On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse <[hidden email]> wrote: Hi _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
No, we haven't decided exactly what will be the plan for the GSoC for Mathieu because in the last meeting we talked about what is he currently doing, integrate part of that and decided what to do next with some of his current work. And yes, we need to make it asap. Yes, we plan to use Athens transformation in the future, but the thing is that I don't think all our performance problems come from the platform. Because of this I don't think that all our problems will be fixed with Athens. For example the events generation, we might be generating too many. Vanessa. On 06/05/2013 04:06 AM, Usman Bhatti wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Jun 5, 2013, at 9:45 PM, Vanessa Peña Araya <[hidden email]> wrote:
Because mathieu will have a short GSOC.
but the obvious first :) Because once you know you remove part. I do not know if you loaded the visualization igor did with athens and they were a lot of bezier and they were smooth. For your information we will push athens in Pharo really soon now. Normally it was planned for end of the last week but we got problem with our servers. Stef
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by vpena
On Wed, Jun 5, 2013 at 9:45 PM, Vanessa Peña Araya <[hidden email]> wrote:
I am not sure event generation is the only thing we would like to concentrate during the GSOC because there can be other optimizations. The thing is that the current work is as interesting as improving the performance of Roassal. But we'll have to set priorities at the end we might not have enough time to profile and improve all the points impacting the performance in Roassal.
usman
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi I think there are two different points : 1 - The layout algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ). 2 - Even if I'm not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it.
That is two different things. Layouts may be long to compute, when you display a thousand edges and nodes with a grid layout, it should be fluent.
Regards Mathieu _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I think the goal of this GSoC must be to get Roassal fluent once the layout is shown. And if I have time then, or if someone want to do it, we should implement a real force layout, and improve other ones.
Regards Math
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
> I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu.
> Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal. The idea is indeed to replace the way coordinate are computed in Roassal by using Matrixes. And Athens will play an important role. It may speed up the visualization. > Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be > a solution at its architectural level to have one library for Athens and one for the rest. Yes there is a plan, and the idea is that Matthieu will work on it as soon as possible. Having Athens matrixes in Roassal has nothing to do with Roassal being platform independent. > In addition I do not understand how Roassal can work fast on amber while using Athens without again using the > athens infrastructure. For Amber, we still unsure about the strategy to adopt here. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by MathieuDehouck
> 1 - The layout algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ).
It depends. You need to have a sophisticated algorithm (probably based on quadtree as done in D3) to have it fast. > 2 - Even if I'm not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it. Yes, you spotted a nice problem. We are aware of it but haven't found a nice solution to it. A smarter way to generate event is indeed needed. We left some todos from our last meeting, were you able to make progress on them? If yes, then you should focus on using Athens Matrixes. This is on our todo list for a long time. Using Athens may speed up Roassal, but I doubt it will make Roassal scale up to many more nodes. Who knows.... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Usman Bhatti
> I am not sure event generation is the only thing we would like to concentrate during the GSOC because there can be other optimizations. The thing is that the current work is as interesting as improving the performance of Roassal. But we'll have to set priorities at the end we might not have enough time to profile and improve all the points impacting the performance in Roassal.
The event generation may be closely linked to the poor performance of Roassal. Events are generated all the time, as soon as you move the mouse without doing anything. This is not something we should remove, however this is something we should think carefully. For now, the idea is to make sure that what Mathieu has done so far with his layouts is not lost but integrated in Roassal. Then, the next move can concentrate on integrating Athens better since Mathieu is physically close to Igor. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
> I do not know if you loaded the visualization igor did with athens and they were a lot of bezier and they were smooth.
The difficult thing is to handle the interaction (e.g., turning the bezier curve red as soon as the mouse is above it). I believe this is where most of the resources are wasted so far. But yes, integrating Athens more in Roassal by using matrixes is really important. > For your information we will push athens in Pharo really soon now. Normally it was planned for end of the last week but we got problem with our servers. That is a very good news!!!! Alexandre >> >> On 06/05/2013 04:06 AM, Usman Bhatti wrote: >>> +1 :-) >>> >>> >>> On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse <[hidden email]> wrote: >>> Hi >>> >>> I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. >>> Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal. >>> >>> Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be >>> a solution at its architectural level to have one library for Athens and one for the rest. >>> >>> In addition I do not understand how Roassal can work fast on amber while using Athens without again using the >>> athens infrastructure. >>> >>> So I would like to know. >>> >>> Stef >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
Le 06.06.2013 15:41, Alexandre Bergel a écrit : 1 - The layout algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ).It depends. You need to have a sophisticated algorithm (probably based on quadtree as done in D3) to have it fast.2 - Even if I'm not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it.Yes, you spotted a nice problem. We are aware of it but haven't found a nice solution to it. A smarter way to generate event is indeed needed. We left some todos from our last meeting, were you able to make progress on them? If yes, then you should focus on using Athens Matrixes. This is on our todo list for a long time. Using Athens may speed up Roassal, but I doubt it will make Roassal scale up to many more nodes. Who knows.... Cheers, Alexandre
About my todos list. Well, now compact trees take care of nodes size. Radial tree also but I still have a little something to add to it. I do not have change anything in Bezier curves and the way the interact with canvas, but I can do it when working on canvas later.
But by now, I have to write papers for school, so I don't have much time to spend on the code. (abstract, report ...) I'll be back soon on Roassal.
Regards Math _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards Mathieu _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Mathieu,
We will have a look at this asap Alexandre On Jun 7, 2013, at 9:19 AM, [hidden email] wrote: > Hi > > I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). > > Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. > > > Regards > > Mathieu > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <[hidden email]> wrote: > Hi Mathieu, > > We will have a look at this asap > > Alexandre > > > On Jun 7, 2013, at 9:19 AM, [hidden email] wrote: > >> Hi >> >> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). >> >> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. >> >> >> Regards >> >> Mathieu >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering.
Cheers,
Fabrizio
2013/6/8 Tudor Girba <[hidden email]> n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Thanks Fabrizio.
We have found where the problem comes from. Give us a couple of hours :-) Alexandre On Jun 14, 2013, at 5:41 AM, Fabrizio Perin <[hidden email]> wrote: > Hi, > to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes. > > The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse. > > So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. > Cheers, > Fabrizio > > > 2013/6/8 Tudor Girba <[hidden email]> > n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well? > > Doru > > > On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <[hidden email]> wrote: > > > Hi Mathieu, > > > > We will have a look at this asap > > > > Alexandre > > > > > > On Jun 7, 2013, at 9:19 AM, [hidden email] wrote: > > > >> Hi > >> > >> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). > >> > >> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. > >> > >> > >> Regards > >> > >> Mathieu > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Fabrizio Perin-3
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible. Cheers, Alexandre On Jun 14, 2013, at 5:41 AM, Fabrizio Perin <[hidden email]> wrote: > Hi, > to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes. > > The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse. > > So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. > Cheers, > Fabrizio > > > 2013/6/8 Tudor Girba <[hidden email]> > n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well? > > Doru > > > On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <[hidden email]> wrote: > > > Hi Mathieu, > > > > We will have a look at this asap > > > > Alexandre > > > > > > On Jun 7, 2013, at 9:19 AM, [hidden email] wrote: > > > >> Hi > >> > >> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). > >> > >> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. > >> > >> > >> Regards > >> > >> Mathieu > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Alex
What was the problem? Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <[hidden email]> wrote: > Hi Fabrizio, > > Can you try again? > It should be significantly faster, even though we are still rendering elements that are not visible. > > Cheers, > Alexandre > > > On Jun 14, 2013, at 5:41 AM, Fabrizio Perin <[hidden email]> wrote: > >> Hi, >> to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes. >> >> The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse. >> >> So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. >> Cheers, >> Fabrizio >> >> >> 2013/6/8 Tudor Girba <[hidden email]> >> n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well? >> >> Doru >> >> >> On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <[hidden email]> wrote: >> >>> Hi Mathieu, >>> >>> We will have a look at this asap >>> >>> Alexandre >>> >>> >>> On Jun 7, 2013, at 9:19 AM, [hidden email] wrote: >>> >>>> Hi >>>> >>>> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). >>>> >>>> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. >>>> >>>> >>>> Regards >>>> >>>> Mathieu >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
Hi Alex, Anyway tomorrow at work I will be able to access again to the model I was using and I will let you know about the performances.thanks really a lot, i didn't expect a so fast answer, mine was more a suggestion :) 2013/6/14 Alexandre Bergel <[hidden email]> Hi Fabrizio, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |