K-ballo 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/
hkaiser has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
jaafar has quit [Remote host closed the connection]
jaafar has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
jejune has joined #ste||ar
shubham has joined #ste||ar
jejune has quit [Quit: "What are you trying to say? That I can dodge bullets?" "No Neo, what I'm trying to say, is that when you are ready.....you won't have to"]
bita has quit [Ping timeout: 260 seconds]
shubham has quit [Quit: Connection closed for inactivity]
linus2 has joined #ste||ar
diehlpk_work has quit [Ping timeout: 264 seconds]
linus2 has quit [Client Quit]
linus2 has joined #ste||ar
tid_the_harveste has quit [Quit: Idle for 30+ days]
<gonidelis[m]>
i remember k-ballo suggesting that I should tweak iter_sent.hpp in order to work for the tests but I just can't find my changes (cause of the million instances of iter_sent.hpp probably_
<gonidelis[m]>
)
<hkaiser>
gonidelis[m]: as said, the current implementation of the iter_sent in master can be imrpved
<gonidelis[m]>
i do get your point
<gonidelis[m]>
and I aggree
<hkaiser>
the comparison operators should be defined either on the sentinel or as global functions that are enable'd for iterators that make is_sentinel_for<> true
<hkaiser>
for reasons unknown (most likely I simply didn't pay attention to this), currently the operators are defined for the specific Iterator type only - so the sentinel can't be used for arbitrary iterators
<gonidelis[m]>
ahhh yeah now i recall!!!
<hkaiser>
actually the operators should be sfinae'd on is_input_iterator<>, that should be sufficient
<gonidelis[m]>
How could I make iter_sent sth like a global facility that we could access like #include <hpx/.....>
<gonidelis[m]>
instead of stupid `include " "`s
<hkaiser>
we need the file for the tests only, no?
<hkaiser>
if the file is needed for the tests only, we should leave it as #include "", just try to have it at a spot where it can be #included from all tests
peltonp1 has quit [Read error: Connection reset by peer]
<k-ballo[m]>
why would we have more than one itersent.hpp?
<gonidelis[m]>
yes it's only for the tests
<gonidelis[m]>
k-ballo: yeah we don't need them
<gonidelis[m]>
I will remove them
<gonidelis[m]>
hkaiser: the problem is that it's been used from tests both under `/parallelism` and `/core`
<gonidelis[m]>
could I put them maybe under `hpx/tests` ?
<hkaiser>
gonidelis[m]: let's have it duplicated, we don't have a central spot for test-related headers
<gonidelis[m]>
ok
<gonidelis[m]>
duplicated is the maximum for me. I won't allow triplecate or more ;p
<hkaiser>
+1
<jedi18[m]>
hkaiser: Can I include algorithms that use partitioner_with_cleanup? (uninitialized_copy, unintialized_fill..etc)
<hkaiser>
jedi18[m]: you 'can include' whatever you like ;-)
<hkaiser>
we're not in scholl here - you are an adult, I presume
<hkaiser>
school, even
<jedi18[m]>
Yeah no I mean it should be doable right? Or is there any reason these haven't been attempted yet?
<hkaiser>
no particular reason except that nobody had time/resources to look into it
<hkaiser>
partinioner_with_cleanup is very similar to the plain partitioner
<hkaiser>
it enables some rollback in case of errors
<jedi18[m]>
Oh ok so for adapting algorithms to C++ 20, I'm thinking of working on unique, adjacent_difference, lexicographical_compare, swap_ranges, unintialized_copy, uninitialized_fill and unitialized_move
<jedi18[m]>
Since those are the partitioner/foreach_partitioner ones
<jedi18[m]>
Given how long it too me to do min,max,minmax and assuming I can do it quicker once I do the starting few, that should comprise 1/3rd to 1/2 of my proposed work, is that okay?
Ri2Raj has joined #ste||ar
<Ri2Raj>
Hello everyone so I have built hpx from source as mentioned in the docs but currently I'm unable to compile the hello world program. It says ** fatal error: hpx/hpx_main.hpp: No such file or directory
<Ri2Raj>
**
<Ri2Raj>
Currently I'm using Ubuntu 20.04 and have installed all the dependencies
<gonidelis[m]>
do you link your program correctly to HPX?
<hkaiser>
jedi18[m]: sounds good
<zao>
Ri2Raj: How are you building your software and what instructions do you follow, if any?
<Ri2Raj>
I have used this command ** g++ -o hello_world hello_world.cpp **
<hkaiser>
Ri2Raj: have you installed HPX?
<Ri2Raj>
Yess obviously I've first built hpx from source and then installed it using ** make install ** as in the docs
<hkaiser>
Ri2Raj: where did you install it to?
<hkaiser>
what's your CMAKE_INSTALL_PREFIX
<Ri2Raj>
Okay So my CMAKE_INSTALL_PREFIX is my system's root directory
<hkaiser>
ok, what did you specify when invoking cmake?
<Ri2Raj>
** cmake ../ **
<zao>
(unless your dependencies are installed in a global location (which you really shouldn't), you need compiler flags to find the headers and linker flags to find the libraries)
<hkaiser>
Ri2Raj: apparently he did install to system
<hkaiser>
zao: ^^
<Ri2Raj>
zao which compiler flags should I use
<zao>
hkaiser: If it's truly the root, it may not be considered.
<zao>
Ri2Raj: -I (capital i) govens where headers are searched. -L governs where libraries are searched.
<zao>
Typically one would use the CMake or pkg-config files from a HPX installation to get the correct flags to use.
<zao>
I would strongly recommend installing software like this into a specific separate location, as it makes it easier to rebuild and wipe it.
<zao>
Regardless, if it's not in a standard location, you tend to specify something like `-I$HOME/opt/hpx-master/include -L$HOME/opt/hpx-master/lib` to augment the search paths.
<zao>
(when having installed it with `-DCMAKE_INSTALL_PREFIX=$HOME/opt/hpx-master`)
<Ri2Raj>
Thanks ! I'll try
<zao>
HPX may have additional directories you need to specify, I've never really looked :)
<ms[m]>
hkaiser: freenode_srinivasyadav227[m]: I'd check that in the hpx non-parallel unseq case we're not doing any chunking (i.e. that we're just using one big chunk)
<hkaiser>
ok, I'll have a look
<hkaiser>
ms[m]: he is just doing seq for the hpx algorithms
<ms[m]>
in parallel you obviously still need it, but it would set a baseline to see how much of the overhead comes from various function wrappers and how much from the chunking (it might not be much but worth looking into)
<ms[m]>
I think we might do the chunking even in the sequential case, but I'm not sure
<hkaiser>
don't think so - but you might be right
<ms[m]>
I may also be wrong... just something I thought might be worth checking
<srinivasyadav227>
ok, shall i test with chunking?.. what be optimal chunk size? i am testing for 2^^10, 2^^20, 2^^30
<srinivasyadav227>
i mean would you suggest any optimal chunk size with my array size being 2^^10, 2^20, 2^^30
<hkaiser>
srinivasyadav227: give me a day or so to reproduce your issues
<srinivasyadav227>
ok sure, ;-)
<srinivasyadav227>
hkaiser: finally my exams are done, i could start working on separating datapar, i have some doubts related to it
<hkaiser>
cool
<srinivasyadav227>
in datapar/transform_loop.hpp and util/transform_loop.hpp, inside namespace hpx::parallel::util in both headers
<srinivasyadav227>
we defined transform_loop and transform_loop_n functions
<srinivasyadav227>
and which internally calls structs (call method) defined in detail right?
<srinivasyadav227>
so should we define a CPO for datapar transform_loop overloads? for seperating
<diehlpk_work>
We will give a short course at the 16th U.S. National Congress on Computational Mechanics
<diehlpk_work>
Please spread the word
<srinivasyadav227>
hkaiser: yes, i am very much interested in performance improvements
<hkaiser>
srinivasyadav227: ok - might be a better project
<srinivasyadav227>
hkaiser: i felt the same regarding separating datapar, i think it would involve lot of code duplication, honestly i could not understand why we want to separate them?, they will only be enabled if HPX_HAVE_DATAPAER is defined right?, so they are already seperated right?,
<hkaiser>
well, yes
<hkaiser>
I was hoping we could simplify the algorithm implementation if we didn't have to adapt to datapar
<srinivasyadav227>
hkaiser: i think is_vectorpack trait is used in many places, i think it was mainly defined for datapar
<srinivasyadav227>
it is defined even if HPX_HAVE_DATAPAR is disabled, its deriving std::false_type
<srinivasyadav227>
but we are mostly using it to check for datapar policy right?
shubhu_ has joined #ste||ar
shubham has joined #ste||ar
nanmiao has quit [Quit: Connection closed]
shubhu_ has left #ste||ar ["Leaving"]
shubhu_ has joined #ste||ar
shubham has left #ste||ar [#ste||ar]
shubham has joined #ste||ar
shubhu_ has quit [Quit: Leaving]
<hkaiser>
srinivasyadav227: yes
bita_ has joined #ste||ar
K-ballo1 has joined #ste||ar
bita has quit [*.net *.split]
K-ballo has quit [*.net *.split]
K-ballo1 is now known as K-ballo
<hkaiser>
srinivasyadav227: I have fixed the sequential for_loop to be faster now than the plain for(), trying to find a way to do the same for for_each....
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
nanmiao has joined #ste||ar
jejune has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]
<gonidelis[m]>
hkaiser: how about converting the hpx::ranges::next facility impl from straightforward function templates to func. objects?
<hkaiser>
gonidelis[m]: what would be the rationale for this?
<gonidelis[m]>
1. we are full for func. obj as far as I understand
<gonidelis[m]>
2. recommended by cppref
<gonidelis[m]>
3(and most important). we provide the facility in a more abstracted way???