hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
<ms[m]>
srinivasyadav227: you might also want to check the email above since your PRs are affected
<gonidelis[m]>
ms: thanks
<gonidelis[m]>
i need to subscribe with my new email to the list
<gonidelis[m]>
ms: now in case I wanna tweak the source local code by using just hpx is that possible?
<ms[m]>
gonidelis: instead of letting hpx download hpxlocal you can also point it to a source tree with FETCHCONTENT_SOURCE_DIR_HPXLOCAL or to an installed hpxlocal with the usual cmake mechanisms
<ms[m]>
in your case I guess you rarely use the distributed stuff so you might also just want to use hpxlocal on its own
<gonidelis[m]>
is `int* pa = a; float* pb = (float *)pa;` supposed to be undefined behavior?
<gonidelis[m]>
caues i don't see float and int falling into any of those exception categories
<hkaiser>
well, think about what that means
<hkaiser>
sketch what this looks like in memory
<gonidelis[m]>
`pb` holds twice as much memory?
<hkaiser>
no
<hkaiser>
*pb might have a different size
<hkaiser>
on some systems sizeof(int) == sizeof(float) on some not
<gnikunj[m]>
The only cool casts are from T* to void* and back. C FTW xD
<hkaiser>
and even if they have the same size, what sense does it make to reinterpret a bit pattern that is representing an int as if it was representing a float?
<hkaiser>
elements of programming chapter 1, I believe
<gonidelis[m]>
hkaiser: well sure. i don't want to apply this typecast somewhere, but it's good to know that i shouldn't not apply it in the future
<gonidelis[m]>
but what does eop ch1 have to do with that?
<gonidelis[m]>
gnikunj: yeah...pure memory address although i still dont know why
<K-ballo>
casts are fine most of the time, dereferencing the resulting pointer is another story
<K-ballo>
*inter-pointer casts
<gonidelis[m]>
K-ballo: lol
<gonidelis[m]>
i get that the float* size might be different than the int* size but what implications could it have at the end?
<gonidelis[m]>
how could misalignment actually happen?
<hkaiser>
gonidelis[m]: no, usually sizeof(float*) == sizeof(int*) as both are addresses in memory
<hkaiser>
however sizeof(float) is not always equal to sizeof(int)
<hkaiser>
gonidelis[m]: different types might have different alignment requirements, e.g. char is usually byte-aligned, while double could be aligned to addresses divisible by 8
<gonidelis[m]>
oh!
<hkaiser>
gonidelis[m]: for instance an operation on a double located on the stack that is not aligned at boundaries divisible by 8 will cause a segmentation fault on x86
<gonidelis[m]>
what do you mean "aligned to address" ?
<gonidelis[m]>
placed?
<hkaiser>
the address has to be divisible by 8
<hkaiser>
i.e. values 0, 8, 16, etc
<hkaiser>
ms[m]: would you have any suggestion how we can ensure that PRs on hpx that depend on changes in hpx-local can be properly tested?
<gonidelis[m]>
yes but what do you mean the data is aligned to some address?
<hkaiser>
that the address of that data items is divisible by some integer value, usually 2, 4, 8 or 16
<gonidelis[m]>
ok ok ok got it
<ms[m]>
hkaiser: if hpx really depends on those changes in hpx-local that dependency should be reflected in the minimum version required and the default tag used for hpx-local