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/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
bobakk3r has joined #ste||ar
bobakk3r_ has quit [Ping timeout: 246 seconds]
K-ballo has joined #ste||ar
<gonidelis[m]> when i launch a parallel hpx algo with hpx::execution::par, how many threads do i get?
<gonidelis[m]> i suspect it's the maximum
<gonidelis[m]> but i want less ;p
<srinivasyadav227> gonidelis[m]: i think we can pass --hpx:threads=n
<gonidelis[m]> a shit great
<gonidelis[m]> was using the wrong directive
<gonidelis[m]> srinivasyadav227: thanks
<gonidelis[m]> !
<srinivasyadav227> ;)
<jedi18[m]> Hi! Could someone tell me why I am getting these errors? https://cdash.cscs.ch/buildSummary.php?buildid=157517#!#Build
<jedi18[m]> Is that the reason or is it somethign else/
hkaiser has joined #ste||ar
<K-ballo> jedi18[m]: because those functions are deprecated, and the warnings they produce are being promoted to errors by some compiler flag
<K-ballo> change the code as the message indicates
<gonidelis[m]> now can i spawn more threads than my CPU has
<gonidelis[m]> ?
<jedi18[m]> I see thanks that makes sense, and I guess the pragma statements tell it to ignore the deprecated declaration warnings? If so why is it already working here https://github.com/STEllAR-GROUP/hpx/blob/87c0d769cd627a70c1e1d81a63b408b68a952c26/libs/parallelism/algorithms/include/hpx/parallel/container_algorithms/fill.hpp#L133 without those?
<K-ballo> what's working?
<jedi18[m]> I mean there are no errors when this is built by the CI
<jedi18[m]> Are the deprecated warnings not being promoted to errors here?
<K-ballo> where is it being called?
<jedi18[m]> Nowhere, but then neither is the one in my branch.
<K-ballo> yours is probably actually called, this one is a dependent call on a function template, no instantiation -> no functoin
<K-ballo> link to yours?
<K-ballo> where's the call?
<jedi18[m]> That's what I'm saying, it's not being called anywhere
<jedi18[m]> Or wait
<gonidelis[m]> check the example
<gonidelis[m]> `std::views::reverse`
<gonidelis[m]> without parenthesis
<gonidelis[m]> to be honest the compiler was complaining for my empty parenthesis
<hkaiser> gonidelis[m]: you can spawn as many threads as you like, if you create too many kernel-threads however, the system might slow down
<hkaiser> gonidelis[m]: creating many hpx threads however is not as big of a problem
<jedi18[m]> K-ballo: Well it looks like one of the regression tests does (fill_executor_5016.cpp)
<K-ballo> yep, that's what the error is saying
<K-ballo> fwiw, if you build locally the error message will probably tell you where exactly the call is
<K-ballo> cdash in its usefulness decides to strip all the relevant information
<gonidelis[m]> hkaiser: yeah that's what i wanted: to achieve saturation
<gonidelis[m]> hpx:threads though won't let me exceed 16 threads
<hkaiser> you can create as many hpx::threads as you like
<gonidelis[m]> god
<jedi18[m]> K-ballo: Oh ok thanks!
<gonidelis[m]> `:` -> `::`
<hkaiser> but --hpx:threads defines the number of kernel threads created, if that number is higher than the number of cores things will slow down
<gonidelis[m]> yeah great
<gonidelis[m]> about the reverse thing... does it seem cogent?
<hkaiser> yes, I was wrong, apparently
<gonidelis[m]> no i mean does it seem logical that eric chose this way of implementing it
<gonidelis[m]> ?
<hkaiser> *shrug*
<gonidelis[m]> huh
<hkaiser> it's a matter of taste
<hkaiser> it's a design decsion, if it's applied consistently - fine
<gonidelis[m]> hkaiser: definately. do you think it's ok if i just report strong scaling
<gonidelis[m]> ?
<hkaiser> sure
<gonidelis[m]> great
<mdiers[m]> hkaiser: Have you found time to look at #5117 yet?
<hkaiser> no success, I have started looking but was not able to reproduce the issue
<mdiers[m]> When I run my last example distributed on multiple nodes I get it reproduced.
<hkaiser> :/
<mdiers[m]> Of course only with the optimized compilation.
<hkaiser> ahh
<hkaiser> I tried in debug
<mdiers[m]> Race conditions without optimization? Interesting 😉
<gonidelis[m]> hkaiser: shouldn't hpx::threads=1 give me the same time as when the algo is called with `execution::seq` poicy
<gonidelis[m]> ?
<gonidelis[m]> policy^^
<hkaiser> gonidelis[m]: it will probably a bit slower
<hkaiser> be*
<gonidelis[m]> hm
<gonidelis[m]> say "lot" ...
<hkaiser> shouldn't be that bad
<gonidelis[m]> 10000000 elements
<gonidelis[m]> --hpx:threads=1 -> 13.8554s
<gonidelis[m]> [Seq] - 3.09428s
<hkaiser> gonidelis[m]: that requires some investigation - something is off there
<srinivasyadav227> hkaiser: can you please retest this https://github.com/STEllAR-GROUP/hpx/pull/5309?
<gonidelis[m]> yup
<gonidelis[m]> i put it on my books
<hkaiser> is [Seq] run with --hpx:threads=1 as well?
<gonidelis[m]> no
<gonidelis[m]> ahhh yes
<gonidelis[m]> it does
<hkaiser> ok
<gonidelis[m]> but since it's seq it shouldn't matter
<hkaiser> show me the example, pls
<hkaiser> is this a release build?
<hkaiser> -DCMAKE_BUILD_TYPE=Release?
<gonidelis[m]> yes
<hkaiser> ok
<hkaiser> is that a general observation or something specific to this combination of algorithms?
<gonidelis[m]> that's what i am checking right now
<gonidelis[m]> let me see
<gonidelis[m]> the reports i made was on hpx vs range-v3 parallel algos, range-v3 being the seq one
<gonidelis[m]> but there is still a difference on hpx-par vs hpx-seq algos
<gonidelis[m]> significantly smaller though
<gonidelis[m]> significantly smaller on another example... the one i posted to you shall be according to what i reported
<gonidelis[m]> therefore it fully depends on the combination
<gonidelis[m]> apologies if i may confused u
<hkaiser> does it depend on the iterator category?
<hkaiser> gonidelis[m]: ^^
<hkaiser> what we should do is to fall back par to seq if only one core is involved
hkaiser has quit [Quit: bye]
nanmiao has joined #ste||ar
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
RostamLog has joined #ste||ar
hkaiser has joined #ste||ar
nanmiao19 has joined #ste||ar
nanmiao has quit [Ping timeout: 240 seconds]
nanmiao has joined #ste||ar
nanmiao19 has quit [Ping timeout: 240 seconds]
<gonidelis[m]> hkaiser: yt?
<hkaiser> here
<gonidelis[m]> om
<gonidelis[m]> pm
<gonidelis[m]> ^^
hkaiser has quit [Read error: Connection reset by peer]
diehlpk_work has joined #ste||ar
Vir has quit [*.net *.split]
Vir has joined #ste||ar
<gonidelis[m]> do we have an `unseq(task)` policy
<gonidelis[m]> ?
hkaiser has joined #ste||ar
nanmiao has quit [Quit: Connection closed]