run parallel(each thread running with a different set of input parameters)

[Ming_G_]

Hi, I am a novice in openmp, I want to use openmp to run my code in different threads, while each thread being executed with different input parameters, so do I need to figure out all the parameters in my original code and decide which of them should be set as private?(the code has more than 6000 lines so I'm not sure if this will work). Or do you have any other ideas about this problem? Thanks!

[MikeP_Intel]

Sure you could do that, but as you say it could be difficult to manage the variables for each thread. Another suggestion would be to look at the existing (serial) code, that I'm sure has multiple "for loops" that could be parallelized using #pragma omp for constructs. Hit the most CPU intensive loops first.

[Ming_G_]

Mike P. (Intel) wrote:

Sure you could do that, but as you say it could be difficult to manage the variables for each thread. Another suggestion would be to look at the existing (serial) code, that I'm sure has multiple "for loops" that could be parallelized using #pragma omp for constructs. Hit the most CPU intensive loops first.

Thanks Mike, I have tried to modify my original code in a more parallelized manner, but still with some troubles. Like in some do loops there are callings for subroutines, so do I need to manage the parameters in the subroutines as well ? Because the code cannot run converge last time I didn't do that.    

[Gregg_S_Intel]

What the motivation for using OpenMP?  How about multiple processes running at the same time?

[jimdempseyatthecove]

Pseudo C++ code

OpenInputscript(fileName);
int nInputParameters = ReadNumberOfDifferentInputParameters();
#pragma omp parallel for schedule(static,1)
for(int i=0; i<nInputParameters; ++i)
{
   CString inputParameters; // local string
   ReadInputParameters(inputParameters, i); // read the i'th list of input parameters
   DoWork(inputParameters);
}
// work done

Jim Dempsey

[Ming_G_]

Gregg Skinner (Intel) wrote:

What the motivation for using OpenMP?  How about multiple processes running at the same time?

I need to run my code in a server each time with 20 different set of input parameters, I guess by writing openmp I can save time doing the iterative compiling and linking work. By the way, if I run the 20 input parameters with openmp, will it be more efficient in using processors than running multiple processes at the same time? Thanks~ 

[Ming_G_]

jimdempseyatthecove wrote:

Pseudo C++ code

OpenInputscript(fileName);
int nInputParameters = ReadNumberOfDifferentInputParameters();
#pragma omp parallel for schedule(static,1)
for(int i=0; i<nInputParameters; ++i)
{
   CString inputParameters; // local string
   ReadInputParameters(inputParameters, i); // read the i'th list of input parameters
   DoWork(inputParameters);
}
// work done

Jim Dempsey

Thanks Jim! It indeed inspired me about what to do next though I use fortran for my code. My another question is, except from the different set of input parameters that need to be read from txt, I have also defined some parameters in the code, while some of them can be shared,  most of others will change according to the input parameters, so do I need to set all of them as private?   

[jimdempseyatthecove]

You either use private, or you encapsulate them inside the scope of the parallel region. In Fortran this could be

!$OMP PARALLEL DO SCHEDULE(DYNAMIC,1)
DO I=1,nInputParamerters
  CALL ReadInputParametersAndDoWork(I)
END DO
...
SUBROUTINE ReadInputParametersAndDoWork(I)
  implicit none
  integer :: I
  character(len=500) :: InputParameters
  real :: PrivateArray(nnn)
  call ReadInputParameters(InputParameters, I)
  call DoWork(inputParameters, PrivateArray)
end do

You can control the private/shared property by scoping (local variables or modual variables). The above assumes the shared variables are in a module (or common). Whereas the private data was instantiated within the context of a procedure called inside a parallel region. You would want to restrict the use of the PRIVATE clause to where it is only necessary. Placing a large number of variables in a PRIVATE clause is messy, and prone to error.

Jim Dempsey

[Gregg_S_Intel]

Multiple processes would be more efficient, and a lot easier.  No need to introduce OpenMP if these are completely independent tasks.

[jimdempseyatthecove]

Gregg,

Not necessarily so. You would still need to have a loop to create the processes. Create Process takes longer than to Create Thread, plus if the number of input parameters exceed the number of logical processors on your system, your Create Process loop would oversubscribe the system. If you try to correct for this by adding inter-process communication, you've added overhead and latencies not present in the OpenMP design.

Also, if you pre-parse the list of parameter sets, and pre-build a pick list for each process (to avoid oversubscription), you then loose the ability to load balance should the per-process subsets take different amount of run time.

Jim Dempsey

[Gregg_S_Intel]

For embarrassingly parallel, which this appears to be, OpenMP would typically be syntactic overkill.  Difference between Create Process and Create Thread seems trivial when it only happens once.  Avoiding oversubscription seems equally easy with or without OpenMP.

I bring it up because sometimes folks forget the most efficient parallel execution is multiple serial jobs running simultaneously.

For load balancing embarrassingly parallel work, a batch scheduler would be an improvement over OpenMP chunking.

[TimP]

Funny that you mention it.  A major electric grid application was upgraded recently from multiple independent single thread tasks to boost threaded.  Among adverse effects was that it would lose numa locality when swapped out and back in.