Hi, Thank you for your hint. I'm aware of that, but the calc_force algorithm is executed within every program step so this part does not (only) initialize but also reset the values.
Tomorrow I will try the zipped iteration... please note in my place the time is nine hours later. ;) Today I tried to run Chapel on more than one locale. With a simple algorithm it worked very fine but with my particle simulation... let's find a solution for the first problem I contaced you with, before I get to the next one. :) bye Zitat von Lydia Duncan <[email protected]>: > Hi Michael, > > One thing to note - Chapel variables are initialized by default. > Since you provided a type for the fields of a particle, you don't > need to set their values to 0.0 as that is done automatically. > > Lydia > > On 08/20/2014 09:58 AM, Ben Harshbarger wrote: >> Hi Michael, >> >> I think you’re going to want a zippered iteration: >> >> forall (part, i) in zip(field.p, field.D) { … } >> >> -Ben >> >> On 8/20/14, 7:38 AM, "Michael Dietrich" >> <[email protected]> wrote: >> >>> Hello, >>> >>> yes, you're right, I continued using the C-syntax. Now it looks much >>> better. >>> >>> One question about this to make it perfect: If i write... >>> >>> forall part in field.p { >>> part.f.x = 0.0; >>> part.f.y = 0.0; >>> part.f.z = 0.0; >>> } >>> >>> ...how can I get the index of "part" within the array "p"? >>> >>> bye >>> >>> >>> Zitat von Ben Harshbarger <[email protected]>: >>> >>>> Hi Michael, >>>> >>>> Looking through your code I saw that you were passing classes as >>>> arguments >>>> with the ‘ref’ intent. Chapel classes are passed as references by >>>> default, >>>> so I don’t think you need the ref intent in most of those functions: >>>> >>>> // this should be fine >>>> proc calc_force(parts : ParticleField) { … } >>>> >>>> Something else you can do to improve your code’s performance and >>>> readability is to iterate directly over an array instead of its >>>> underlying >>>> domain: >>>> >>>> forall part in field.p { >>>> part.f.x = 0.0; >>>> part.f.y = 0.0; >>>> part.f.z = 0.0; >>>> } >>>> >>>> // instead of >>>> >>>> forall i in 0..field.num_parts-1 { >>>> field.p[i].f.x = 0.0; >>>> field.p[i].f.y = 0.0; >>>> field.p[i].f.z = 0.0; >>>> } >>>> >>>> >>>> >>>> Let me know if you have any additional questions. >>>> >>>> -Ben >>>> >>>> >>>> On 8/18/14, 11:18 AM, "Michael Dietrich" >>>> <[email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> okay, if you want to you can read through the code [1]. :) >>>>> For comparation it includes the program in C which I successfully >>>>> parallelized with MPI and the same program in Chapel. >>>>> I hope I didn't forget to comment important lines. If anything is >>>>> unclear just ask me. >>>>> >>>>> Please consider the code won't win a beauty contest (especially the >>>>> one in C) but at least my Chapel code is more readable than the code >>>>> in C mostly written by the responsible employee. ;) >>>>> >>>>> bye >>>>> >>>>> [1] http://www-user.tu-chemnitz.de/~michd/fish.tar.gz >>>>> >>>>> >>>>> Zitat von Lydia Duncan <[email protected]>: >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> I think it will be difficult for us to offer further suggestions >>>>>> without looking at the code ourselves, would you be comfortable >>>>>> sending it? >>>>>> >>>>>> Lydia >>>>>> >>>>>> On 08/18/2014 05:27 AM, Michael Dietrich wrote: >>>>>>> Hello, >>>>>>> >>>>>>> today I compiled my program with the --fast flag. >>>>>>> Though it made both the serial execution much faster than before, the >>>>>>> parallel one became even slower compared with the serial. I'm still >>>>>>> trying to find any possible mistakes within my code but I can't find >>>>>>> any. Any suggestions? >>>>>>> >>>>>>> bye >>>>>>> >>>>>>> >>>>>>> >>>>>>> Zitat von Tom MacDonald <[email protected]>: >>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> Without --fast the compiler generates runtime checks, which slows >>>>>>>> down execution time. >>>>>>>> >>>>>>>> Please compile with the --fast flag and see how much execution >>>>>>>> time improvement there is. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Tom MacDonald >>>>>>>> >>>>>>>> On Fri, 15 Aug 2014, Tom MacDonald wrote: >>>>>>>> >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> Thank you for your interest in Chapel! It's good to hear you are >>>>>>>>> studying high performance programming languages. >>>>>>>>> >>>>>>>>> Are you compiling your Chapel program with the --fast option? >>>>>>>>> >>>>>>>>> We need to know that before looking deeper. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Tom MacDonald >>>>>>>>> >>>>>>>>> On Fri, 15 Aug 2014, Michael Dietrich wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I'm working with Chapel due to my bachelor thesis about high >>>>>>>>>> performance programming languages. My current task is to >>>>>>>>>> implement a >>>>>>>>>> particle simulation program of which I already have the code in C. >>>>>>>>>> It >>>>>>>>>> includes two possible algorithms for calculating the force acting >>>>>>>>>> onto >>>>>>>>>> the particles: A simple but ineffective one and the >>>>>>>>>> Barnes-Hut-Algorithm [1] which is much faster but a bit more >>>>>>>>>> complicated. The other calculations aren't that complex so for me >>>>>>>>>> only >>>>>>>>>> the calculation of force is important. >>>>>>>>>> >>>>>>>>>> I implemented the simple algorithm at first. For comparing the >>>>>>>>>> serial >>>>>>>>>> and parallel execution time I surrounded everything with a >>>>>>>>>> serial-statement, evaluating a bool variable I have to set in the >>>>>>>>>> command line. I didn't implement the multi locale improvement yet >>>>>>>>>> so >>>>>>>>>> it runs only on a dual core PC, using forall-loops. Finally the >>>>>>>>>> parallel one only needed half of the time of the serial, yay. >>>>>>>>>> >>>>>>>>>> I continued with Barnes-Hut. This one was a bit more work because >>>>>>>>>> the >>>>>>>>>> maintenance of the tree-structure leaves a lot of opportunities >>>>>>>>>> for >>>>>>>>>> mistakes. After a bit more time it was working as well. >>>>>>>>>> My issue is about the parallel execution time of this algorithm. >>>>>>>>>> Like >>>>>>>>>> in the other one I replaced the crucial for-loop with a >>>>>>>>>> forall-loop >>>>>>>>>> (the serial-statement surrounds the whole program). The problem >>>>>>>>>> is, >>>>>>>>>> that the parallel execution time is similar to the serial one, >>>>>>>>>> sometimes even longer. >>>>>>>>>> Of course I don't want you to read through all my code, but could >>>>>>>>>> you >>>>>>>>>> tell me some possible reasons, why this effect may occur? >>>>>>>>>> >>>>>>>>>> thank you very much >>>>>>>>>> bye >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] http://beltoforion.de/barnes_hut/barnes_hut_en.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------- >>>>>>>>>> -- >>>>>>>>>> --------- >>>>>>>>>> _______________________________________________ >>>>>>>>>> Chapel-users mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/chapel-users >>>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------------------------- >>>>>>>>> -- >>>>>>>>> -------- >>>>>>>>> _______________________________________________ >>>>>>>>> Chapel-users mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/chapel-users >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> -- >>>>>>> ------ >>>>>>> _______________________________________________ >>>>>>> Chapel-users mailing list >>>>>>> [email protected] >>>>>>> https://lists.sourceforge.net/lists/listinfo/chapel-users >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> -- >>>>> ---- >>>>> _______________________________________________ >>>>> Chapel-users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/chapel-users >>> >>> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> Chapel-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-users ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
