Jed,
Thanks for your feedback.
> On Oct 23, 2019, at 7:15 PM, Jed Brown <j...@jedbrown.org> wrote:
>
> IMO, Figures 2 and 7+ are more interesting when the x axis (vector size)
> is replaced by execution time.
> We don't scale by fixing the resource
> and increasing the problem size, we choose the global problem size based
> on accuracy/model complexity and choose a Pareto tradeoff of execution
> time with efficiency (1/cost) to decide how many nodes to use. Most of
> those sloping tails on the left become vertical lines under that
> transformation.
I don't see the connection between your first sentence and the other
sentences.
How does the plot with time instead of size tell you what number of
processors to use?
I don't understand the plots with x as a time axis, so I suspect most
potential readers won't. The only point of the plots is really to give an idea
of the scale of the performance and that performance is low except for large
sizes so will keep the plot axis as is.
>
> How is latency defined in Figure 6?
Least squares. We will reference the definition given later.
>
> Data upon which the latency-bandwidth model is derived should be plotted
> to show the fit, and the model needs to be constrained to avoid negative
> latency.
For the CPU we are playing with the plots to see if they can convey some
useful information. The performance over each range of values on the CPU is
simply not linear, hence a linear fit gives incomplete information. The
negative latencies perhaps don't convey particularly useful information so we
may not list them, the bandwidth value I think is still useful because it does
convey locally the performance of the memory.
>
> If you give me access to the repository with data and current plotting
> scripts, I can take a crack at slicing it in the way that I think would
> be useful.
Hannah will give you the data.
Barry
>
> "Smith, Barry F. via petsc-dev" <petsc-dev@mcs.anl.gov> writes:
>
>> We've prepared a short report on the performance of vector operations on
>> Summit and would appreciate any feed back including: inconsistencies, lack
>> of clarity, incorrect notation or terminology, etc.
>>
>> Thanks
>>
>> Barry, Hannah, and Richard
