Tuning parameters for temporal blocking about yask HOT 4 CLOSED

from yask.

I see, I understand your point. Basically, in cache mode, performing temporal blocking will allow the temporally-blocked region to stay in MCDRAM when the input is larger than MCDRAM size, brining the achieved performance closer to what can be achieved with smaller stencils that fully fit in MCDRAM.

However, I believe this is different from the traditional way of taking advantage of temporal blocking, which is to speed up memory-bound stencils beyond the roofline imposed by the external memory bandwidth. I am actually more interested in maximizing the performance of a given stencil, with a size that fits in MCDRAM (512^3 or 1024^3), and since the reported performance seems to be lower than what I expected, I thought maybe I should use temporal blocking to see if the performance can be improved any further.

I'd really appreciate it if you shed some light on the following issues:

- I seem to be encountering a discrepancy in the reported GFLOPS and points per second for the 3axis stencil. From what I understand, the 3axis stencil is the standard 3D star-shaped stencil that has (6 * radius + 1) points, and a computation intensity of (12 * radius + 1) FLOP per point (6 * radius + 1 FPMUL and 6 * radius FPADD). Hence, for this stencil, I expect the reported GFLOPS to be equal to (points/sec * 13) for radius=1, and (points/sec * 25) for radius=2. However, the numbers reported by YASK seem to be a lot lower than this:

radius=1, size=512^3:

────────────────────────────────────────────────────────────
Running 1 performance trial(s) of 50 step(s) each...
────────────────────────────────────────────────────────────
num-points-per-step:                    134.218M
num-writes-per-step:                    134.218M
num-est-FP-ops-per-step:                1.07374G
num-steps-done:                         50
elapsed-time (sec):                     0.390961
throughput (num-points/sec):            17.1651G
throughput (est-FLOPS):                 137.321G
throughput (num-writes/sec):            17.1651G
time in halo exch (sec):                0 (0%)
────────────────────────────────────────────────────────────~~

radius=2, size=512^3:

────────────────────────────────────────────────────────────
Running 1 performance trial(s) of 50 step(s) each...
────────────────────────────────────────────────────────────
num-points-per-step:                    134.218M
num-writes-per-step:                    134.218M
num-est-FP-ops-per-step:                2.01327G
num-steps-done:                         50
elapsed-time (sec):                     0.336311
throughput (num-points/sec):            19.9544G
throughput (est-FLOPS):                 299.316G
throughput (num-writes/sec):            19.9544G
time in halo exch (sec):                0 (0%)
────────────────────────────────────────────────────────────

Specifically, the conversion ratio in YASK seems to be 8 for radius=1, and 15 for radius=2. Can you please elaborate how the reported GFLOPS is calculated here?

• Should I expect temporal blocking to at all improve performance for the 3axis stencil, when the grid already fits in MCDRAM?

Edit: I realized that the coefficients in YASK are shared and because of this, the FLOP per point in the default 3axis stencil is different from what I had in mind. Hence I scratched the first issue.

from yask.

As currently implemented in YASK, I have not seen a case where temporal blocking improves problems that fit inside MCDRAM. In theory, you might expect a temporal-block size approximately the size of the sum of L2 caches might improve performance, but I have not been able to produce that effect.

from yask.

I see, thank you for the clarification.

The ticket can be closed.

from yask.