Scientific calculations using GPU - what language to use?

Kosmonavt · 2010-12-16 15:34:30

I'm looking for a nice language for scientific programming. The work will be connected with plasma hydrodynamics (for solar astrophysics), which means a lot of resource-hungry modellings using multithreading. But along with performance simplicity is also needed, when learning and using.

I've read https://bbs.archlinux.org/viewtopic.php?id=58900, also C++ FQA (http://yosefk.com/c++fqa/). Now I'm puzzled about support of multithreading and GPGPU in mentioned languages. At the moment I know only C++ at somewhat reasonable level.

Some words about support in Arch Linux of these languages/libraries are also welcome.

lustikus · 2010-12-16 18:22:31

both CUDA (for nvidia) and OpenCL (for AMD/NVIDIA) are C-like languages.
get cuda and the toolkit from AUR, it contains some example code, OpenCL is rather new and less documentary exists.

Kosmonavt · 2010-12-16 19:48:12

Well, I thought about OpenCL. AFAIK, there are Python, C++ and Fortran bindings for CUDA/OpenCL. How they can be compared by performance and efficience in work (garbage collecting etc.)?

*edit*
Also I want to know about math/physics libraries available in these languages. E.g. in C/C++ looks like there are some rather obscure linear algebra libs.

Last edited by Kosmonavt (2010-12-16 19:56:01)

lustikus · 2010-12-17 08:43:57

IMO OpenCL only contains its own C-like language. My guess is that python etc. bindings are slower.
Here you can find more examples and documentation:
http://developer.apple.com/library/mac/ … pic=OpenCL

stfn · 2010-12-17 09:13:36

If performance is a very important factor, then Python or any other interpreted languages are far from the best choice. Instead you will want a language that compiles to real machine code in order to be able to get the most out of it.

I'd recommend you either go with C or C++, depending on your needs and preferences. While C offers you slightly more performance (really isn't too much) C++ might allow you to work more efficiently if you're into OOP. For any C++ programmer the boost library is industry standard anyway, which comes with a lot of useful functionality, including maths:

http://beta.boost.org/doc/libs/1_45_0/? … egory_Math

AdulteratedJedi · 2010-12-17 09:29:24

Give Haskell a try :-)

Last edited by AdulteratedJedi (2010-12-17 09:29:46)

lustikus · 2010-12-17 10:46:47

AdulteratedJedi wrote:

Give Haskell a try :-)

yep, there's also a haskell gpgpu framework in the works:
http://justtesting.org/final-version-of … er-gpgpu-i

Kosmonavt · 2010-12-19 22:13:06

Thanks for your answers. Still thinking about C and python bindings (advertised as without noticeable performance losses), will try testing both when I have time.

2 stfn: Don't think that C++ in this case is efficient. Made sample&simple project (solving of N-body problem), it was a pain. Especially compiling - when using boost, compiling is so slooooow (about 8 secs) even on Core 2 Duo. Also Boost lacks some math functionality, like linear algebra lib which is understandable not only by Donald Knuth.

TheStatsMan · 2010-12-21 11:51:06

I used to do all my scientific computing with C++, now it is all a combination of Python and Fortran. For large problems the penalty is quite small as the code spends all its time inside the compiled Fortran code, but for smaller problems the overhead of Python does have an impact. It is usually for larger problems I need the speed though so this isn't much of an issue. While expression templates are quite nice for dealing with matrices, I find Python is so much better for writting generic code that C++, which becomes heavily templated oriented the further you push the language. Given for scientific problems we are often aware of the computationally complexity of the algorithms we employ it is fairly easy to know what parts of the code need to be written in compiled languages even before running the profiler. I think for the kinds of problems we deal with in scientific programming it is very easy to go to the lower level language when ever necessary. I find for the kind of problems I work with writting the whole program in a lower level language is overkill. Far more effort is required for little gain. Whilst I have little experience with GPU programming, I can see the same logic applying.

By the way there are decent C++ libraries for linear algebra. Eigen2 springs to mind. Admittedly I found it best to write my own, mainly wrapper classes for blas where optimal efficiency was needed and expression templates for algebraic convience where it wasn't. C++ is actually really nice for linear algebra. You can almost get the level of abstraction of higher level languages with near C like speed.

Kosmonavt · 2010-12-21 21:31:18

2 TheStatsMan:

Thanks for detailed answer. It's quite interesting, why you chose Fortran? I started to learn it in institute, but it looked to me anachronistic and without laconic syntax (like in C). Tutor told that there's a lot of routines for Fortran developed since 50s, but aren't e.g. Numpy/Scipy (or anything modern) less efficient and feature-rich? Is there anything that Fortran does way better than C/C++?

Also could you tell what sort of problems do you usually solve?

irnn · 2010-12-27 01:18:21

After having a look at the Python OpenCL bindings it looks like a very good solution.

The performance hit from using Python will be negligible because most of the computation is done on the GPU using the OpenCL kernels. This will only be true if you carefully design your simulations though, the host code should really only be queuing up the kernel to run on the GPU. Also try to minimize copying memory too and from the GPU as this is very expensive.

My experience with OpenCL is writing a 2D lattice boltzmann fluid solver, I wrote the host code in C.

Another possible alternative to consider is http://www.accelereyes.com/ for Matlab, although I am not sure if this will give you the performance you will need.

As for linear algebra, find a library and use it. There are very good ones available for most languages. Whatever you do not try to write your own linear algebra solvers, as they will be no way near as efficient as the ones in the library.

Not to be rude but after reading some of the replies about OpenCL/CUDA on here it, many people do not fully understand what they are talking about so make sure you are fully informed before making a decision!

sanjayvenkat · 2010-12-27 03:42:53

irnn wrote:

Another possible alternative to consider is http://www.accelereyes.com/ for Matlab, although I am not sure if this will give you the performance you will need.

I've been programming with Jacket by AccelerEyes for a few months now and have been very pleased. I have an hp z800 with a core i7 and, still, jacket + gpu in matlab gives 10x results for some of my physics models. Their blog shows some nice results too that have been interesting: http://blog.accelereyes.com/blog/2010/1 … ann_model/

irnn wrote:

As for linear algebra, find a library and use it. There are very good ones available for most languages. Whatever you do not try to write your own linear algebra solvers, as they will be no way near as efficient as the ones in the library.

I've also started to use libjacket (also by accelereyes) which contains the same huge set of functions in a really easy-to-use library, including the broadest set of linear algebra functions i've seen anywhere.

So far so good with gpus for me. have fun.

TheStatsMan · 2011-01-01 21:58:33

Kosmonavt wrote:

2 TheStatsMan:
Thanks for detailed answer. It's quite interesting, why you chose Fortran? I started to learn it in institute, but it looked to me anachronistic and without laconic syntax (like in C). Tutor told that there's a lot of routines for Fortran developed since 50s, but aren't e.g. Numpy/Scipy (or anything modern) less efficient and feature-rich? Is there anything that Fortran does way better than C/C++?
Also could you tell what sort of problems do you usually solve?

Fortran routines aren't less efficient than the routines in Numpy/Scipy, the routines in Numpy/Scipy are typically calls to Fortran routines. Fortran is typically the benchmark when it comes to speed as it is more well defined than C and makes it easier for the compiler to optimise. Well written C or C++ code however tends to be as quick as Fortran code. However, gfortran did not use to be as well optimised as gcc and g++, so this is one area where there used to be a slight discrepancy here.

If I were to write my entire programs in one language my preference would tend to be C++ > C > Fortran as Fortran is certainly less feature rich than C and C++ which are far superior for writing generic code. However when I am extending Python my preference is opposite. I prefer Fortran > C >> C++. In this case I am using Python for the generic code and using the compiled language for writting specific routines. The task is very different. Here I find Fortran shines. It is actually very nice for writting specific numerical code that deals with multi-dimensional arrays. In particular, Fortran is very well defined so it is extremely easy to write mistake free code and when you do make a mistake the compiler tells you exactly what the problem is. The other advantage of Fortran is it is the easiest to call from Python. You simply compile your subroutines with F2PY and use them in Python.

I don't think the libraries in Fortran are much of a reason to choose Fortran as it is so easy to call Fortran libraries from C or C++, however given how well optimised many of the Fortran libraries are I guess it is nice that rather that using Python to call C and the C to call Fortran you just call Fortran from Python.

I am typically looking at estimating the posterior distributions of statistical models using Markov chain Monte Carlo. The most computationally demanding problems I look at are high dimensional space time problems. I typically use a lot of linear algebra routines, for large sparse systems (Krylov subspace methods), some specific time series algorithms (Kalman filter type algorithms), and a lot of standard linear algebra routines (Cholesky decomposition, spectral decomposition, etc). Markov chain Monte Carlo algorithms are usually run for tens of thousands of iterations. I have found Python is very nice for the outer loop and as an interface to generic routines (Metropolis Hastings, etc), while Fortran is nice for the computationally demanding routines (the inner loops I guess). I have actually written I Python library that I will be releasing as open source for these types of problems.

Kosmonavt · 2011-01-05 21:19:50

I've read more on PyOpenCL, and I'm going to use it for a while. Also will try PyCUDA, when will get access to any nVidia GPU (currently having Intel video on laptop). For some range of tasks, especially with almost all realisation on GPU, it looks very promising. About jacket - well, I'm not very good with Matlab (mostly I use Maxima), still I'll keep this possibility in mind.

2 TheStatsMan:

Thanks for explanation! Note about compiler errors seems very positive comparing to C++ ones. A reason to start learning Fortran again! Hope that compile times aren't that big - for a simple C++ modelling project with boost threads it takes almost 10 seconds.

I also heard that in Fortran 2003 there are some elements of OOP. Is there stable support of this standard in existing compilers?

Arch Linux

#1 2010-12-16 15:34:30

Scientific calculations using GPU - what language to use?

#2 2010-12-16 18:22:31

Re: Scientific calculations using GPU - what language to use?

#3 2010-12-16 19:48:12

Re: Scientific calculations using GPU - what language to use?

#4 2010-12-17 08:43:57

Re: Scientific calculations using GPU - what language to use?

#5 2010-12-17 09:13:36

Re: Scientific calculations using GPU - what language to use?

#6 2010-12-17 09:29:24

Re: Scientific calculations using GPU - what language to use?

#7 2010-12-17 10:46:47

Re: Scientific calculations using GPU - what language to use?

#8 2010-12-19 22:13:06

Re: Scientific calculations using GPU - what language to use?

#9 2010-12-21 11:51:06

Re: Scientific calculations using GPU - what language to use?

#10 2010-12-21 21:31:18

Re: Scientific calculations using GPU - what language to use?

#11 2010-12-27 01:18:21

Re: Scientific calculations using GPU - what language to use?

#12 2010-12-27 03:42:53

Re: Scientific calculations using GPU - what language to use?

#13 2011-01-01 21:58:33

Re: Scientific calculations using GPU - what language to use?

#14 2011-01-05 21:19:50

Re: Scientific calculations using GPU - what language to use?

Board footer