Current Plan

Quoting Jim:


1. Measure effect of Bare-C timing code by comparing real times for
   versions with and without timing code.  As long as this difference
   is small (under 1%) for sufficiently large problem sizes, then we
   can ignore the timing code.  Otherwise we'll have to account for it
   in any plots with total run time.


2. Finish reporting and plotting, making it very clear (a) how the
   components add up to the total time (and highlighting any
   differences between the sum of the components and the total time),
   and (b) which numbers and plots are comparable between the
   Topographica (hybrid Python+C) and the bare C versions.


3. Prepare good, clear plots of the scaling behavior for us to
   discuss: density versus time (on a single processor), and then
   number-of-CPUs versus time for various (relatively large) density
   values.
   
4. Analyze the plots to understand the scaling behaviour of the bare C
   code with number of CPUs (each with different memory subsystems).
   Is the communication overhead (and any other overheads) low enough
   that it scales well, up to a hundred processors or so?  


5. If the bare-C scaling with CPU is bad, we probably need to focus on the
   communication pattern, reducing time CPUs spend waiting on data.


6. If the bare-C scaling with CPU is good, rejoice and start focusing
   on the Topographica implementation, first making it have the same
   pattern of communication and C computation. Once it appears to be
   doing the same thing as the bare-C version, analyse the scaling
   with CPU for Topographica -- does the Python overhead limit the
   number of processors that are useful?  Is that limit high enough
   for our practical purposes?  If not, we'll need to focus on
   optimizing other parts of Topographica until the scaling behavior
   with CPU is good.


7. Once we have good scaling with CPU for Topographica, for
   sufficiently large problem sizes, we'll be ready to release that to
   everyone to start using.
   
8. Then we can focus on scaling with cores -- can we do anything to
   exploit other cores that share memory hierarchies?  Right now we do
   get some speedup using OpenMP on some shared-memory machines, but
   it's far from ideal. We'll at least want to exploit what speedup we
   already have from using all the cores, and possibly investigate how
   to make it better.  But we're unlikely to get quite that far in
   this project.


Suggested time output:

Total time (CPU usage 96%): 14.301s

Components: init=8.387s + sim.run=5.48s = 13.867s

Unaccounted-for: 0.434s (3.0%)

I'm hoping to finish my plotting script in about 2 days. As soon as that happens I will start using ECDF instead of Jupiter.