Alex Granovsky
gran@classic.chem.msu.su
Roughly speaking, the whole concept of using GPUs in scientific
computations is a bit weird and misleading. Instead of adapting
architecture of their very specialized accelerators to the needs
of code developers, GPU makers preferred to promote some of
programmers to develop code that fits the limitations and specific
programming concepts of their products.
Various accelerators had been in market for many years. E.g., one may
recall Weitek coprocessors etc... The permanent war of CPUs and
accelerators is a kind of sea-saw - the endless war without success
for any party. At Firefly Project, we are ready to use accelerators
like GPUs to speedup BLAS operations, but that's the only purpose we
will be giving them in the future.
As to me personally, I was deeply disappointed by two things
recently - the first one is the way how the double precision FP
performance was intentionally cut off in the GPUs as opposed to
Tesla boards (to the best of my knowledge, NVIDIA is the only
company cutting FP performance in their "desktop" as opposed to
"server" products based on the same micro-architecture). I do not
think this was wise decision anyway.
The second one is the lack of professionalism and (to my opinion)
inadequate reaction of NVIDIA to our emails concerning CUDA kernel-
mode data exposure security breach. I do not see any way how I can
trust NVIDIA drivers anymore provided that such a childish, naive and
non-professional mistake existed in drivers for years and was not
fixed in just in 15 minutes after having been reported.
Kind regards,
Alex Granovsky
On Fri Jun 17 '11 2:27am, Ron Bakus wrote
-----------------------------------------
>I hate to be the guy to ask it, but is there any planned enhancement of CUDA functionality in 8.0? Specifically, in interested in what the road-map looks like for:
>1) Having structure optimization at the HF/DFT level of theory being CUDA enabled
>2) Extension of FF CUDA support to other architectures, specifically linux
>Secondarily, is work being done on improvements to the direct SCF code, in terms of speed (the hints page still indicates that the direct is slower than conventional)?
[ This message was edited on Sun Jun 19 '11 at 4:56pm by the author ]