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
hkaiser has quit [Ping timeout: 250 seconds]
hkaiser has joined #ste||ar
ct-clmsn has joined #ste||ar
ct-clmsn has quit [Quit: This computer has gone to sleep]
ct-clmsn has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 265 seconds]
ct-clmsn has quit [Quit: Leaving]
hkaiser has quit [Quit: Bye!]
<gonidelis[m]>
Isidoros: Aarya thank you for your proposals :)
<Isidoros[m]>
<satacker[m]> "meanwhile, please let me know if..." <- Thanks I would love to hear your thoughts, should I p.m. you a link?
<satacker[m]>
Yes please
<satacker[m]>
I would encourage you to remove the original doc to some other link as it is still visible in logs
<satacker[m]>
not that it would create much issue but to be on a safer side
<Isidoros[m]>
Oh i thought i deleted it
<Isidoros[m]>
Oh you mean move the doc, okay sure!
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
matrixb01x has quit [Quit: Client closed]
HHN93 has joined #ste||ar
<HHN93>
_deps/hpx-src/libs/core/algorithms/include/hpx/parallel/algorithms/detail/generate.hpp:58:32: error: no member named 'execution' in namespace 'std'; did you mean simply 'execution'?
<satacker[m]>
you'll have to use macros to check if your current build supports this
<HHN93>
got it, will update the code
<HHN93>
thank you
<HHN93>
HPX_WITH_CXX20_EXPERIMENTAL_SIMD?
<satacker[m]>
Nope, idts
<satacker[m]>
<HHN93> "CI seems to be using c++ 9" <- also i hope we are on the same page regarding `c++ 9` , it's just gcc/libstd number and not c++9, just in case I don't confuse myself
<satacker[m]>
although not necessarily the binary but libs from that i suppose
<HHN93>
is unseq policy considered experimental?
<satacker[m]>
what does cppreference page say?
<satacker[m]>
(in case of std:: always follow cppreference)
<HHN93>
ok
<HHN93>
there is HPX_WITH_CXX17_STD_EXECUTION_POLICES
<HHN93>
but it doesn't check for std::unseq
<HHN93>
I am assume its because std::execution::unseq is c++2
<HHN93>
c++20
<satacker[m]>
Either you can add a new macro that checks for this or you can use c++20 ones that just check for c++ 20 just for the sake of CI
<HHN93>
found it there is a macro
<HHN93>
HPX_WITH_CXX20_STD_EXECUTION_POLICES
<HHN93>
checks for unseq policy
<satacker[m]>
Nice
<HHN93>
sometimes my performance numbers have very high variation, should I omit these outliers?
<HHN93>
also any reason why it happens? sometimes it is >3x times the average
hkaiser has joined #ste||ar
<srinivasyadav18[>
HHN93: yes, try to run multiple times, then take mean or median over the runs
<HHN93>
outliers are probably due to my machine, right?
<srinivasyadav18[>
yea, might be. Because your machine is doing many other things while you are running the application
<jbjnr[m]>
You must also be careful when testing performance on modern cpus (like my laptop). The frequency is throttled down and up when busy/idle etc, so you can get quite wild swings in results. Can help if you use cpupower frequency-set on linux machines to fix the freq at some lower than max value too avoid throttling when it gets hot.
<HHN93>
ok I will try using frequency set, thank you
<HHN93>
The insert_iterator returned by std::inserter(), it can be a forward iterator, right?
<HHN93>
std::inserter(diff, diff.begin()), [](const int &a, const int &b)
<HHN93>
{ return a < b; });
<HHN93>
return;
<HHN93>
}`
<hkaiser>
it's an output iterator
<HHN93>
it should be a valid input to set_difference, right?
<HHN93>
std::set_difference accepts it, but not hpx::set_difference
<HHN93>
hpx throws static_assert error
<hkaiser>
ok, it should accept it for unseq or seq
<hkaiser>
if not, it's a bug
<hkaiser>
it shouldn't accept it for par or par_unseq
<HHN93>
std:: accepts it for par_unseq
<HHN93>
hpx doesn't
<hkaiser>
HHN93: the standard requires forward iterators
<hkaiser>
std::inserter returns an output iterator
<HHN93>
output iterator is suffiicientight?
<HHN93>
sufficient though, right?
<hkaiser>
accepting it for seq/unseq would be an extension, but it would make sense to support that
<HHN93>
does standard enforce an order in which set_difference should be returned?
<HHN93>
I am not sure why output itr can't be used in case of par
<Isidoros[m]>
<HHN93> "does standard enforce an order..." <- you might have already seen this, but keep in mind the order might be messed up due to: https://github.com/STEllAR-GROUP/hpx/issues/6198
<hkaiser>
HHN93: output iterators are one of the weakest
diehlpk has joined #ste||ar
<HHN93>
For input: (according to the documentation this is well defined)
<HHN93>
{ 1, 1, 1, 4, 5 }
<HHN93>
{ 1, 1, 1 }
<HHN93>
It crashes with a double free error when run with 5 or more threads
<HHN93>
now it makes sense why the program doesn't run even when there's no static assert error
<hkaiser>
HHN93: fixitfixitfixitfixit ;-)
<HHN93>
I am not able to reproduce the error now :-/
<HHN93>
std::inserter(diff, diff.begin()), [](const int &a, const int &b)
<HHN93>
{ return a < b; });
<HHN93>
return;
<HHN93>
doesn't
<HHN93>
any advice on fixing crash errors?
<HHN93>
just slowly go next with gdb?
HHN93 has quit [Quit: Client closed]
diehlpk has quit [Quit: Leaving.]
<gonidelis[m]>
K-ballo: what is the diff between concurrent progress and parallel progress guarantee? standard does not make it easy for me to understand