wiki.chpc.ac.za

User Tools

Site Tools

You are here: start » scaling
Trace:
scaling:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
scaling:start [2018/12/19 14:46]
ccrosby 		scaling:start [2021/12/09 16:42] (current)
Line 4: Line 4:
 First one should start with a problem that can be completed quickly -- say one that would take 10 minutes or so on a single node. The problem should not be trivially small -- large jobs are needed before parallelism can be seen properly.  If possible, run for fewer iterations or timesteps. First one should start with a problem that can be completed quickly -- say one that would take 10 minutes or so on a single node. The problem should not be trivially small -- large jobs are needed before parallelism can be seen properly.  If possible, run for fewer iterations or timesteps.
  
-Then one submits the jobs on increasing numbers of nodes and observes to see if the runtime comes down as expected. As an example of how you may go about this I have two scripts -- one is the PBS job script, and the second is a simple shell script that allows me to submit the PBS script with different parameters.+Then one submits the jobs on increasing numbers of nodes and observes to see if the runtime comes down as expected. As an example of how one may go about this, here are two scripts -- one is the PBS job script, and the second is a simple shell script that allows the user to submit the PBS script with different parameters.
  
 <file bash scaling_test.qsub> <file bash scaling_test.qsub>
Line 35: Line 35:
 first=1 first=1
  
-for i in 1 2 4 8 10 +for i in 1 2 4 8 10
 do do
   select="select=${i}:ncpus=24:mpiprocs=24:nodetype=haswell_reg,place=excl"   select="select=${i}:ncpus=24:mpiprocs=24:nodetype=haswell_reg,place=excl"
Line 49: Line 49:
 done done
 </file> </file>
-When I look at the results I see that the corresponding walltimes are:+ 
 +The (fake) results are represented here as a table:
 ^  Number of nodes  ^  Runtime (seconds)  ^ ^  Number of nodes  ^  Runtime (seconds)  ^
 | 1  |  344| | 1  |  344|
Line 56: Line 57:
 | 8  |  55| | 8  |  55|
 | 10 |  43| | 10 |  43|
-| 16 |  30| +
-| 20 |  25| +
-| 32 |  21| +
-| 40 |  15| +
-| 64 |  13| +
-| 80 |  14| +
-| 96 |  18|+
  
 These results are best interpreted in the form of a graph: These results are best interpreted in the form of a graph:
  
 +{{:scaling:scalegraph1.png|}}
 +
 +This graph looks OK (the run time comes down as the number of nodes goes up), but is actually quite difficult to interpret, in terms of finding the optimum number of nodes to use.  It is much more useful to plot the reciprocal of the runtime, such as the number of runs per hour:
 +
 +{{:scaling:scalegraph2.png|}}
 +
 +This clearly shows that the application is scaling linearly.  Adding more nodes will almost certainly make it run faster.
 +
 +The following two graphs illustrate a case which does **not** scale well.  The runtime graph does not look as good as the first example, but it is not immediately clear where the scaling starts worsening.  The "Runs per hour" graph provides much better insight.
 +
 +{{:scaling:scalegraph3.png|}}
 +
 +{{:scaling:scalegraph4.png|}}
 +
 +In this case there is definitely no point in trying to use more than 8 nodes, and the scaling is already showing diminishing returns after 2 nodes.  In this case it may be more efficient to use fewer nodes per run, but submit more simultaneous runs.
  
/app/dokuwiki/data/attic/scaling/start.1545223568.txt.gz · Last modified: 2021/12/09 16:42 (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
CC Attribution-Noncommercial-Share Alike 3.0 Unported Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki