Hi, I have the following snippet of code and would like to know what I am doing wrong below. Without parallelizing, if this loop look takes 0.01 seconds. When I use k threads, this function is taking k*0.01 seconds. (1) Is there a faster way to evaluate a local expansion at a bunch of points. Or i must assess them 1by1 (2) I tried num threads from k=2 to k=10. This behavior is consistent. always takes (k*0.01). Is this behavior consistent? #pragma omp parallel num_threads(k) for (int i =0 ; i < values.num_elements(); i++) { values[i] = lexp->PhysEvaluate(glCoords.at(i),el_Phys); } // Info lexp is localExpansionShPtr; // num_elements ~21 // In the program, I am replacing k with 2 .. 10 number Ashok.
Hi Ashok, I can't guarantee Nektar will work perfectly with openmp, since we haven't tried this yet. In any case, I think what you need is: #pragma omp parallel for num_threads(k) Without the "for" clause all threads will execute the whole loop, instead of sharing the work. Cheers, Douglas ________________________________ From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of ashok jallepalli <ash.nani@gmail.com> Sent: 02 December 2016 13:27:48 To: nektar-users Subject: [Nektar-users] Using OpenMP on Nektar Libraries. Hi, I have the following snippet of code and would like to know what I am doing wrong below. Without parallelizing, if this loop look takes 0.01 seconds. When I use k threads, this function is taking k*0.01 seconds. (1) Is there a faster way to evaluate a local expansion at a bunch of points. Or i must assess them 1by1 (2) I tried num threads from k=2 to k=10. This behavior is consistent. always takes (k*0.01). Is this behavior consistent? #pragma omp parallel num_threads(k) for (int i =0 ; i < values.num_elements(); i++) { values[i] = lexp->PhysEvaluate(glCoords.at(i),el_Phys); } // Info lexp is localExpansionShPtr; // num_elements ~21 // In the program, I am replacing k with 2 .. 10 number Ashok.
Thank you, Douglas. I will be cautious in using openMP in Nektar. I was using " #pragma omp parallel for num_threads(k) ". I typed it wrong when sending the previous mail and it is k taking times to execute. So moving away from this OpenMP. Cheers, Ashok. On Fri, Dec 2, 2016 at 7:13 AM, Serson, Douglas <d.serson14@imperial.ac.uk> wrote:
Hi Ashok,
I can't guarantee Nektar will work perfectly with openmp, since we haven't tried this yet.
In any case, I think what you need is:
#pragma omp parallel for num_threads(k)
Without the "for" clause all threads will execute the whole loop, instead of sharing the work.
Cheers,
Douglas ------------------------------ *From:* nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@ imperial.ac.uk> on behalf of ashok jallepalli <ash.nani@gmail.com> *Sent:* 02 December 2016 13:27:48 *To:* nektar-users *Subject:* [Nektar-users] Using OpenMP on Nektar Libraries.
Hi,
I have the following snippet of code and would like to know what I am doing wrong below. Without parallelizing, if this loop look takes 0.01 seconds. When I use k threads, this function is taking k*0.01 seconds.
(1) Is there a faster way to evaluate a local expansion at a bunch of points. Or i must assess them 1by1 (2) I tried num threads from k=2 to k=10. This behavior is consistent. always takes (k*0.01). Is this behavior consistent?
#pragma omp parallel num_threads(k) for (int i =0 ; i < values.num_elements(); i++)
{
values[i] = lexp->PhysEvaluate(glCoords.at(i),el_Phys);
}
// Info lexp is localExpansionShPtr; // num_elements ~21 // In the program, I am replacing k with 2 .. 10 number
Ashok.
Hi Ashok, Just to expand a bit; we have done a little work on investigating threading but much of the code is not guaranteed to be thread-safe. There may therefore be a bunch of race conditions that we're just not aware of in some of the routines. Care is needed in investigating the routines you're trying to thread to check we are not e.g. using an output array as temporary storage. Generally we have found that unless you have a solid chunk of work needed to be done by each thread, you will spend much of the time waiting for threads to spawn and finalise. However conceptually I would envision that elemental evaluations should be trivially parallelisable; it may therefore be a case of restructuring things to thread this in a more effective manner. Let us know how you get on. This is an open topic for us at the moment and trying to converge to an optimal strategy is likely to be difficult, so practical experience is going to be valuable feedback! Cheers, Dave
On 5 Dec 2016, at 03:57, ashok jallepalli <ash.nani@gmail.com> wrote:
Thank you, Douglas. I will be cautious in using openMP in Nektar.
I was using " #pragma omp parallel for num_threads(k) ". I typed it wrong when sending the previous mail and it is k taking times to execute. So moving away from this OpenMP.
Cheers, Ashok.
On Fri, Dec 2, 2016 at 7:13 AM, Serson, Douglas <d.serson14@imperial.ac.uk> wrote: Hi Ashok,
I can't guarantee Nektar will work perfectly with openmp, since we haven't tried this yet.
In any case, I think what you need is:
#pragma omp parallel for num_threads(k)
Without the "for" clause all threads will execute the whole loop, instead of sharing the work.
Cheers,
Douglas
From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of ashok jallepalli <ash.nani@gmail.com> Sent: 02 December 2016 13:27:48 To: nektar-users Subject: [Nektar-users] Using OpenMP on Nektar Libraries.
Hi,
I have the following snippet of code and would like to know what I am doing wrong below. Without parallelizing, if this loop look takes 0.01 seconds. When I use k threads, this function is taking k*0.01 seconds.
(1) Is there a faster way to evaluate a local expansion at a bunch of points. Or i must assess them 1by1 (2) I tried num threads from k=2 to k=10. This behavior is consistent. always takes (k*0.01). Is this behavior consistent?
#pragma omp parallel num_threads(k) for (int i =0 ; i < values.num_elements(); i++) {
values[i] = lexp->PhysEvaluate(glCoords.at(i),el_Phys);
}
// Info lexp is localExpansionShPtr; // num_elements ~21 // In the program, I am replacing k with 2 .. 10 number
Ashok.
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
-- David Moxey (Research and Teaching Fellow) d.moxey@imperial.ac.uk | www.imperial.ac.uk/people/d.moxey Room 364, Department of Aeronautics, Imperial College London, London, SW7 2AZ, UK.
participants (3)
-
ashok jallepalli
-
David Moxey
-
Serson, Douglas