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/
EverYoung has quit [Remote host closed the connection]
<jbjnr>
heller_: can you make a list of 'features' that you would like to see improved in cdash. I will send them to the cdash list. Looking at the auto-remove feature, you can make old builds disappear from tracks after a certain time, but if we could make them disappear when replaced by a new one of the same build ... stuff like that
<heller_>
ok, I think I am dreaming
<heller_>
look at the console
<heller_>
jbjnr: alright, I'll see what I can come up with. TBH, I have a hard time putting everything into understandable sentences ;)
<K-ballo>
someone accidentally disabled the tests?
<jbjnr>
lol
<zao>
:D
<jbjnr>
good'ol intel. Always a reliable source of fail.
kisaacs has joined #ste||ar
<diehlpk_work>
jbjnr, Is there any reason you decided to use all cores when no parameter is provided?
<jbjnr>
yes.
<diehlpk_work>
Could you explain?
<diehlpk_work>
Yestewrday I used --hpx:thread= instead of --hpx:threads= and hpx used all my cores, instead of one core what I was suspected
<jbjnr>
multiple reasons : 1) everyone we spoke to on courses etc was confused by the idea of a multithreading runtime framework that by default only used 1 thread. 2) The new resource partitioner is useless when you only have one thread, and any attempt to create a non default thread pool would fail due to empty "default" pool - so you would have to always specify --hpx:threads=N and wanting one core is much less common than wanting 'all'
<jbjnr>
cores
<jbjnr>
* we discussed it on here and everyone agreed to the change * Sorry that you missed out!
<diehlpk_work>
No problem, just wanted to know why
<heller_>
diehlpk_work: that's more a problem with the command line handling rather then the decision to use all cores or not, either way, you would have been scratching your head about the performance, no?
<diehlpk_work>
Yes, you are right
<jbjnr>
the command line handling is a problem. (people don't like being 'forced' to use boost program options either).
<heller_>
they aren't though
hkaiser has quit [Quit: bye]
eschnett has quit [Quit: eschnett]
<diehlpk_work>
Ok, I will have a look if we can at least check for the default hpx parameters
wash[m] has quit []
wash[m] has joined #ste||ar
aserio has joined #ste||ar
eschnett has joined #ste||ar
david_pfander has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 276 seconds]
hkaiser has joined #ste||ar
<github>
[hpx] hkaiser force-pushed refactor_base_action from 7e4cabf to 2783320: https://git.io/vAvAI
<github>
hpx/refactor_base_action 2783320 Hartmut Kaiser: Refactoring component_base and base_action/transfer_base_action to reduce number of instantiated functions and exported symbols...
kisaacs has quit [Ping timeout: 248 seconds]
<mbremer>
@hkaiser: any updates on the paper?
mcopik has quit [Ping timeout: 268 seconds]
kisaacs has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
sam29 has joined #ste||ar
<sam29>
Hello, I'm trying to solve the bug #3048, can someone guide me on the prerequisites that would be needed to approach the task.
<diehlpk_work>
Can I change the parameter hpx:threads set by the user?
<zao>
As it's one of the stock examples, you wouldn't need too much to build it, just -DHPX_WITH_EXAMPLES=ON if you don't already build them. After that, well, squint at the code and see if it seems like there's some race.
<zao>
And of course, see if it reproduces at all on your machine and HPX version.
<zao>
If you're lucky it's due to bogus example code, but it might be evidence of something hosed deeper in HPX.
<zao>
Vary the environment, run with 1,2,many threads, add trace output to see how execution goes, etc.
<aserio>
heller_: have you heard of the Berlin Buzzwords conference?
<aserio>
heller_: nvm you can now read about it on hpx-users
<sam29>
zao: Thank you for the info. I'll try to proceed further as you have guided. If someone else is working on the same bug please do let me know.
<zao>
sam29: As with most debugging, it's an exploratory journey.
sam29 has quit [Ping timeout: 260 seconds]
EverYoun_ has joined #ste||ar
kisaacs has quit [Ping timeout: 268 seconds]
EverYoung has quit [Ping timeout: 276 seconds]
daissgr has quit [Ping timeout: 240 seconds]
mbremer has quit [Quit: Page closed]
mcopik has joined #ste||ar
mcopik has quit [Ping timeout: 256 seconds]
<K-ballo>
when's the tentative release date?
<hkaiser>
really soon now ;)
sam29 has joined #ste||ar
<heller_>
Does anyone have a trivial patch to commit to master? This all green is making me nervous
<heller_>
aserio: no, I haven't. But I'm receiving the fellows emails as well ;)
<heller_>
Not sure if we really fit in there, nor which story we could tell there
<K-ballo>
trivial patches cause the more redness
<hkaiser>
heller_: it's probably russian hacckers - those tend to be responsible for everything nowadays ;)
aserio has quit [Ping timeout: 276 seconds]
<diehlpk_work>
hkaiser, with a combination of static_chunk_size and guided_chunk_size we are close to blase omp for vectors
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
diehlpk_work: nice!
<hkaiser>
diehlpk_work: we probably should create a custom chunking policy for blaze, that avoids having invocations of parallel::for_loop for different policies (i.e. reduces code size)
<diehlpk_work>
hkaiser, Yes, sounds good
<diehlpk_work>
Once, I got all parameters we could do this
<hkaiser>
right
<diehlpk_work>
We have to do the same for matrix operations
aserio has joined #ste||ar
<heller_>
hkaiser: yeah. That's the only explanation ;)
aserio has quit [Ping timeout: 265 seconds]
<heller_>
hkaiser: could you take a look at #3146 please? I'd like to move on there
aserio has joined #ste||ar
kisaacs has joined #ste||ar
<aserio>
heller_: woops I meant fellows :p
kisaacs has quit [Ping timeout: 240 seconds]
daissgr has joined #ste||ar
sam29 has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 276 seconds]
kisaacs has joined #ste||ar
aserio has joined #ste||ar
aserio has quit [Ping timeout: 260 seconds]
<diehlpk_work>
heller_, With the latest version of hpx the performabce slighlty improved
<diehlpk_work>
1000000 6082.71 6185.71
aserio has joined #ste||ar
EverYoung has joined #ste||ar
EverYoun_ has quit [Ping timeout: 276 seconds]
eschnett has quit [Quit: eschnett]
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
sam29_ has joined #ste||ar
hkaiser has joined #ste||ar
sam29_ has left #ste||ar [#ste||ar]
diehlpk_work has quit [Quit: Leaving]
<github>
[hpx] hkaiser created fixing_commandline_handling (+1 new commit): https://git.io/vALWz
<github>
hpx/fixing_commandline_handling 95bb5d8 Hartmut Kaiser: Fixing the handling of quoted command line arguments.
<github>
[hpx] hkaiser opened pull request #3160: Fixing the handling of quoted command line arguments. (master...fixing_commandline_handling) https://git.io/vALWr