I think the reason why at 21:45 it didn't run any faster was because you're setting element equal to i*i and then just, throwing away the element variable. I'm assuming the compiler saw that and realized "oh I don't actually have to do that, I can just skip that step since it's not being used later in the program". Hence why it would take the same amount of time as if you just initialized the array, which... also didn't get used, and so was probably garbage collected or whatever you call it when compilers decide something isn't important.
@ritz-menardi Right, the code shown at that timestamp is forall (element, i) in zip(A, A.domain) { element = i*i; } In this zippered loop, 'element' is a reference to A[i]. So the value stored in 'element' is not thrown away. It ends up in the array. Yes, in theory, the whole array could be optimized away, but the current compiler won’t do that. I have not investigated it in detail but I suspect it’s more to do with being memory bandwidth bound.
@neme6698: Thanks for the question! Chapel was developed as part of a larger Cray project named Cascade, and its name came from "Cascade High-Productivity Language" or CHPL, which evolved into Chapel. For more information about Chapel's origins, see chapel-lang.org/publications/PMfPC-Chapel.pdf
@AozenDreyar: Thanks for your inquiry. Unfortunately, we don't have any open positions at HPE today (or elsewhere in the Chapel community that I'm aware of). As opportunities become available, they'll be advertised on the Chapel jobs page (chapel-lang.org/jobs.html ), the HPE careers page (careers.hpe.com/us/en ), and our social media channels (chapel-lang.org/community.html ).
![Diggy Graves - Red Vineyard [Official Lyric Video]](http://i.ytimg.com/vi/8Ro085T0mnQ/mqdefault.jpg)
I think the reason why at 21:45 it didn't run any faster was because you're setting element equal to i*i and then just, throwing away the element variable. I'm assuming the compiler saw that and realized "oh I don't actually have to do that, I can just skip that step since it's not being used later in the program". Hence why it would take the same amount of time as if you just initialized the array, which... also didn't get used, and so was probably garbage collected or whatever you call it when compilers decide something isn't important.
@ritz-menardi Right, the code shown at that timestamp is
forall (element, i) in zip(A, A.domain) {
element = i*i;
}
In this zippered loop, 'element' is a reference to A[i]. So the value stored in 'element' is not thrown away. It ends up in the array. Yes, in theory, the whole array could be optimized away, but the current compiler won’t do that. I have not investigated it in detail but I suspect it’s more to do with being memory bandwidth bound.
Why was it called chapel?
@neme6698: Thanks for the question! Chapel was developed as part of a larger Cray project named Cascade, and its name came from "Cascade High-Productivity Language" or CHPL, which evolved into Chapel. For more information about Chapel's origins, see chapel-lang.org/publications/PMfPC-Chapel.pdf
@@ChapelLanguage is the name affected by christianity? I am a christian
@@nemea6698: It is not.
@@ChapelLanguage okay
@@ChapelLanguage okay
does chapel have any jobs?
@AozenDreyar: Thanks for your inquiry. Unfortunately, we don't have any open positions at HPE today (or elsewhere in the Chapel community that I'm aware of). As opportunities become available, they'll be advertised on the Chapel jobs page (chapel-lang.org/jobs.html ), the HPE careers page (careers.hpe.com/us/en ), and our social media channels (chapel-lang.org/community.html ).