hpcgarage / spatter

Benchmark for measuring the performance of sparse and irregular memory access.
Other
66 stars 11 forks source link

Memory Utilization #186

Open radelja opened 3 weeks ago

radelja commented 3 weeks ago

There is an issue with the refactor using more memory than the current version.

Using the uniform stride test (cpu-ustride.json) as an example, the Jupyter notebook mentions:

This test will require 2GB of memory. The plots in the paper used 16 GB but we want this notebook to run quickly on laptops with less memory.

I ran the uniform stride test and confirmed the current version uses 1.9 GB of memory. When I ran the same test with the refactor, I found that it used 7.4 GB of memory.

However, the uniform stride test specifies UNIFORM patterns with NR and the refactor does not handle these patterns correctly. There are two branches that resolves the handling of these patterns:

https://github.com/radelja/spatter/tree/refactor-nr-fix https://github.com/plavin/spatter/tree/refactor-new

Running the uniform stride test with either of these branches revealed the refactor uses 29.8 GB of memory compared to the 2 GB of memory used by the current version.

jyoung3131 commented 1 week ago

Discussion noted that the refactor is using different buffers for each configuration, which is making the overall memory usage grow dramatically along with the runtime.

There are two fixes we discussed: 1) Use the same buffers between configs which should make resize() operations much faster. 2) Incorporate the old Spatter function to calculate the max buffer size for vectors, and remove vector resize() operations.

radelja commented 1 week ago

I measured the memory usage of the current (main branch) and refactor (refactor-new branch) versions of Spatter running cpu-ustride.json with the serial backend using valgrind's massif. The following graphs were generated with massif-visualizer:

Current main

Refactor refactor-new