| Message/Author |
|
|
|
|
(MESSAGE INITIALLY FROM IGOR)
Dear Tom,
Thank you for developing it and letting it to be used for free. I like
the cellular automata ideas, and the software seems very good.
However, I'm running the sample files now, and already noticed that it
only uses 1 CPU core. As far as I understand, the parallel programming
in C# had been impossible, but what do you think of recently released
http://www.microsoft.com/downloads/details.aspx?FamilyId=348F73FD-593D-4B3C-B055 -694C50D2B0F3&displaylang=en
Technology Preview I have found a coding example with
Parallel.For,
==========================================
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
namespace parallel1
{
class Program
{
public static int N = 502542656;
static void Main(string[] args)
{
long ticks = DateTime.Now.Ticks;
Parallel.For(1, N, delegate(int i)
{
ModTask(i);
});
Console.WriteLine((DateTime.Now.Ticks - ticks) / 10000000);
Console.ReadLine();
ticks = DateTime.Now.Ticks;
for (int k = 1; k <= N; k++)
{
ModTask(k);
}
Console.WriteLine((DateTime.Now.Ticks-ticks)/10000000);
Console.ReadLine();
}
static void ModTask(int k)
{
double x = k * Math.Sin(k);
}
}
}
==========================================
I would assume that CEASAR' cellular algorithms are naturally
data-parallel and would be very easy to modify. Am I right? If so, do
you think anyone in the development team can do it (I've never
programmed in C#)? Eventually, I would suggest taking the
computational engine back to C/C++ and port it to massively parallel
hardware. The .NET and the "legacy" code can talk via PInvoke (I do
so). |
|
|
|
|
Hi Igor,
Good to hear from you,
Thanks for the link about the parallel processing -I have had a go in C# making use of the multithreading to try and split some tasks up between two processors. I was also quite inspired by the simplicity of parallel programming in C++ using OpenMP, I saw a good talk by someone using that for flood inundation modelling - and it looked dead easy to set up.
OK, the real issue is what sort of savings could be made using parallel methods. First we need to profile the code to see how much time is taken up by the various modules. Last time I did this (and things have changed since slightly) c. 40-60% (I've forgotten how much..) of the time was taken up by the flow routing and the rest by other functions mainly dealing with the erosion and deposition etc...
Now, all the functions that do NOT deal with water routing can probably (mostly) be parellised. However, the water routing is carried out sequentially. EG you have to have a scan from l-r, then one from r-l then up-down then down-up and within each of these scans water has to be sequentially moved from one cell to another. Now, its probably possible to parallel some components of this - and thinking about it now, that might make some speed up, but CAESAR is not a true CA, as some parts of the matrix are reliant upon what happens some distance away even in the same iteration - due to the scanning. This makes this part much harder to make parallel IMHO.
BUT - what we have done is parallelise the process by dividing the catchment up into sections, e.g. upstream and downstream, then on separate machines run the upstream part, gather the output (as a file) and feed into the downstream part that runs on another machine. In effect we parallelise into regions as opposed to just dividing up the processes as they come along if that makes sense?
Now this part could probably be dealt with more formally and then incorporated directly into the code... well its an idea!
Anyway, I hope that helps, and I'm happy to discuss this more - or you're welcome to come over here and chat things through if you like,
Cheers,
Tom |
|
|
|
|
Hello,
Just reflecting on my post above..
THe best way to proceed with this - if you are interested - would be to firstly re-profile the code and work out what functions are taking up most of the time... then work through and see if there really would be any savings in that..
Tom |
|
|
 Igor Rychkov (Igor) posted on Tuesday, September 02, 2008 - 03:25 pm
|
|
|
Tom,
I suppose each water routing scan is sequential in one direction (say, x) but can run parallel in the perpendicular direction (y), so the scanning can proceed in (overlapping) strips. Say, each row of cells along with it's 2 edge rows are assigned to one working thread. In the end all the strips are accumulated into one matrix.
As for the methods, I personally work with C++ using for parallelization OpenMP (for as long as we've had multicore CPUs) and CUDA (well, not as yet, although we've got the hardware already).
However, I would assume that .NET languages could be used too, now when the parallel toolkit available for multi-core programming on CPU, and more importantly, on GPU (through the projects such as http://www.gass-ltd.co.il/en/products/cuda.net/).
Igor |
|
|
|
|
Yup - lets say all the cells on row 3 are looking to route to cells in row 4, at the moment the code runs down all the cells in row 3 seeing if water can be moved into row 4. That part could easily be parallelised, so say row 3 cols 1, 2, 3, 4 could be each sent to a processor then row 3 cols 5, 6, 7, 8 etc..
I had a play with some threading things a while back - and managed to get both cores on my laptop up and running to about 85% total capacity.. but it was actually slightly slower!! And more worryingly gave a different result.. so something was being lost numerically there. But that was just a 'bored on a Friday' type effort ~ to see if I could actually do it and I never pursued it in anger.
Tom |
|
|
|
|
Oh, incidentally, a straight port to C or C++ will give a c.100% speed up in performace.
Why not write in C++ or C you might ask? Well CAESAR was originally in C, but since moving it to a 'visual' language it has made it much much more accessible to other researchers, and I have had far more people use it, modify it and contribute to the whole process.
Tom |
|
|
| Back to top |
|
