Domain: libgeodecomp.org
Stories and comments across the archive that link to libgeodecomp.org.
Comments · 4
-
No, I'm taking MY word for it. :-)
Sorry, I should probably have added a disclaimer that I'm involved in the development of the library as my signature apparently doesn't make it obvious enough: I'm the project lead.
So far we've built about a dozen application with LibGeoDecomp, including porting a dozen large scientific codes towards it. You're right that porting a code usually involves debugging. But that's inevitable when parallelizing a previously sequential code anyway. We don't claim to do magic, we just have some cool tricks up our sleeves. And that's a Good Thing(tm). Because those who claim to cast magic usually disperse just b/s while clever tricks can save you weeks (months even) of work. Here is what you don't have to do if you use LibGeoDecomp:
- You don't have to write a proven (and correct) parallelization that scales to 1850000 (that's 1.8M) MPI processes.
- You don't have to devise your own domain decomposition and load balancing scheme.
- You don't have to write scalable parallel IO and application-level checkpoint/restart code.
- ...and so on and so on. A more complete list is here.
As said, parallelizing a sequential code will almost always involve some sort of debugging, no matter which tool you use. But the library also brings a couple of facilities to ease that transition: 1. you can first adopt the SerialSimulator which performs no parallelization at all, but allows you to check the data transfer and callbacks. 2. you can then transition to those parallelization which run on a single node only (e.g. the CacheBlockingSimulator or the CudaSimulator) to check that there are no race conditions before (3.) you finally more to large scale systems using e.g. the HiParSimulator (used for full system runs on JUQUEEN, an IBM BG/Q and ATM the fastest European machine) or the HpxSimulator (used for runs on TACC's Intel Xeon Phi equipped Stampede; BTW: it's built on HPX, a parallel runtime to C++). 4. Finally you can piggy-back the TestCell onto your model, which will use checksums to validate the data the library gives back to your code.
-
No, I'm taking MY word for it. :-)
Sorry, I should probably have added a disclaimer that I'm involved in the development of the library as my signature apparently doesn't make it obvious enough: I'm the project lead.
So far we've built about a dozen application with LibGeoDecomp, including porting a dozen large scientific codes towards it. You're right that porting a code usually involves debugging. But that's inevitable when parallelizing a previously sequential code anyway. We don't claim to do magic, we just have some cool tricks up our sleeves. And that's a Good Thing(tm). Because those who claim to cast magic usually disperse just b/s while clever tricks can save you weeks (months even) of work. Here is what you don't have to do if you use LibGeoDecomp:
- You don't have to write a proven (and correct) parallelization that scales to 1850000 (that's 1.8M) MPI processes.
- You don't have to devise your own domain decomposition and load balancing scheme.
- You don't have to write scalable parallel IO and application-level checkpoint/restart code.
- ...and so on and so on. A more complete list is here.
As said, parallelizing a sequential code will almost always involve some sort of debugging, no matter which tool you use. But the library also brings a couple of facilities to ease that transition: 1. you can first adopt the SerialSimulator which performs no parallelization at all, but allows you to check the data transfer and callbacks. 2. you can then transition to those parallelization which run on a single node only (e.g. the CacheBlockingSimulator or the CudaSimulator) to check that there are no race conditions before (3.) you finally more to large scale systems using e.g. the HiParSimulator (used for full system runs on JUQUEEN, an IBM BG/Q and ATM the fastest European machine) or the HpxSimulator (used for runs on TACC's Intel Xeon Phi equipped Stampede; BTW: it's built on HPX, a parallel runtime to C++). 4. Finally you can piggy-back the TestCell onto your model, which will use checksums to validate the data the library gives back to your code.
-
Excellent question!
I didn't know the answer myself so I investigated. We've never done this before, but yes: with a bit of glue it is possible. Please take a look here. It's just a quick functional prototype. Let me know if you need a boilerplate for a larger code.
-
Post it to Slashdot!
*wink*library for computer simulations *wink*