Hi Rajath - Thanks for you questions - see below for some answers.
On 3/5/16, 2:59 PM, "Rajath Shashidhara" <[email protected]> wrote: >Hello, > >I did some reading on the Chapel language specifications to understand >the begin statement (This actually helped me better understand the >problem description). > >I have a few questions regarding begin expressions: >(1) Since chapel is not a functional language, functions can have >side-effects (e.g change global variables - [any shared memory in the >context of this question]). Using such functions in begin expressions >might lead to concurrency issues such as race conditions. >e.g: >var x : int = 5; >proc funA(y:int) : int { > x += 1; > return x + y; >} >proc funB(y:int) : int { > x += 2; > return x+y; >} >var z = begin funA(10) + begin funB(15); > >This problem can also arise due to call by reference function calls >(when both functions attempt to modify the parameter). > >Unless the functions are written to enforce mutual exclusion, these >kind of calls will be disastrous. >Any ideas how we can handle this ? I wouldn't expect the begin expression project to take special action here. You could write the same racy code now: var tmp1, tmp1 : int; cobegin { tmp1 = funA(10); tmp2 = funB(15); } var z = tmp1 + tmp2; The begin expression idea is just meant to enable moving data more easily out of a task when it is completed (vs in my cobegin example. My cobegin-equivalent version of your example is a bit needlessly wordy. The Chapel project's current strategy for data races is to: 1) Try to set up the language so it is easy to write correct code and harder to write racy code, if possible. (The task-intents work is an example of this strategy). 2) Expect users to write programs that are not racy. There are many strategies that can be used for that - including using a functional style where most data structures are immutable once created. > (The problem description also >includes a bonus result probably because of this complication. I >believe the runtime library functions are not thread-safe ?) I think our runtime library is in pretty good shape for being thread-safe. Of course there are places it could be improved, but I don't know of any issues in this area. >(2) Currently it is illegal to include a return statement in the begin >statement [1]. This issue can be resolved in two ways : >(a) By lifting this restriction on begin statements or (b) by treating >begin expressions as different grammatical constructs (in some sense >"begin" keyword would then be overloaded). I am not sure how (a) will >affect the language, but (b) is a safer option. No matter what, to do this project, it will be necessary to modify the parser. I don't think it matters much if return is supported at this time in a begin expression - and I think it would be reasonable to check for returns in begin expressions after parsing and emit an error. In other words, there is no need to explicitly prohibit returns in the grammar. (I haven't looked closely at how we check for return in a begin statement - but it may be that the same logic emitting that error can apply to begin expressions). I would expect that a GSoC project implementing begin expressions would make 'return' in a begin expression be an error initially, and consider relaxing that restriction if there is time. However, relaxing it runs into some language design questions - and it's not obviously a good idea for the language to relax the restriction - so it would need some study beside implementation effort. >(3) I wonder what implications this feature have on the Common >Sub-expression compiler optimization pass. It is not always possible >to determine if two begin expressions will produce the same output >even if they have the exact same function calls. That's not really new - it's not always possible to determine that two function calls have the same result even if they have the same arguments. The situation with begin expressions is just a corollary of that. Our Common Sub-expression Elimination pass is not something I'm personally very familiar with but I understand it is pretty limited to performing some specific optimizations to do with iterators. I very much doubt that it would need to be adapted for begin expressions. Put another way - I'd expect that the begin expression work would support easier expression of some programs - but that it would be, at least initially, implemented out of other constructs that we already have (begin/cobegin/sync etc). Hence I would not expect any changes to be necessary for common sub-expression elimination or any other part of the compiler that runs after the begin expressions have been lowered. Cheers, -michael > >I would like to know your opinion about my thoughts. > >Thank you, >Rajath Shashidhara > >[1] Section 24.2 http://chapel.cray.com/spec/spec-0.98.pdf > >On Thu, Mar 3, 2016 at 12:21 AM, Rajath Shashidhara ><[email protected]> wrote: >> Hello, >> >> I have perused your ideas page and I would love to work on >> implementing support for begin expressions in Chapel. >> >> During the course of my academics, I have developed an interest in the >> development of scalable and performance critical software. I am >> familiar with the parallel and distributed programming paradigms and >> frameworks. I have worked on several programming and design projects >> in this domain. This project would help me further my experience in >> this area. >> >> I am good at adapting to new technologies, frameworks or languages and >> I have experience in open source contribution (including GSoC'13 with >> Apache OpenOffice). >> >> I would like to know more about begin expressions (expected semantics >> and syntax). Meanwhile, I will familiarize myself with source code and >> architecture of Chapel compiler. It would be great if you could >> suggest me a bug that will expose me to the relevant source code. >> >> Thank you, >> Rajath Shashidhara >> >> Attachments : >> [1] Resume : >>https://drive.google.com/open?id=0ByDeY7btIDOWR25sa3lpMExWU0U >> [2] Github : https://github.com/rajaths589 > >-------------------------------------------------------------------------- >---- >_______________________________________________ >Chapel-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/chapel-developers ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
