Add example that profiles parallel sum #774
Conversation
examples/demo_flops.py
Outdated
| FLOPS = 1e9 * sums / (event.profile.end - event.profile.start) | ||
| GFLOPS = FLOPS / 1e6 | ||
|
|
||
| data[row, col] = GFLOPS |
There was a problem hiding this comment.
Arguably, this workload will be bandwidth-bound, so GB/s will be the more appropriate measure.
There was a problem hiding this comment.
This decision was made because it's common to evaluate gpu performance based on TFLOPS (and this number is computed with similar workloads) and especially highlights the fact that of course the flops go up when working with smaller types
examples/demo_flops.py
Outdated
| header = f'#define T {literal}\n' | ||
| kernel = cl.Program(ctx, header + src).build().sum | ||
|
|
||
| event = kernel(queue, (sums,), None, x, y, z) |
There was a problem hiding this comment.
It's generally good practice to do a few "warmup" rounds before timing, to better measure the steady-state rate.
There was a problem hiding this comment.
There are problem with caches however. In cpu runs I get crazy GFLOPS for medium size arrays because they already live in the cache, gpu doesn't seem to suffer from this problem.
But with the new commits one could decide to do no warmup runs and only one hot run so it's ok
There was a problem hiding this comment.
Could you look over the CI failures?
Description
This program profiles the parallel sum kernel when summing two arrays of increasing size, interpreting the data as char, int, float... the results are plotted with matplotlib, it's an external dependency but it's a common one.
Rationale
When experimenting with GPU computing is useful to estimate an upper bound on performance, this PR offers an example of how you could use pyopencl events to profile a kernel (I suppose we are profiling only the execution time without the data transfers).
The results show a powerful idea in parallel computing: using shorter types improves throughput
Possible corners