Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Audrey J. Pratt
    @ajoshpratt
    I think this is the only time anyone has ever expressed they're interested in whether or not I care about them.
    Brad Chamberlain
    @bradcray
    Now you’re making me weep. :’(
    Audrey J. Pratt
    @ajoshpratt
    Some of us are the monkeys who only got spiky mother. What can I say...
    Tiago Carneiro
    @carcarah
    Hello everyone! is there a way to perform the semantics of #pragma omp critical{....} in Chapel?
    Moreover, should I use Sync / Singles for implementing something like #pragma omp single?
    thanks!
    Brad Chamberlain
    @bradcray
    Hi @Tiago: There’s no feature built-into Chapel that supports critical sections syntactically. In practice, a sync variable is used to guard such code sections (e.g., write to the sync variable to fill it upon entering the section; read from the sync variable to empty it upon leaving it; or vice-versa).
    I’m not as familiar with #pragma omp single. As I understand it, if it’s placed within a parallel region, only a single thread would execute the code? Here, your best bet might be to use an atomic that each task does a compareExchange into to see if it’s the first task to reach it. If so, it executes the code; if not, it skips over it (?).
    Tiago Carneiro
    @carcarah
    Hello @bradcray . Thank you! The #pragma omp single is like you said. It is used inside a parallel region so only one thread executes the single section of the code, but not the necessarily the master one. Ok, I'm going to implement like that. Thanks again =)
    @bradcray I cannot find inside the forall section of the documentation the directives concerning shared, private etc. Am I looking in the right place?
    As far as I remember, the private ones should be inside the with, righ?
    Tiago Carneiro
    @carcarah
    @bradcray Can I suggest the ''single'' directive in Github?
    Brad Chamberlain
    @bradcray
    I think you want the "forall intents" or "task intents" sections of the language specification.
    with (in myvar) will essentially create a per-task (modifiable) copy of an outer variable myvar, so effectively a task-local copy of myvar
    with (const in myvar) will do the same, but it'll be a read-only copy.
    with (var myvar = …) will create a new per-task variable.
    You're welcome to propose a language extension that would give singlesemantics on GitHub issues, yes.
    Bryant C. Lam
    @BryantLam
    For #13541, what does the : int part of the argument do?
    proc foo(type t:int) { }
    foo(int(8));
    I'm using to seeing default argument values as = int, so it makes me think this is something else.
    Oh wait. I think I'm following now. I think this is a constraint on type t.
    Brad Chamberlain
    @bradcray
    That's correct, its a constraint on the type argument.
    Constraining it to be int isn't all that exciting, though it can be a way to tease type cases apart via overloading.
    Here's a slightly more interesting example:
    Bryant C. Lam
    @BryantLam
    That's cool! I like that Chapel has these micro cases of constrained generics that pop up once in a while.
    Bryant C. Lam
    @BryantLam
    Is there a way to force Chapel to build a single-locale executable from a multi-locale build? In other words, how do I get the CHPL_COMM=none behavior where my executable doesn't depend on a launcher?
    Is --local enough? I should just test that.
    Brad Chamberlain
    @bradcray
    —local will give you a single-locale build, yes.
    You may also want to set CHPL_LAUNCHER=none or —launcher=none, but that may require your runtime to have been built in that configuration as well (?).
    Lydia Duncan
    @lydia-duncan
    --comm=none also should work
    Bryant C. Lam
    @BryantLam
    What is the difference between --local and --comm=none?
    Lydia Duncan
    @lydia-duncan
    --comm=none is the same as setting CHPL_COMM=none but only for that single chpl compile . --local will explicitly turn off the generation of certain remote operations in the compiler, but will still require you to pass -nl or --numlocales to the executable and will leave the launcher/comm setting unchanged.
    If you send -nl 2 or greater to an executable compiled with --local, you will get a halt telling you to run with only one locale
    Most of the environment variables we track with printchplenv have that compiler flag equivalent, which is useful if you have multiple builds lying around. But note that if you haven’t built with that particular configuration, you’ll have to change the environment variables and do so anyways.
    Audrey J. Pratt
    @ajoshpratt
    Can said multiple builds exist within the same chapel install directory? I wasn't sure if I just failed to set some parameter correctly and it didn't work, or...
    on classRef.home {} <---- I take it classRef is a Chapel built in? And also, this is getting that 'attempt to dereference nil' error which
    ooof, nope, it's a special ZMQ module thing
    Audrey J. Pratt
    @ajoshpratt
    Ah, ooops. Got it. I attempt to receive on a socket before actually setting up the socket. Nevermind. This has been "Stream of Consciousness Theatre, with Audrey."
    Lydia Duncan
    @lydia-duncan

    Can said multiple builds exist within the same chapel install directory? I wasn't sure if I just failed to set some parameter correctly and it didn't work, or…

    The built chpl executable will always live in the same place, but for those environment variable settings we make separate subdirectories in $CHPL_HOME/lib and then swap which ones we look for depending on the settings for the particular program being compiled

    I’m not sure if that answers your question, heh
    Audrey J. Pratt
    @ajoshpratt
    I think so, yes!
    I had it working once but then it didn't work after I had to reinstall, and I was too busy to debug so I just, you know, git cloned again and compiled...
    Lydia Duncan
    @lydia-duncan
    You use a big hammer sometimes XD
    I suspect what happened is that you had rebuilt the compiler in one setting and not the other, so parts of it were out of date?
    But that’s pure speculation
    Audrey J. Pratt
    @ajoshpratt
    That's what I'm assuming, too
    Sometimes the big hammer gets results!...
    Audrey J. Pratt
    @ajoshpratt
    Also, engineers are highly superstitious. For my code to compile, all the pieces must be in place. I must have the correct includes, the proper number of candles lit, I must have said "please please please" at least 4 times, and if I'm not hitting the keys just right that day, of course the code won't compile, I'll have angered the code. Disrespected it, even, with my loud typing. So. Ya know. Big hammer.
    Brad Chamberlain
    @bradcray
    My take on —local vs. —comm=none: —local says “compile this program such that it will never use locales other than the initial one (i.e., it will not require or use communication; effectively all on-clauses are ignored).” —comm=xyz says “when this program needs to communicate, use communication layer xyz to do it.” So when using —local the choice of comm doesn’t really matter (it won’t be used) and when using —comm=none no communication will be able to be performed. As a result, —comm=none causes the compiler to default to —local while any other —comm setting defaults to —no-local. (and CHPL_COMM is a way of setting the default —comm= option).
    Multiple configurations can absolutely live in the same CHPL_HOME directory happily.