<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Jed:<br>
    <br>
      Good catch on the cache hierarchy: that is multi-core specific,
    GPUs and KPUs don't have those hierarchies. What we are really after
    is a measure of the instruction + operand bandwidth and latency,
    which has always been a very complex function of hardware resource
    availability and instruction issue timing. Maybe the simplification
    is offered by the physical organization of the machine: there will
    be on-chip memories and off-chip memories in any machine
    organization that could be used to capture operand bw and latency
    dependencies. In cache hierarchies you can reasonably ignore the
    lower levels as they are designed and dimensioned to support the
    data flow from the outer cache into the functional units. if the hw
    folks have done their job that should be seamless. Then again, I
    have spent 15 years finding such cache hierarchy failures, so maybe
    it isn't as simple from the outside.<br>
    <br>
    The derivative indeed is the quest, but don't get too comfortable
    with that either. Because we are talking about a discrete event
    system, there is no linearity to speak off. If you deplete a
    particular resource, your performance will fall dramatically ruining
    your derivative. Unfortunately, it is the location of the cliff that
    is most important for the application designer, and any type of
    scaling arguments or interactive presentation you would like to
    offer your customers.<br>
    <br>
    I think the solution lies in the 'big data' that will be generated
    by running the benchmarks on hundreds or thousands of
    configurations. Weak scaling measurements are the best in
    discovering the cliffs in the resource availability, so instead of
    asking the hardware or a simulator to cripple the resource, ask the
    application to find the resource bottleneck and hammer it. Then the
    scaling behavior of the collective application+hardware needs a
    couple of data points at the different cliffs to offer you a pretty
    good characterization of the dynamic behavior of the machine.<br>
     <br>
    Theo<br>
    <br>
    On 6/9/2014 8:36 AM, Jed Brown wrote:<br>
    <span style="white-space: pre;">> Theodore Omtzigt
      <a class="moz-txt-link-rfc2396E" href="mailto:theo@stillwater-sc.com"><theo@stillwater-sc.com></a> writes:<br>
      ><br>
      >> As always, depending on the question you need to answer,
      you want to see<br>
      >> different Kaviat graphs. As a hardware designer, I would
      like to see how<br>
      >> well a particular resource allocation is helping the
      performance of an<br>
      >> application. As all machines have a common collection of
      resources, the<br>
      >> Kaviat's that I am interested would capture those, in
      particular this list:<br>
      >><br>
      >> FPU sp peak throughput<br>
      >> FPU dp peak  (big difference in silicon allocation)<br>
      >> IU peak throughput<br>
      >> L1 bw peak (latency is governed by core clock, but bw is
      parallelism on<br>
      >> the cache ports)<br>
      >> L2 bw peak (latency becomes an issue further away, but
      most L2s are<br>
      >> supporting fast L1 refresh)<br>
      >> L3 bw peak<br>
      >> L3 size<br>
      >> FSB bw peak<br>
      >> Memory latency (for low-concurrency kernels this is the
      bottleneck)<br>
      >> Memory bw peak<br>
      >> Network latency<br>
      >> Network bw peak<br>
      >> Reduction peak throughput<br>
      >> Broadcast peak throughput<br>
      >><br>
      >> The beauty of this list is that it is uniform across all
      machines,<br>
      >> including non-von Neumann. <br>
      ><br>
      > This seems to imply a particular cache hierarchy, which may
      not be<br>
      > universal.  I think that to reword your request, we would
      like to see<br>
      > the DERIVATIVE of application performance with respect to
      each of these<br>
      > attributes.  I wrote exactly these words in emails this
      winter, but I<br>
      > don't know how to measure this derivative.  Does there exist
      a hardware<br>
      > platform or simulator capable of incrementally crippling one
      attribute<br>
      > at a time?<br>
      ><br>
      > If we can measure these quantities for the suite of apps and
      benchmarks<br>
      > on different machines, we could make a very useful
      interactive<br>
      > javascript presentation.</span><br>
    <br>
  </body>
</html>