{"push_id":778831957,"size":3,"distinct_size":3,"ref":"refs/heads/master","head":"014770d6e26da1db777bb58522a4988a9ac6e6a9","before":"983f23696e813a85f0fd2e93074c8e844094d1e5","commits":[{"sha":"04b685b77fb341e0dff19658d669945c5efba8c3","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Do not let local var outlive its scope in 'begin'\n\nThe uts_deq.chpl benchmark had this code since its inception\n(using then-appropriate syntax):\n\n  proc balance_load ... {\n    ...\n\tvar work = ...; // of a record type\n    ...\n\tbegin with (ref work) create_tree(work);\n    ...\n  }\n\nNow that we do not want local variables to outlive their lexical scope\nin begin-statements, I am replacing the 'ref' task intent with 'in'.\nThis works for the intention of the code, which is to hand off\n'work' to create_tree(), and ignore the result.\n\nWhile there, replaced 'inout' intents with 'ref'.\n'inout' intents had been there since the code was first written.\nI imagine 'inout' was used because 'ref' was not available on records\nback then.","distinct":true,"url":"https://api.github.com/repos/chapel-lang/chapel/commits/04b685b77fb341e0dff19658d669945c5efba8c3"},{"sha":"33731ebc64367052a3ce6295753e427490ad3ae2","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Replace sync with atomic variables.\n\nWhile I was looking at this code, I upgraded it from syncs to atomics.\nThis made it more elegant/short, hopefully faster, and\nreplaced a 'single' variable with a call to waitFor().\n\nI needed an implementation of atomic max, which I copied from Ben's fannkuch:\n  proc atomic_int64.max(other: int)\nIt probably belongs in modules/internal/Atomics.chpl.","distinct":true,"url":"https://api.github.com/repos/chapel-lang/chapel/commits/33731ebc64367052a3ce6295753e427490ad3ae2"},{"sha":"014770d6e26da1db777bb58522a4988a9ac6e6a9","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Merge pull request #2419 from vasslitvinov/use-_in_-task-intent-in-uts_deq.chpl\n\nUse in/ref task/arg intents in uts_deq.chpl\r\naka Do not let local variable outlive its scope in 'begin'\r\n\r\nThe uts_deq.chpl benchmark had this code since its inception (using then-appropriate syntax):\r\n\r\n  proc balance_load ... {\r\n    ...\r\n\tvar work = ...; // of a record type\r\n    ...\r\n\tbegin with (ref work) create_tree(work);\r\n    ...\r\n  }\r\n\r\nNow that we do not want local variables to outlive their lexical scope in begin-statements, I am replacing the 'ref' task intent with 'in'.  This works for the intention of the code, which is to hand off 'work' to create_tree(), and ignore the result.\r\n\r\nWhile there, I replaced 'inout' intents with 'ref'.  'inout' intents had been there since the code was first written.  I imagine 'inout' was used because 'ref' was not available on records back then.\r\n\r\nAlso while there, I upgraded this code from syncs to atomics.  This made it more elegant/short, hopefully faster, and replaced a 'single' variable with a call to waitFor().\r\n\r\nI needed an implementation of atomic max, which I copied from Ben's fannkuch:\r\n  proc atomic_int64.max(other: int)\r\nIt probably belongs in modules/internal/Atomics.chpl.\r\n\r\nReviewer comments:\r\n\r\nIt seems like we might expose enough queries in the runtime to rely on its counts of things running rather than keeping our own counts. If I were trying to make the best Chapel port of UTS, I don't believe UTS says how to apply parallelism, it just says to do the computation as fast as possible. So the approach taken here (\"I'll count the threads and compare to an arbitrary max\") is fairly arbitrary. I'd hate to release this benchmark suggesting that users should keep their own task counts -- particularly for single-locale programs -- rather than relying on the runtime to tell them what's happening in reality (i.e., if other threads are running and doing useful work, maybe we shouldn't create a whole new computation thread to interfere with them?), so using the locale query seems cleaner to me than trying to approximate reality. The atomic that's used as a global count of tasks across the program's execution would need to remain -- I don't believe we have an interface for this (nor that we store it).\r\n\r\nr: @bradcray","distinct":true,"url":"https://api.github.com/repos/chapel-lang/chapel/commits/014770d6e26da1db777bb58522a4988a9ac6e6a9"}]}