StackExchange, a network of collaborative question and answer sites, has opened a new site for computational science. Some questions on the site now:
We’re offering another training course on GPU programming this fall:
Tech-X Corporation is pleased to announce our next three-day training course for GPU computing with CUDA will be held from September 19 – 21 at our offices in Boulder, Colorado, USA. If you are interested, please complete the form so we can contact you with further details.
The cost for this particular training will be US$1,200 for all three days. This price includes lunch each day. You can register and pay at our online store.
Full disclosure: I work for Tech-X Corporation.
Astonomy Computing Today recently has had a series of articles about using GPUs in astronmy: The Use of Graphical Processing Units (GPU’s) In Astronomy, GPU’s in Astronomy: Critical Decisions for Early Adopters, and GPU’s vs. CPU’s: Apples vs. Oranges?. I think these articles give a great, brief introduction to using a GPU for calculations including a discussion of pros/cons and what types of codes benefit the most from using a GPU.
If this sounds interesting to you and would like to check out GPU computing from IDL without having to learn CUDA, check out GPULib.
Full disclosure: I work for Tech-X and have developed parts of GPULib.
Tech-X is providing GPU training:
Tech-X Corporation is pleased to announce our next three-day training course for GPU computing using CUDA will be held from May 16 – 18 at our offices in Boulder, Colorado, USA. The cost for this training will be US$2,500 for all three days. This price includes lunch each day. If you are interested, please complete our form so we can contact you with further details.
Full disclosure: I work for Tech-X and will be involved in this training course.
Igor Chilingarian and Ivan Zolotukhin open their recent paper on the botteneck in scientific computing with:
Present-day astronomical instruments and large surveys produce the data flow increasing exponentially in time. The CPU power required to analyse these data is also growing with the same pace following the Moore’s law; the same applies to the data storage volume per price unit. However, in astronomy we do not see the exponential avalanche of scientific results produced with this computational power.
After providing good and bad examples of code in projects and discussing issues with bad code, they conclude:
It turns out that all “good examples” were developed either by professional astronomers with very strong IT/CS background or by IT/CS professionals working closely with astronomers for years and understanding astronomy. One cannot simply hire an industrial software engineer to develop astronomical software and/or an archive and/or a database.
A possible solution is to change the teaching paradigm for students in astronomy. Basic courses in algorithms, programming, software development and maintenance have to be made mandatory in the education of modern astronomers and physicists; advanced courses should be recommended to some of them. The Fortran language is now obsolete and we have to accept this. Instead of teaching research students to Fortran programming, one should teach how to interface legacy Fortran code in C/C++.
As soon as this bottleneck is resolved, the avalanche of discoveries will loom.
I agree. What to do with all the existing astronomers, though? I don’t think it is too late to learn good practices for those interested.
Link via Astrocompute.
GPULib 1.4.4 was released today! Many bugs were fixed in this release through our new QA/release process: a big one when doing full reduction in GPUTOTAL, several issues in GPUINIT, many issues if you build GPULib from source, better error handling, a couple memory leaks, and many more. Get the download from the Tech-X website.
Disclosure: I work for Tech-X Corporation and help develop GPULib.
Zeeya Merali makes an excellent point in her recent article for Nature Why Scientific Computing Does Not Compute.” (Nature, 467, 775; October 14, 2010) :
As a general rule, researchers do not test or document their programs rigorously, and they rarely release their codes, making it almost impossible to reproduce and verify published results generated by scientific software, say computer scientists. At best, poorly written programs cause researchers such as Harry to waste valuable time and energy. But the coding problems can sometimes cause substantial harm, and have forced some scientists to retract papers.
Her suggestions make a lot of sense, though I know plenty of code gets written that does not follow them:
It is clear that scientists need more training/advice on software than they currently receive. The online Software Carpentry course and materials were also mentioned as a model for solving this problem.
Link via Bruce Berriman’s Astronomy Computing Today site.
GPULib 1.4.2 was released today with several important bug fixes, improved demos, and a smoother installation. Get it from the GPULib page on Tech-X website.
A more thorough set of release notes is available on the GPULib blog.
Full disclosure: I work for Tech-X Corporation and have worked on the IDL bindings for GPULib.
GPUlib 1.4 is now available! See the GPULib blog for a rundown of the new features. Particularly exciting for me are:
Full disclosure: I work for Tech-X Corporation and have worked on the IDL bindings for GPULib.
ITT VIS had several presentations about IDL 8.0 at this week’s IDL User Group Meeting. David Fanning says:
Just one word: Wow!
It appears that the promise of IDL 5 has finally been realized. :-)
David also posted a longer description of the new features, so I won’t go through the laundry list (but I do intend to run through it with some examples when 8.0 is actually released, like I did for 7.1).
But I will discuss a bit the one feature that I have used extensively: operator overloading. This was the main focus of my talk about GPULib with IDL 8.0. The gist is that GPULib variables will be objects and if you are running IDL 8.0+, you can do things like the following:
IDL> a = gpuFindgen(10)
IDL> b = gpuFindgen(10)
IDL> c = a + b
This was easy to implement, just inherit from IDL_Object and write a method with the special name _overloadPlus:
function gpuvariable::_overloadPlus, left, right
compile_opt strictarr
return, gpuAdd(left, right)
end
Most operators are supported like +, -, /, *, MOD, EQ, etc., but also including brackets (both on the left side and right side of an assignment) and other special methods used by PRINT, HELP, and SIZE. The dot operator is automatically connected to the getProperty and setProperty methods of the class.
Another nice point is that GPULib will not require separate versions for pre-8.0 and post-8.0 versions of IDL. Just write a simple dummy IDL_Object class. This will allow the code to be compiled in versions of IDL before 8.0 and won’t be found (because the real IDL_Object is part of IDL’s core and found before any user routines) in versions 8.0+. Of course, only the old procedure or function interfaces are available in versions before 8.0. I’m much more likely to use operator overloading because I can provide extra features for IDL 8.0 users and fall back to a more verbose interface for those who have not upgraded yet.
If you have the tech preview handed out at the meeting or are just interested in some more examples of this, check out these HDF5 classes which make use of operator overloading. The end of the mg_h5.pro file has a main-level program which shows how to use the classes:
IDL> .run mg_h5
Full disclosure: I work for Tech-X Corporation and have worked on the IDL bindings for GPULib.
You are currently browsing the archives for the HPC category.
