Chapel programming language | Peak developer hours are 0600-1700 PT (UTC-07/08) weekdays | Developer Resources: http://www.chapel-lang.org/developers.html
2 replies
My assumption is the atomic array operations tmp=A[i].read() and A[i].write(tmp) should be more expensive than the cost of regular array operations tmp=A[i] and A[i]=tmp.
However, my tests show that for the same code, if we just change the regular array operations with atomic array operations, sometime (often for a large graph as an input) the atomic array method is good. Sometime the atomic array method is bad (often for a small graph as an input) compared with the regular array method. No matter one locale or two locales.
Can anyone help to explain the results? Thanks!
In one iteration, multiple threads will compare the value of A[i] with their own specific value tmpj. A[i] will be updated with tmpj if A[i] is larger than tmpj. Otherwise, it will have no changes.
A possible parallel execution scenario is that when multiple threads execute the comparison at the same time and then they update A[i] concurrently, the value of A[i] may not be the smallest one. This may lead to the following comparison and assignments will be executed again.
If we use atomic assignment, the smallest value will be assigned to A[i] and the following comparisons cannot trigger the update operations. So fewer update operations will be executed. This may cause the atomic operation to take less time since fewer assignments will be executed.
In Chapel code, we let a=1, b=2, and c=3. Here only c is an atomic variable.
We have two parallel threads.
Thread 1 executes
if a < c.read() then c.write(a)
and thread 2 executes
if b<c.read() then c.write(b)
So, the value of c can be 1 or 2. Or the final value of c depends on which thread will execute the write finally. Is this correct? Thanks!
if a < c.read() then c.write(a)
as an atomic operation.
compareAndSwap is close but I need a "< " condition instead of "==" condition.
Can Chaple support the comparison and set value as an atomic operation?
@zhihuidu: I think the standard technique for doing this type of pattern with atomics would be to do something like:
do {
const oldC = c.read();
if a < oldC {
// do a compare-and-swap / compare-exchange here that ensures that c is still ‘oldC’, and if it is, swap in a; if it’s not, spin around this loop again
}
} until the swap is successfulNote that nothing about this is particularly Chapel-specific. I believe the same sort of approach would be taken in any language with atomics of this flavor (like modern C, C++).
chpl to use?
6 replies
An unrelated question. I have this piece of code:
// A buffer of atomics on locale 0 for computing the reduction
var atomicBuffDom = {0..0:c_int};
var atomicBuff: [atomicBuffDom] atomic real;
proc globalSumReal(sendBuf: c_ptr(real), recvBuf: c_ptr(real),
count: c_ptr(c_int)) {
const n = count.deref();
const inds = 0 ..< n;
writeln("calling globalSumReal(", sendBuf, ", ", recvBuf, ", ", n, ") from ", here);
// grow the temp buff if it's not big enough
if here.id == 0 then
if n > atomicBuffDom.size then
atomicBuffDom = {inds};
// Make sure locale 0 has had the chance to resize before proceeding
allLocalesBarrier.barrier();
writeln(here, ": atomicBuffDom = ", atomicBuffDom, ", atomicBuff.size = ", atomicBuff.size);
allLocalesBarrier.barrier();
assert(atomicBuff.size >= n);
// have all locales atomically add their results to the atomicBuff
forall i in inds do
atomicBuff[i].add(sendBuf[i]);
// Make sure all locales have accumulated their contributions
allLocalesBarrier.barrier();
// Have each locale copy the results out into its buffer
forall i in inds do
recvBuf[i] = atomicBuff[i].read();
}globalSumReal is invoked from all locales. The first time it's invoked, n is 2 and hence a resize of atomicBuff should happen on locale 0. However, the output that I'm getting is:
calling globalSumReal(0x7fe691ffbe40, 0x7fe691ffbe40, 2) from LOCALE0
calling globalSumReal(0x7fe6941fbe40, 0x7fe6941fbe40, 2) from LOCALE1
LOCALE0: atomicBuffDom = {0..1}, atomicBuff.size = 2
LOCALE1: atomicBuffDom = {0..1}, atomicBuff.size = 1
src/Diagonalize.chpl:63: error: assert failed
StacktraceAny ideas how this could happen? It seems as if the domain assignment has happened on locale 0, but the array has not yet been resized... is this possible?
@bradcray: It seemed so to me as well, though I thought it might've been some undocumented semantics of global variables... The workaround that I've found since yesterday is to replace
var atomicBuffDom = ...;
var atomicBuff : [atomicBuffDom] atomic real;with
record AtomicBuff {
var dom : domain(1, c_int);
var arr : [dom] atomic real;
}
var atomicBuff = new AtomicBuff();and then accessing both the domain and the array via AtomicBuff record seems to fix it. My code is still crashing, but I think it's a different error now.
Also, it's a bit too late here in Europe to test the --no-remote-value-forwarding; I did try to disable caching at some point, but that didn't have any effect.
I could try to make a reproducer sometime next week if that would help. Or do you think you already know what might be the cause of the bug?
atomicBuff inside the writeln call.
I'm finally planning a commit that requires testing, but I'm having issues setting up the environment according to the web instructions that rely on setchplenv.bash etc.
I previously had Chapel installed via a Linux package manager that did ./configure; make; sudo make install under the hood. I uninstalled this package and deleted any chpl binaries I could find, then tried to follow the website's instructions.
First issue: I have LLVM and Clang 14 in /usr/bin but it can't find them automatically, leaving CHPL_LLVM as NONE. When I set this variable manually to SYSTEM it complains that I don't have LLVM 11.0 (why this version?, I remember 13 and 14 used to be allowed)
Not sure if it affects anything, but I did accidentally compile one time after sourcing the bash file without LLVM, and that's the Chapel compiler I have on my system now.
Second issue: Something in this whole process seems to have polluted my .profile. I originally added a source ${CHPL_HOME}/util/setchplenv.bash to my .profile and observed a bunch of declare statements printed out. I removed the source of setchplenv.bash from .profile, but I still get a wall of declare statements, and I can't easily find where they're coming from.
Any advice would be greatly appreciated, thanks!
8 replies
I must be rustier than I thought, because apparently I cannot even install chapel anymore :o . I did
./configure --prefix=~/.chapel
make
make mason
make chpldoc
sudo make installthen I added ~/.chapel/bin to my path but encountered
lferrant@LAPTOP-HGM2FD2S:~$ chpl --version
error: $CHPL_HOME must be set to run chplam I missing something?
14 replies
3 replies
var a = ["A" => 0, "B" => 2, "C" => 3],
b = ["B" => 2, "A" => 0, "D" => 3]; // note the different key D instead of C
writeln(a == b);
use UnitTest;
proc test1(test: borrowed Test) throws {
test.assertEqual(a, b);
}
UnitTest.main();false false true
test1()
tmp.chpl:9: error: halt reached - zippered associative array does not match the iterated domain
I got a confusing error message from the Chapel 1.28 compiler I'm hoping someone can explain. First, the code:
class Foo {
const aD: domain(1);
var a: [aD] int;
var chunks: [0..#numChunks][1..0] int;
proc init(a: [?D] int) {
this.aD = D;
this.a = a;
const elemsPerChunk = N / numChunks;
this.chunks = [myID in 0..#numChunks] a.localSlice(elemsPerChunk * myID .. #elemsPerChunk);
}
}
var a = [i in 0..#N] i;
var x = new Foo(a);and the resulting error message:
$ chpl testFoo.chpl
$CHPL_HOME/modules/internal/ChapelArray.chpl:842: error: Cannot replace an instantiated field with another type
$CHPL_HOME/modules/internal/ChapelArray.chpl:842: note: field '_instance' has type 'unmanaged [domain(1,int(64),false)] int(64)' but is set to 'unmanaged [domain(1,int(64),false)] int(64)'The error is caused by reassigning this.chunks in the last line of the initializer; if I remove this line, the error disappears. However, the message doesn't make sense to me: according to the compiler logic (compiler/resolution/functionResolution.cpp:7708), I should only see this error in the case where the type of the field and the type of the assigned value are different, but in this case, the description of each in the error message is the same. Perhaps the compiler message is missing some detailed type information?
The goal of this code was to have an arraychunks, where each element is itself an array of a non-statically-knowable size. Documentation about 'jagged' or 'skyline' arrays suggests that this may not currently be supported
7 replies
Hi Chapel community :wave: ,
just wanted to share my progress on the developing the Chapel track on exercism. You can follow the track development on this github repository: https://github.com/exercism/chapel/
The exercism community and core team has been extremely welcoming and helpful, so the progress has been pretty smooth. At the moment, we already have 15 exercises with solution (20 needed for launch, personally I'd like to get more than the bare minimum before launching). I am fairly confident we can launch the track already this year. When the track is ready, I'll also announce it on discourse. Meanwhile, if you have feedback, comments, questions, requests, everything is welcome :)
3 replies
6 replies
Hello everyone, I have a small (may be naive) question. What is the Chapel way to do stuff like data->buf (or (*data).buf) in C ? Working with the following example:
extern record data {
var buf: c_ptr(c_int);
// ...
};
extern proc fill_buf(buf: c_ptr(c_int)): void;
var d: c_ptr(data) = /* extern C creator of "data" */
fill_buf(d.buf); /* return an error */Thank you in advance.
3 replies