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
