This plot looks reasonable to me. For a normal linear problem... I wouldn't expect to be able to scale a 350,000 dof problem (that only takes 30 seconds in serial) over about 10 cpus... just too much communication involved (which is what you're seeing).
I'm not saying that we couldn't do something better in MeshCommunication (or that there might be a bug)... I'm just trying to say that you shouldn't expect this problem to scale all that well. Try a bigger (or harder) problem and I bet that plot changes. Derek On Feb 11, 2010, at 3:23 PM, Yujie wrote: > Dear John, > > Please check the attached figure. It is better to show the problem. > I will test it according to your advice. I am just wondering whether it is > reasonable. > Thanks a lot. > > Regards, > Yujie > > On Thu, Feb 11, 2010 at 4:19 PM, John Peterson > <[email protected]> wrote: > Yujie, > > I don't understand the numbers you posted, not least of which because > the columns don't line up in my email... > > MeshCommunication is a class that does a lot of different things, is > that what you are referring to in the second column. > > How about attaching some actual perflog logs? How about adding some > additional logging to parallel_sort if that part is getting slower, > and seeing which part of it takes the longest? > > -- > John > > <forlibmesh.jpg> ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
