search

flatironinstitute / cufinufft

Nonuniform fast Fourier transforms of types 1 and 2, in 1D, 2D, and 3D, on the GPU
Other
83 stars 18 forks source link

CU vs CPP #18

Closed janden closed 4 years ago

janden commented 4 years ago

A lot of the source code is currently written as CU files that could just be straight CPP files (that is, they don't contain any kernel invocations). I'm not sure what effect this has, but it does make the build process more convoluted than it perhaps needs to be. (The compiler errors do become more difficult to parse since since GCC will report errors in the preprocessed source files which end up in /tmp on my setup).

@garrettwrong Do you know if this could be a potential issue? Otherwise we will leave it as is.

garrettwrong commented 4 years ago

The usual reason to use nvcc with non kernel code is just to help with lib paths, linking, and includes. I'm getting my coffee and will check out Melody's pull request. I can take a look while I'm there.

garrettwrong commented 4 years ago

So lets figure out where 1) use cuda toolkit methods 2) cuda kernel and related code.

git grep -L "cudaMalloc" \*cu

Tells me that all the files except the following are at least using cudaMalloc( group 1)

src/2d/cufinufft2d.cu
src/2d/spreadinterp2d.cu
src/3d/cufinufft3d.cu
src/3d/spreadinterp3d.cu
src/cufinufft.cu
src/deconvolve_wrapper.cu
src/profile.cu

The above are obviously group 2 by inspection.

For group 1, you do not have to use nvcc, but instead you would need to manage the headers, lib paths, and linking yourself in gcc/g++. That is what nvcc does for you in this case, a frontend that wraps the underlying compiler. It is up to you whther you think it is better or worse. I would lean towards nvcc:

In the early days it was more popular to do this manually (write a C file include the driver and runtime headers, link it yourself), but it makes for less portable and lasting code. For example, when (not if) nvidia refactors, suddenly your header includes are tied to a version. NVCC usually gets the right things..

Can you post what you are seeing so I can take a peek? I don't get any complaints on my fedora box, and I don't recall on tigerGPU.

garrettwrong commented 4 years ago

(note this was quick and dirty, the search is not accurately categorizing, just crudely covering)

janden commented 4 years ago

For group 1, you do not have to use nvcc, but instead you would need to manage the headers, lib paths, and linking yourself in gcc/g++. That is what nvcc does for you in this case, a frontend that wraps the underlying compiler. It is up to you whther you think it is better or worse. I would lean towards nvcc:

Ok this makes sense.

Can you post what you are seeing so I can take a peek? I don't get any complaints on my fedora box, and I don't recall on tigerGPU.

Going over this again, it seems that I was seeing things like this

src/cufinufft.cu(88): error: identifier "err" is undefined

1 error detected in the compilation of "/tmp/tmpxft_0005dd73_00000000-6_cufinufft.cpp1.ii".

and focusing on the last part ignoring the fact that the full error message given by nvcc clearly gives the right source code location.

So this is a non-issue, I think. Closing.