Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    hokiegeek2
    @hokiegeek2
    while I am trying to launch locales in dockers, more generally speaking the custom command launch not working for me. I have screen shots immediately abovve
    Brad Chamberlain
    @bradcray
    I don’t… In practice, I either use the launchers, or use the -v / --verbose flag on a launcher binary to see what it’s doing and then customize that command for my own use. Throwing "verbose" flags to GASNet’s launchers can also be useful but AFAIK, there’s currently no way to do that without bypassing our launcher and invoking the GASNet launcher manually.
    Elliot Ronaghan
    @ronawho
    @bradcray for some additional context this is trying to use GASNET_SPAWNFN='C' and GASNET_CSPAWN_CMD to use a customer spawner with gasnet, not really a custom chapel launcher. I agree though that we don't have much experience with this ourselves beyond using GASNET_CSPAWN_CMD=srun for amudprun. I might try reaching out to the gasnet team
    hokiegeek2
    @hokiegeek2
    @ronawho @bradcray And yeah, this really is a GASNET-focused question, so I am happy to follow-up with them instead
    Brad Chamberlain
    @bradcray
    Thanks for clarifying. I definitely lost the thread yesterday.
    hokiegeek2
    @hokiegeek2
    is there a way to configure the ports used in locale-locale comms?
    Brad Chamberlain
    @bradcray
    @hokiegeek2 : I don’t personally know the answer to that. Will check whether anyone else does.
    hokiegeek2
    @hokiegeek2
    @bradcray thanks, I actually think I've got an alternative path, so no need to follow-up w/ the rest of the Chapel team
    hokiegeek2
    @hokiegeek2
    This is odd -> first time I've seen this error:
    image.png
    ah, I see, could not get to GASNET_MASTERIP within docker, I guess
    Brad Chamberlain
    @bradcray
    That error is unfamiliar to me as well.
    Engin Kayraklioglu
    @e-kayrakli

    @/all — CHIUW 2021 is tomorrow! We have a really exciting keynote by Eric Laurendeau of Polytechnique Montreal on his decades of experiences in the intersection of HPC+CFD+Aircraft Design and how Chapel helps their day-to-day research, and 13 other talks. The event starts at 8:00 AM PDT tomorrow.

    More info: https://chapel-lang.org/CHIUW2021.html
    Registration is needed; but free and very easy: https://hpe.zoom.us/meeting/register/tJ0ldumppj0rEtCAGHNsMRcqYGJSqTFyjARv

    blankprism
    @blankprism:matrix.org
    [m]
    Is there a way to get more precision while adding two numbers
    For eg. writeln(1e-06 + 1) results in 1.0
    also writeln(1e+06 + 1) results in 1e+06
    Brad Chamberlain
    @bradcray
    You probably want writef() which is like Chapel's take on C's printf(). See https://chapel-lang.org/docs/modules/standard/IO/FormattedIO.html
    4 replies
    Thomas Rolinger
    @thomasrolinger

    I want to create a block-distributed array of LockFreeQueues (https://chapel-lang.org/docs/modules/packages/LockFreeQueue.html). However, I get the warning/error below:

    warning: creating an array with element type LockFreeQueue(int(64))
    warning: which now means class type with generic management
    error: array element type cannot currently be generic

    This is unfamiliar territory for me. Is there an obvious work-around? I've tried wrapping the LockFreeQueue into a record and storing those records in the block-distributed array, but the same problem arises.

    Brad Chamberlain
    @bradcray
    Hi Thomas — I believe the issue here is that given a class C in Chapel, a reference to C could mean owned C, borrowed C, unmanaged C, or shared C, which is what the “now means class type with generic management” phrase means in your error message. Declaring the array as var A: [1..10] owned C; or var A: [1..10] unmanaged C; or any of the other variants should resolve this. One other thing you may need to wrestle with it whether you want to store nilable or non-nilable instances of the class, which would be expressed as var A: [1..10] unmanaged C? vs. var A: [1..10] unmanaged C; respectively.
    Thomas Rolinger
    @thomasrolinger

    Thanks, that got me past the declaration of the array, using unmanaged and nilable instances. But now when I try to call the enqueue method on one of the LockFreeQueues, I get the following:

    error: unresolved call 'unmanaged LockFreeQueue(int(64))?.enqueue(int(64))'
    $CHPL_HOME/modules/packages/LockFreeQueue.chpl:133: note: this candidate did not match: LockFreeQueue.enqueue(newObj: objType, tok: owned TokenWrapper = getToken())
    note: because method call receiver with type 'unmanaged LockFreeQueue(int(64))?'

    Apologize in advance if this is beginner stuff; I rarely go beyond arrays of ints/reals!

    for what its worth: I am trying to get a LockFreeQueue per locale
    Thomas Rolinger
    @thomasrolinger
    (and I need to be able to access another locale's LockFreeQueue from any other locale)
    Engin Kayraklioglu
    @e-kayrakli
    Your array stores nilable LockFreeQueues, but before calling a method, you have to make sure that the item you call the method on is not actually a nil, and you have to assure the compiler of that. You do that by a postfix-!. e.g. if you have arr[0].enqueue you need arr[0]!.enqueue or equivalent.
    Thomas Rolinger
    @thomasrolinger
    @e-kayrakli thanks! I am definitely a novice at this side of Chapel
    Brad Chamberlain
    @bradcray

    @thomasrolinger : No worries, we all are novices about this at this point, so much has changed about Chapel classes in the past few years. :)

    I also wanted to correct one potential misunderstanding: If you were to use an array of records, nothing would prevent other locales from referring to each others’ record values. That’s not to suggest that records are necessarily the right approach to your pattern, but if they were, they tend to be much simpler to work with than classes (due to their lifetimes being based on scoping; due to not having a pointer-to-object that could potentially be nil).

    This SO question is pretty good at characterizing how classes and records differ, though I’m realizing that it could probably stand to touch on nilability a bit more: https://stackoverflow.com/questions/48331007/when-should-i-use-a-record-vs-a-class-in-chapel

    Thomas Rolinger
    @thomasrolinger
    @bradcray thanks for the info! On a related note, is the LockFreeQueue module something that has been actively, or recently, looked at? I am experimenting with it and it seems to work in terms of correctness, but I am curious about whether its performance is "up to date" w.r.t. the latest Chapel improvements. It's something I stumbled upon more or less by accident.
    Brad Chamberlain
    @bradcray
    @thomasrolinger : Ah, sorry. I didn’t recognize LockFreeQueue in your code above as being from a package module rather than something you were creating yourself. I don’t know much about the status of this package. It’s been maintained such that whatever tests were written against it are still passing, but I haven’t used it myself, so don’t feel like I have a very good sense of its status, stability, or performance.
    (others here may have a better sense, though)
    Michael Ferguson
    @mppf
    I’d expect LockFreeQueue to have reasonable performance - the main lacks in it I know of have to do with portability. One of the related packages has a memory leak in testing but I don’t remember which one (or know if it’s a big problem for practical uses or not).
    Engin Kayraklioglu
    @e-kayrakli
    Both LockFreeQueue and LockFreeStack have some leaky tests.
    Lakshya Singh
    @king-11
    make[4]: *** [Makefile:156: all] Error 2
    make[3]: *** [Makefile:171: /home/king-11/chapel/third-party/llvm/install/linux64-x86_64-gnu/bin/clang] Error 2
    make[2]: *** [Makefile:135: /home/king-11/chapel/third-party/llvm/install/linux64-x86_64-gnu] Error 2
    make[1]: *** [Makefile:79: compiler] Error 2
    make: *** [Makefile:59: comprt] Error 2
    I am getting the above error while trying to build chapel with CHPL_LLVM=bundled
    1 reply
    s166harth
    @s166harth
    Hello.... I'm new to this community.....my skills are a bit limited......so can you guys guide me towards some begginer friendly issues?
    Lydia Duncan
    @lydia-duncan
    Welcome! The tag “good first issue” is a good place to start on github: https://github.com/chapel-lang/chapel/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
    s166harth
    @s166harth
    Thanks
    npadmana
    @npadmana

    Hi all -- I'm running into an odd error with reduce (could well be that I'm doing something silly here). Consider the following code that computes the mean and stdev of a vector :

    record R {
      var x : [0..1] real;
    }
    
    const wt = 1.0/3.0;
    var arr = [new R([0.6,0.4]), new R([0.5,0.6]), new R([0.4,0.5])];
    
    const xmean = + reduce (arr.x * wt);
    const x2 = + reduce(arr.x**2 * wt);
    const xvar = + reduce ((arr.x-xmean)**2 * wt);
    
    writeln("xmean :",xmean);
    writeln("x2 :",x2);
    writeln("xvar :",xvar);
    
    writeln('Calculated mean =', xmean);
    writeln('Calculated variance (problem!) =',sqrt(xvar));
    writeln('Calculated variance 2 (correct!) =',sqrt(x2-xmean**2));
    writeln('Expected variance =', sqrt(2*(0.1**2)/3.0));

    Running this on 1.24.1, I get

    xmean :0.5 0.5
    x2 :0.256667 0.256667
    xvar :0.0101815 0.0264037
    Calculated mean =0.5 0.5
    Calculated variance (problem!) =0.100903 0.162492
    Calculated variance 2 (correct!) =0.0816497 0.0816497
    Expected variance =0.0816497

    I would expect that (a) both approaches to calculating the variances should give the same answer and (b) both elements of xvar to be the same. Just from playing around, it looks like the error comes out when xmean is not zero, but I can't quite rule out my just being careless.

    9 replies
    Brad Chamberlain
    @bradcray
    @npadmana : Took a look, and as I mentioned guessing to you on PM, it did turn out to be a case of my least favorite Chapel bug (TM): chapel-lang/chapel#11428
    Brad Chamberlain
    @bradcray
    (Or actually, a slight variant on my least favorite Chapel bug that I think we can address).

    Specifically, as Paul guessed and you referred to as an ambiguity, the issue is with arr.x - xmean. Chapel doesn’t implicitly support subtraction between arrays, nor between 'array-of-t' and ’t’ (arguably what you’re wanting here), so this becomes a promotion of the scalar subtraction function with its two array arguments, which you can think of as being equivalent to:

    forall (x, xm) in zip(arr.x, xmean) do (x - xmean);
    // or:
    [(x, xm) in zip(arr.x, xmean)] (x - xmean);

    So, if Chapel were working as intended, and the bug above did not exist, the execution-time behavior you should’ve received would’ve been an error like:

    error: zippered iterations have non-equal lengths

    Yet, because of the bug (almost more of a design flaw that needs to be addressed, really), the mismatch isn’t detected, so you’re not alerted to it, and Chapel runs off the end of the xmean array, trying to find a third element for it.

    The difference between this and my least favorite bug is that this one—in which the first expression in the zippering is larger than the second—we can and should be able to catch in Chapel today, yet don’t (to my bewilderment), because there is no third element of xmean, so the zippering should just fail. The other—in which the first expression in the zippering is smaller than the second—we can’t without changes to Chapel’s design that we intend to address, but haven’t yet. I’ve got a simple mod that issues the error, and will run it through testing to see if it can be merged.
    Brad Chamberlain
    @bradcray

    I think the right way to express what you wanted in Chapel today would be to run a loop over the array as follows:

    const xvar = + reduce [x in arr.x] ((x-xmean)**2 * wt);

    to clarify that you want to apply the elements of arr.x to xmean with the subtraction operator.

    Brad Chamberlain
    @bradcray
    I’ve also been puzzling over whether our promotion machinery could be smarter about noting that the arrays here (arr.x and xmean) aren’t really all that compatible, so aren’t a good candidate for promotion, at least as written here. The most obvious cues would be the lengths, but we don’t generally attempt to reason about array lengths at compile-time (and generally can’t, even though in this case we could). But beyond that, I wonder whether we should be noticing that the first array’s element type is an array of real and the second’s is merely a real, so perhaps we should balk at applying the promotion? I.e., not permit the double promotion that I believe is occurring today.

    What do I mean by double promotion? Essentially, returning to my rewrite (and fixing my typo):

    [(x, xm) in zip(arr.x, xmean)] (x - xm);

    the type of x is [0..1] real and the type of xm is merely real. So when we see x-xm we apply another promotion of the first argument and get:

    [(x, xm) in zip(arr.x, xmean)] [x2 in x] x2 - xm;

    which isn’t what you wanted. But then the question is: Is it ever what someone would want? Or should we just not permit this? (and give you an error, forcing you to express one of the loops explicitly to break the ambiguity?).

    (Sorry, this was probably a bit long and in-depth for gitter… I’m going to stew on it a bit more and maybe kick off an issue).
    Brad Chamberlain
    @bradcray
    Patch that would’ve caught this specific case here: chapel-lang/chapel#17929
    npadmana
    @npadmana

    @bradcray -- thanks for the detailed notes here, and in particular, the right version above (copied below).

    const xvar = + reduce [x in arr.x] ((x-xmean)**2 * wt);

    I seem to keep forgetting that I can use the [a in arr] syntax on the right-hand side of an assignment (I think mentally because I translate [a in arr] into a for loop which I just think of as a statement). And I'm always struck by how fluently it reads.

    One question about that -- I'm guessing that this reduce expression somehow reduces down to a single forall loop, and doesn't produce a temporary for the

     [x in arr.x] ((x-xmean)**2 * wt)

    part? Is that true (or at least, is that the intention)?

    Finally, on the double promotion, I had been mulling that, and I sort of kept ending with the conclusion that the compiler should just balk at it. I just worry about edge cases where the compiler would guess the wrong path and get the wrong answer (and silently too!). And (as in this case) it seems like there are equally elegant ways to write the statement that are explicit. Just my $0.02.

    Brad Chamberlain
    @bradcray
    A slight refinement on my “should we prohibit double promotion?” question last night would be “should we prohibit asymmetric double promotion?” in which one argument is an array of arrays and the other is simply an array. I think promotion can still be very helplful and natural if both cases are arrays of arrays of t, for example. But the case where one argument causes two promotions and the other causes one seems like it may be more likely to be an error than intentional. I’m still wrestling with this and still thinking about opening an issue about it.
    w.r.t. the manual rewrite and the temporaries: you’re correct that a temporary array will not be created to store the intermediate values before reducing them. However, I think it’s still a nested forall in that there’ll be the forall over arr.x and then a small 2-element forall over the 2-element arrays to compute each x-xmean difference (which should be serialized in practice since it’s nested).
    Brad Chamberlain
    @bradcray
    Also note that, while they’re syntactically a bit more awkward/verbose, both for and forall support expression-level forms as well. So, one can write:
    const xvar = + reduce for i in 1..10 do i;
    npadmana
    @npadmana
    I wonder if it's possible for the compiler to have an "--report=all" flag that might inform the user when it's applying certain optimizations, or unusual promotions, or eg. auto-aggregation, localAccess. I know there are switches for some of these individually, but this might be a nice hammer to use when one is trying to figure out what the compiler is doing.
    I guess I'm musing about a "--help-me-chapel-you're-my-only-hope" flag. Or a Chapel-team AI. :-)
    Brad Chamberlain
    @bradcray
    Regarding —report-all, I agree that would be attractive, and it would be easy to implement, but I think for it to be practically useful, we’d probably have to put more effort into making the various reports play nicely with each other. I’d file a feature request for this, though, if you like.
    The flag I keep fantasizing about (which would be work, but tractable, and better to start on earlier than later) would be a —perf-notes flag that called out things that were known to be likely performance concerns, either at compile-time (“I notice you’re zippering these two multidimensional arrays, which doesn’t work very well yet”) or execution time (“Hey, I’m spending a lot of time in this slow code path; maybe you could do something to improve that?”)