search

jadot-bp / fastsum_gpu

Repository for the "FAST" FASTSUM Analysis Software Tools prepared during the 2024 DiRAC GPU Workshop.
1 stars 0 forks source link

`memcpy` issue in `readC.c` #4

Open jadot-bp opened 9 months ago

jadot-bp commented 9 months ago

There currently appears to be an issue with the memcpy call in readC.c when the memory required exceeds a certain size. Currently, the code supports at least 64x32^3 lattices and should support up to 128x32^3, but encounters a segmentation fault when provided a 64x48^3 128x48^3 lattice.

RJaBi commented 9 months ago

Minor comment that it was actually a 128x48^3 lattice that broke.

jadot-bp commented 9 months ago

The issue appears to be related to the exact size of size_t, which dictates the maximum allocatable memory. For the gcc compiler, size_t is type defined as long unsigned int, whose maximum value is 4,294,967,295 (2^32-1)

If my estimate is correct, a 128x48^3 lattice should have 14,155,776 sites, yielding 56,623,104 link variables. If each 3x3 SU(3) link variable is represented by a double complex number, the required size would be 8,153,726,976 which exceeds the size of size_t.

The size of size_t is even compiler dependent, so care should be taken with solving this. To conform to standard C, we could attempt blocking. The alternative is to try a redefinition of size_t, but I'm unsure what implications this will have.

jadot-bp commented 9 months ago

After further thought, this issue will also impact any fread() statements in gauge.c.

jadot-bp commented 8 months ago

Marking this as wontfix for the time being-- This issue is fundamentally connected to the size of site_t, and with the introduction of the new parallel branches, any workarounds should be compatible with the different parallelisation approaches.