There is a lot of parallel communication buried in there too (it performs a parallel binsort), so the same root cause may be to blame.
-Ben ----- Original Message ----- From: Yujie <[email protected]> To: Kirk, Benjamin (JSC-EG311) Cc: [email protected] <[email protected]> Sent: Mon Jan 18 15:25:41 2010 Subject: Re: [Libmesh-users] parallel performance Dear Ben, Thank you for your reply. I need to check the machine interconnect. My problem is two coupled elliptic-typed PDEs. According to your advice, the unstable time cost of Probe() is most likely from the hardware. However, how about the find_global_indices()? Generally, this function took almost the entire time. Thanks a lot. Regards, Yujie On Mon, Jan 18, 2010 at 3:18 PM, Kirk, Benjamin (JSC-EG311) < [email protected]> wrote: > What is the machine interconnect? > > What is the problem you are running? > > Probe() indicates the code is waiting on an mpi message to arrive or > complete. If the network is poor or the cluster is unevenly loaded this > could cause what appear (to me) to be very long probes and the > unrepeatability you report. > > For a well tuned system with no job contention the probes should take > essentially 0 time - the code is structured so that the messages are likely > ready when the probe is issued. > > -Ben > > > ----- Original Message ----- > From: Yujie <[email protected]> > To: [email protected] < > [email protected]> > Sent: Mon Jan 18 12:48:30 2010 > Subject: [Libmesh-users] parallel performance > > Dear Libmesh Developers, > > Recently, I use the new SVN libmesh (downloaded in about November) for my > application. When I tried to increase the number of CPU to observe the > parallel performance with adaptive mesh evolution. I find that Functions: > MeshCommunication: find_global_indices( ) and Parallel:probe( ) spend most > of the whole cost time. Further, the cost time is not stable. For example, > > CPUs total time time of find_global_indices() time of probe() > 2 6473.0 5389.0 0.0767 > 3 5337.0 4843.0 12.73 > 4 1341.0 921.0 18.64 > 5 2959.0 2299.0 179.7 > 6 3071.0 622.4 2035.4 > > I am using X86_64 Cluster. Could you give me some advice? Thanks a lot. > > Regards, > Yujie > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
