Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS: OpenCL SELECT_PLATFORM #42

Open
janscholten opened this issue Nov 21, 2017 · 2 comments
Open

AWS: OpenCL SELECT_PLATFORM #42

janscholten opened this issue Nov 21, 2017 · 2 comments

Comments

@janscholten
Copy link

I was wondering about how we should control the choice of platform+device when running on the g2.2xlarge. I currently use some environment variables (with the surprising cw3 names HPCE_SELECT_PLATFORM etc). Is that supported (will the benchmark make the best choice? And how do I know?). Or should test myself on the AMI and then hardcode my choices?

I would like to hear your advise since I think option one can be tricky and I don't like the latter idea either (portability).

@m8pple
Copy link
Contributor

m8pple commented Nov 22, 2017

I don't intentionally set any environment variables to select GPU selection, as I don't know
what they would be. In a product you would generally publicise how to select the GPU,
using an env variable or a config line, but that doesn't really apply here.

Hard-coding the device is a reasonable choice for this coursework (and this
is probably what you should do), but as you say it is not really a good choice
in general for portability reasons. However, it is better to have a fall-back too
(e.g. if you are running on an EC2 instance that only has software opencl).

Usually you have some idea about whether a device is going to work better on
a GPU or a multi-core CPU provider, so you can use clGetPlatformInfo to distuiguish
between the different types. For example, you might choose GPU platforms in
preference to CPU platforms.

The most general approach is to perform a small amount of benchmarking
on startup, and run some representative kernel on all the platforms. So
serious applications will either do this offline if it is slow, or do it every time
if it is fast enough. Another approach is to do it at build or install-time - some
BLAS implementations
will look at the system they are being installed in, and try to optimise themselves
for the hardware. FFTW allows
for the creation of optimised "Plans" of execution at run-time based on the
dimensions of the problem, and some GPU libraries do the same thing.

@janscholten
Copy link
Author

Thank you for the advise, and I appreciate the background information also, I didn't realize this is a common problem with various approaches, and the dynamic setup things are quite cool actually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants