aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [Quit: K-ballo]
diehlpk has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
diehlpk has joined #ste||ar
daissgr has quit [Ping timeout: 264 seconds]
Smasher has quit [Remote host closed the connection]
jaafar has joined #ste||ar
diehlpk has quit [Ping timeout: 260 seconds]
diehlpk has joined #ste||ar
nikunj has quit [Quit: Page closed]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
nikunj has joined #ste||ar
hkaiser[m] has joined #ste||ar
<hkaiser[m]>
the memory
<hkaiser[m]>
block stuff is ancient
<hkaiser[m]>
could be removed, really
<K-ballo>
removing stuff, I like
hkaiser has joined #ste||ar
diehlpk has quit [Ping timeout: 248 seconds]
hkaiser[m] has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
nanashi55 has quit [Ping timeout: 264 seconds]
nanashi55 has joined #ste||ar
hkaiser has joined #ste||ar
gedaj has joined #ste||ar
hkaiser has quit [Quit: bye]
gedaj has quit [Quit: Leaving]
<nikunj>
@hkaiser: Should I work on removing memory_block from hpx then?
hkaiser[m] has joined #ste||ar
<hkaiser[m]>
nikunj feel free
<nikunj>
hkaiser[m]: Ok, in that case, I'll remove the memory_block from hpx and make quicksort run without memory_block.
<nikunj>
Also, should I raise a ticket to show that the error remains same and that the problem exists within memory_block itself?
<nikunj>
^^ error in case you create only a basic code that simply creates a memory_block and free it.
<nikunj>
hkaiser[m]: regarding the pr, I have actually built the hello
<nikunj>
hello_world_component
<nikunj>
hello_world_component is built when make tests.unit.build is run on docker
<hkaiser[m]>
Ok thanks
Anushi1998 has quit [Quit: Leaving]
<hkaiser[m]>
Why did that involve removing the source?
<nikunj>
hkaiser[m]: it was previously building the src folder. The purpose was to build an external project. Now that we needed to build the hello_world_component, we could build an external project directly by building hello_world_component, so @heller_ told me to build that one instead.
<nikunj>
hkaiser[m]: That was the reason I deleted the src directory
<hkaiser[m]>
but haven't that removed the actual source file needed for the component?
<nikunj>
hkaiser[m]: which file are you talking about?
<nikunj>
hkaiser[m]: the outer cmakelists was initially invoking the one inside the src directory, I just changed the location to invoke the cmakelists inside of hello_world_component
<hkaiser[m]>
the one you removed
daissgr has joined #ste||ar
<hkaiser[m]>
nikunj let me look again later today
<nikunj>
hkaiser[m]: ok. It is actually building correctly, I think there is slight misunderstanding.
<hkaiser[m]>
Ok
diehlpk has joined #ste||ar
<nikunj>
hkaiser[m]: what is the file hpx/runtime/get_lva.hpp used for?
<nikunj>
It is creating a struct get_lva with type components::server::memory_block
daissgr has quit [Ping timeout: 256 seconds]
hkaiser[m] has quit [Ping timeout: 240 seconds]
Smasher has joined #ste||ar
daissgr has joined #ste||ar
diehlpk has quit [Ping timeout: 268 seconds]
jakub_golinowski has joined #ste||ar
hkaiser[m] has joined #ste||ar
<jakub_golinowski>
Hello
<jakub_golinowski>
I have a question about documentation:
<Guest96539>
yeah should I paste it's content here? or is there anything specific that you want? file does not mention opencl btw
<K-ballo>
if it's only a couple lines sure
<K-ballo>
nod, that's what I was looking for, some opencl mention
<Guest96539>
currently i have reinstalled hwloc without opencl support. lets see how far it goes
<Guest96539>
also sometimes the make stops citing segfaults but after I re-run, it vanishes.. does anybody face something like this?
<Guest96539>
for example : /hpx/src/runtime/threads/thread_helpers.cpp:636:52: internal compiler error: Segmentation fault return self->get_available_stack_space();
jakub_golinowski has joined #ste||ar
<Guest96539>
around 28%
<K-ballo>
if you are building in parallel it is possible you are running out of memory
<Guest96539>
yeah that seems like it
<Guest96539>
but that would be a problem in single core as well.. dont you think?
<K-ballo>
no, if one TU requires 4GB of RAM and another one requires 6GB then for a single build you just need 6, whereas a parallel build needs 10
<K-ballo>
keep an eye on your memory usage, and figure out how many builds you can afford
Guest96539 has quit [Quit: Page closed]
<jakub_golinowski>
I have a question about having multiple build of hpx on one OS - is this generally OK? or there are some problems with this
<jakub_golinowski>
?
<K-ballo>
jakub_golinowski: is fine as long as you install them to different places (if you do install them), specially if neither of them is installed in the system default location
<jakub_golinowski>
K-ballo thank you
<jakub_golinowski>
I am asking because I was using version1.0 so far
<jakub_golinowski>
now I figured I should use the version compiled from git repository to be up-to-date, so I built it in another directory
<jakub_golinowski>
and now when I tried to rebuilt the application that I was succesfully building using HPX 1.0 again with HPX 1.0 - It was unsuccesful
<K-ballo>
builds are independent, so are installations to distinct prefixes
<zao>
jakub_golinowski: In general, avoid installing to a globally visible location.
<zao>
(for any user-supplied lib, not just HPX)
<zao>
(-DCMAKE_INSTALL_PREFIX= when building)
kasprov has quit [Quit: Page closed]
jakub_golinowski has quit [Ping timeout: 276 seconds]
nanashi64 has joined #ste||ar
nanashi5- has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi5- is now known as nanashi55
nanashi64 has quit [Ping timeout: 256 seconds]
Anushi1998 has joined #ste||ar
jakub_golinowski has joined #ste||ar
nikunj has quit [Quit: Page closed]
Anushi1998 has quit [Ping timeout: 252 seconds]
galabc has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 252 seconds]
<galabc>
In the article, it is said that you implemeted 2 functions chunk_size_determination() and prefetching_distance_determination() to get the optimal values
<hkaiser>
yes
<galabc>
I was looking into the HPXML files and I couldn't find where those functions are defined
<galabc>
I took a look at the Clangtool files
<galabc>
but I didn't find it
<hkaiser>
galabc: only zahra will know :/
<hkaiser>
I have no idea where all of this code lives
<galabc>
Ok no problem, I will ask her in no time
<galabc>
thank you
<galabc>
Oh I finally found it :D
<hkaiser>
where is it?
jakub_golinowski has joined #ste||ar
<galabc>
hpx/parralel/
<galabc>
the headers are there
<hkaiser>
ok
<galabc>
well hkaiser I have a question regarding the headers in that directory
<hkaiser>
galabc: I'll be away for an hour, just leave your question here
<galabc>
ok
<galabc>
in the header file prefetching_distance_detemination.hpp
<galabc>
the function prefetching_distance_determination is defined
<galabc>
but its not the prototype that is defined but the actual function
<galabc>
I've never seen a header file that contains a function definition instead of a function prototype
<galabc>
from my experience, the headers contain the prototype and then a .cpp file contains the function definition
<zao>
Headers contain function bodies when they're defined inline, when they're function templates or partial template specializations, or defined in-line in a class definition.
<K-ballo>
that one in particular is missing `inline`
<zao>
This one will be a linker error in case you ever include it in two TUs.
nikunj has joined #ste||ar
<galabc>
TUS?
<K-ballo>
translation unit, normally one .cpp file under compilation, after preprocessing
<galabc>
Ok but header files are never compilated
<galabc>
how could the functions be compiled if they are in a header?
<zao>
galabc: They're pulled in via preprocessor includes.
<K-ballo>
header files are compilated, once a .cpp file is preprocessed it includes all the files that were directly and indirectly #included via the preprocessor
<zao>
If you include that header in two source files, you're going to get duplicates of the function body in your object files.
<zao>
If it'd been marked inline, there'd be duplicates, but any one of them would be considered fine for the linker.
<galabc>
Ok, I will try to better understand headers in general
<galabc>
I'm mostly used to matlab and python so I'm not used to all of this :D
<galabc>
I mostly used**
<zao>
In short, when the compiler compiles a cpp file, all the headers will be pasted pretty much as-is at the place they're included.
<zao>
The compiler then runs through the source file top-down and compiles it, this is why you need to declare before use, and such things.
parsa has joined #ste||ar
<galabc>
ok can you repeat what the 'inline' does?
<zao>
When you link several source files together, the linker looks for the compiled implementation of functions in object files.
<galabc>
ok
<zao>
Normally you have a function in a single .cpp file, so you end up with a definition for that function in exactly one object file.
<galabc>
yes
<zao>
So when you link it together with something that requires that function, it resolves properly.
<zao>
Now, if you for some reason want the implementation of a function visible in a header (for purposes of optimization and inlining), you've got a problem.
<zao>
As each successful include of that header results in a separate compilation of that function definition.
<zao>
The 'inline' keyword on functions has the effect that any of those compiled functions are considered equivalent, and the linker just picks one at will.
<zao>
Historically, the keyword had a bit of hinting to what should be inlined in calling functions, but that's pretty much gone and only the weird name remains.
<zao>
This is incidentally why you are allowed to have bodies on functions inside of class definitions in headers, they're implicitly considered "inline".
hkaiser has quit [Quit: bye]
<galabc>
ok so you don't want to keep recompile the function cpp file
<galabc>
so you keep the definition in the header
<galabc>
is that right?
<zao>
That's normally not a big concern.
<galabc>
Ok but I assume these functions require a lot of recompile
<galabc>
Ok i understand
<galabc>
Thank you very much zao :D
<zao>
Separately compiled functions are nice in that as long as you don't touch them or the headers they include, they stay compiled.
<zao>
Functions defined in headers will be compiled whenever you compile a source file that includes it.
<zao>
So there's some tradeoffs taking place.
<zao>
Doesn't really matter much as long as you follow the rules about defining them inline and not.
<zao>
In the particular case you linked, the author has either forgotten to mark it inline (happens a lot), or has intended the header to only ever be included by a single source file.
jakub_golinowski has quit [Read error: Connection reset by peer]
jaafar has quit [Ping timeout: 248 seconds]
<K-ballo>
we used to have a test that would compile all the headers together
jakub_golinowski has joined #ste||ar
<heller_>
we still have
<galabc>
ok i see
galabc has quit [Ping timeout: 268 seconds]
eschnett has joined #ste||ar
mcopik has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 268 seconds]
nikunj_ has joined #ste||ar
nikunj has quit [Ping timeout: 260 seconds]
jakub_golinowski has joined #ste||ar
jakub_golinowski has quit [Quit: Ex-Chat]
nikunj_ has quit [Ping timeout: 260 seconds]
diehlpk has joined #ste||ar
hkaiser has joined #ste||ar
galabc has joined #ste||ar
galabc has quit [Client Quit]
hkaiser[[m]] has joined #ste||ar
hkaiser[[m]] has quit [Client Quit]
kasprov has joined #ste||ar
daissgr has quit [Quit: WeeChat 1.4]
<github>
[hpx] hkaiser deleted msimberg-patch-1 at 50c8f4d: https://git.io/vxeAD