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 [Ping timeout: 276 seconds]
EverYoun_ has quit [Ping timeout: 265 seconds]
daissgr1 has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
daissgr has quit [Quit: WeeChat 1.4]
EverYoun_ has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYoun_ has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoun_ has quit [Read error: Connection reset by peer]
EverYoun_ has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoun_ has quit [Read error: Connection reset by peer]
K-ballo has quit [Quit: K-ballo]
EverYoung has quit [Ping timeout: 268 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
asghar has joined #ste||ar
asghar has quit [Client Quit]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
hkaiser has quit [Quit: bye]
eschnett has joined #ste||ar
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
Shikhar has joined #ste||ar
jaafar has quit [Ping timeout: 252 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
pree has joined #ste||ar
<pree>
Hearty Congratulations ! for being selected as a potential mentor organization for GSoC 2018 : ) -
<pree>
All the best : )
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
pree has quit [Quit: Bye dudes]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
jbjnr has joined #ste||ar
david_pfander has joined #ste||ar
<heller_>
jbjnr: hey ... removing wait_or_add_new in itself decreases performance
<heller_>
jbjnr: I am not sure it is really the scheduler that's to blame for the missing 10%
<heller_>
I think it is more the allocations of the futures and stuff
<jbjnr>
"decreases performance" - really, that is surprising.
<jbjnr>
what actually happens in wait_or_Add_new
<jbjnr>
The thing I asumed was causing some delay was the fact that we gather 'N' tasks into bunches and allocates stacks and suchlike for all of them in one go. (making some tasks wait until there are 'enough'?)
<jbjnr>
My numa stuff isn't working at the moment, so I'm trying to fix it again.
<heller_>
the reason for the performance decrease is that now the task queue itself is under higher contention
<heller_>
and the thread_map, of course
Smasherr has joined #ste||ar
<jbjnr>
heller_: you may find that with -very- small tasks the performance is hit, but with ones larger than some threshold (but still small), the performance improves again? The matrix operations we are doind are quite long by HPX standards (1ms).
<simbergm>
could alignas help on thread_queue?
<heller_>
simbergm: i think so, yes
<heller_>
simbergm: but then, those structures are already larger than 64 bytes ;)
<heller_>
but potentially, yes, for small tasks
<heller_>
jbjnr: ok, you can give it a try for sure
<heller_>
jbjnr: I didn't observe performance increase for larger (1ms) tasks though
<heller_>
(no decrease either)
<heller_>
jbjnr: you should trying to profile the small blocks with vtune
<heller_>
and see what shows up
<heller_>
I am almost certain it has nothing to do with the scheduler itself but one of the surroundings
Smasherr has quit [Quit: Connection reset by beer]
Smasherr has joined #ste||ar
Smasherr has quit [Ping timeout: 240 seconds]
Smasherr has joined #ste||ar
Vir has quit [Ping timeout: 240 seconds]
anushi has joined #ste||ar
marco has quit [Ping timeout: 260 seconds]
eschnett has quit [Read error: Connection reset by peer]
eschnett has joined #ste||ar
<simbergm>
heller_, jbjnr: it seems like octotiger was hanging with one thread because when you do schedule_last with the lifo queue backend a thread still gets scheduled first
<simbergm>
so I would change to use deque in all the queue backends, but I was wondering if anyone has already done some benchmarking and concluded that deque is clearly slower than stack/queue?
<simbergm>
maybe also relevant for cholesky... jbjnr what backend do you use in your scheduler?
<jbjnr>
at the moment, abp_lifo
<heller_>
deque is slower since the implementation uses dcas, which is not lockfree
<heller_>
IIRC
<jbjnr>
I vary them from time to time to experiemnt, but don't seem to get much differnceeither way
eschnett has quit [Quit: eschnett]
<jbjnr>
myspacebarisnotworkingwell btw
<simbergm>
heller_: dcas? something compare and swap?
<heller_>
double word compare and swap, yes
<simbergm>
hrm, in most cases one would never see this because one runs with >> 1 thread
<diehlpk_work>
Lol, heise online asked for an interview or article about us as an organization for gsoc
<jbjnr>
heller_: simbergm hkaiser cdash has been updaded to latest version. http://cdash.cscs.ch/index.php?project=HPX is dashboard -link should be same as old one. So far nothing has been submitted, so let me know if builds should be appearing but do not show up. I've just started a full rebuild on daint to test.
<jbjnr>
bad news : we have wiped the old database, so old results are gone.
<jbjnr>
good news, new dashboard should a have a few more features. we'll see
<heller_>
thanks for the update
<simbergm>
jbjnr: nice! will push some PRs soon to populate it
<jbjnr>
I messed up the tracks. should start look like before from tomrrow
<jbjnr>
or after next push. we''ll find out ...
CaptainRubick has joined #ste||ar
<hkaiser>
jbjnr: thanks for your work on this!
<jbjnr>
<says the man who never looks at it and prefers buildbot>
<hkaiser>
;-)
<hkaiser>
I told you that I appreciate you're doing this, and I mean it
<CaptainRubick>
Hey I am new here. I looked through the idea page of Ste||ar for GSoC '18. Is someone working on concurrent data structures project?
<hkaiser>
CaptainRubick: not at this moment
<jbjnr>
CaptainRubick: not yet, but you can be first in in you want
<jbjnr>
^if
<CaptainRubick>
How do you suggest I begin research on this?
<jbjnr>
how much do you know already?
<CaptainRubick>
I have been working on implementing LevelDB which is an API for concurrent string map by google
<CaptainRubick>
Currently this is my project for Microsoft research
Smasherr has quit [Quit: Connection reset by beer]
<jbjnr>
wel ... we've got boost::lockfree data structures - but there are only really a queue/deque/stack, a decent concurrent vector, map, and other stuff would be useful.
<CaptainRubick>
This is my work.
<github>
[hpx] KADichev opened pull request #3170: Add cmake flag -DHPX_WITH_FAULT_TOLERANCE=ON (OFF by default) to igno… (master...resilience) https://git.io/vAOHZ
<CaptainRubick>
Ok so I will look through already implemented DS
<zao>
CaptainRubick: Hi there!
<CaptainRubick>
What else do you expect from this project?
<jbjnr>
if you spend some time googling the subject, you'll discover that it's not easy to make nice lock free containers and plenty of others have implmented many of them, so code is out there, but we can't use it if it isn't boost licensed - so the task would be to learn all you can and then implement 'some' containers on your own essentially.
<CaptainRubick>
Alright
<CaptainRubick>
Leveldb uses concurrent skiplist. So that might be a candidate for inclusion in the project
<jbjnr>
"What else do you expect from this project?" - well we could do with a maintained/tested and working hpx::concurrent namespace with a bunch of containers in
<zao>
https://liblfds.org/ probably has some decent links in their docs section.
<jbjnr>
where boost::lockfree are available, just a typedef to them is ok, other we need
<github>
[hpx] pierrele opened pull request #3171: adding the missing unset() function to cpu_mask() for case of more th… (master...master) https://git.io/vAOHw
<jbjnr>
otherS - we need. I meant to say
<CaptainRubick>
Hi @zao
<CaptainRubick>
Alright thank you. I will go through the resources and contact again.
<jbjnr>
no probs
Smasher has quit [Remote host closed the connection]
<diehlpk_work>
gentryx, heller_ could you accept the invitation for gsoc?
Smasherr has joined #ste||ar
Smasherr has quit [Client Quit]
simbergm has quit [Ping timeout: 256 seconds]
eschnett has quit [Quit: eschnett]
david_pfander has quit [Ping timeout: 252 seconds]
Anushi1998 has joined #ste||ar
simbergm has joined #ste||ar
eschnett has joined #ste||ar
Smasherr has joined #ste||ar
<Anushi1998>
My name is Anushi Maheshwari and I am a competitive coder mostly active on various online platforms (Codeforces, Codechef etc. with handle anushi).I am looking to get into open source development in Ste||ar through this GSOC'18.I am comfortable in C++, Python, and MATLAB.
<hkaiser>
welcome Anushi1998
<Anushi1998>
I am working on a bug #2954 and requires some clarity regarding that
<hkaiser>
cool!
<zao>
Ooh, that's my report.
EverYoung has joined #ste||ar
<hkaiser>
Anushi1998: just ask away here if you need help
<Anushi1998>
The bug is about replacing std::rand with separate PRNG like MT but as far as I have studied rand is already implemented with Mersenne Twister algo isn't it?Why it requires separate implementation?Or please correct me if I am wrong anywhere
<Anushi1998>
zao, Yes
<hkaiser>
Anushi1998: the ticket explains the immediate problem
<zao>
Anushi1998: The problem with std::rand is that RAND_MAX varies among platforms.
<hkaiser>
the other issue with std::rand is that is going to be deprecated as it's not thread safe
jbjnr has quit [Read error: Connection reset by peer]
Smasherr has quit [Quit: Connection reset by beer]
Smasherr has joined #ste||ar
Smasherr has quit [Client Quit]
Smasherr has joined #ste||ar
Smasher- has joined #ste||ar
Smasherr has quit [Ping timeout: 240 seconds]
<parsa[w]>
hkaiser: ping
<hkaiser>
parsa[w]: here
<parsa[w]>
hkaiser: primitive performance counters are unique per instance. duplicate entries come from elsewhere... i can go through them and remove the duplicates (which have the same sequence id but have different instance ids) but what do we need those duplicate entries in agas for?
<hkaiser>
could be that the sequence ids are generated in some wron gway
<parsa[w]>
are you saying there's only one sequence id maps that maps to an instance id?