From: Deborah Joanne Bard [mailto:djbard@slac.stanford.edu]
Sent: Friday, November 22, 2013 7:18 PM
To: Todd Martinez
Cc: Marshall, Stuart L.; Adesanya, Adeyemi; Abel, Tom; Kaehler, Ralf; Brian Moritz; Thomas Peter Devereaux; Eriksson, Thomas; Voss, Johannes; O'Grady, Christopher P.; Perazzo, Amedeo; Gaponenko, Igor; Radmer, Randall James; Ho, Ling Cherd; Hoeche, Stefan; Dubois, Richard; Boehnlein, Amber; Luitz, Steffen; Gruber, Shirley; Yan, Jun; van den Bedem, Henry
Subject: Re: GPU computing at SLAC: meeting 22nd Nov 2pm
Hi All,
the minutes of today's meeting are below. Please let me know if you have any comments or suggestions!
cheers,
Debbie
Minutes
----------
attending: Tom Abel, Yemi Adesanya, Debbie Bard, Stefan Hoeche, Igor Gaponenko, Stuart Marshall.
Summary: There is demand for a small central GPU resource, where
users can practice and develop code and run small-scale analyses. It is
likely that there is not demand for a larger facility. It is also likely
that the affordable option of an interactive/batch server using desktop
GPUs would be sufficient to meet the needs of users, but there are
drawbacks to such a scheme. We will prepare a proposal outlining the use
cases for such a resource, with input from groups across slac.
Here's an outline of our discussions:
- How are people using GPUs at SLAC right now?
Kipac: the KIPAC GPU cluster is used mostly by individuals using GPUs for
analysis work on small/medium scales. Visualisation group has their own GPUs.
LCLS: Three GPUs are currently used by individual users with a specific code base.
- Do existing GPU users have an interest in using central GPU resources?
What kind of demand is there (among existing and potential GPU users) for
this kind of resource?
Kipac: There is some interest in further small-scale use of GPUs for
processing/fitting data.
LCLS: Users in LCLS do not have full access to SLAC resources, so they are
unlikely to use central resources. Only pre=processing, filtering etc is
done at SLAC, otherwise the user typically takes data back to the home
institution for analysis. However, a configurable workflow is being
developed which may include GPU modules.
Theory: Potential to use GPUs for event generation. This is a large code
that would have to be re-written for the GPU, as yet it's unclear whether
this is worth it in terms of possible speed-up, and in terms of end user
resources. A central GPU resource would help scope out the possible gains.
- What kind of resources are useful to people now? What would be useful to the wider SLAC community?
Yemi: There's already demand from groups (Kipac, theory, SIMES) for
resources to try out GPU implementation without investing in the hardware
themselves.
Igor: there are plenty of libraries/tools for GPUs, perhaps we could bring
some in and set them up.
- What problems do we need to be aware of (e.g. over-subscribed interactive nodes)?
Yemi: New LSF protocol manages access to GPU slots in exclusive process
mode, so a clash of resources is avoided. However, this won't work for
interactive nodes and is not an efficient use of CPU/GPU.
Tom: It may be better to invest in consumer-grade GPUs that don't have the
capacity/[precision, but are sufficient for user needs. 1/10th price!
Igor: Have to be careful about the precision, and whether memory will be
sufficient. Need a good, fast connection to where the data is stored!
Stuart: Can't fit consumer GPUs into a regular server farm. Need to
consider options there.
Igor: remember NVidia/cuda is not he only game in town! OpenCL/ATI GPUs
may be a good option.