nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
rori has joined #ste||ar
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
simbergm, rori: yt?
<rori>
yep
<hkaiser>
hey
<simbergm>
yuo
<hkaiser>
you guys are on the roll!
<hkaiser>
question wrt the concurrency module you mentioned
<hkaiser>
we have two types of synchronization primitives (and I gues this is what the concurrency module is all about)
<hkaiser>
the purely local ones and most of the time distributed equivalents
<hkaiser>
the planned concurrency module would hold the local synchronization types, right?
<hkaiser>
what's your plan there?
<simbergm>
so, the plan is that this concurrency module would be os-level synchronization primitives like the spinlock, barrier (the one that used to be in compat), etc.
<simbergm>
not lcos
<simbergm>
so lcos, both distributed and local, would come later
<simbergm>
but I agree that the naming could lead you to think that concurrency would be what we currently have in lcos
<hkaiser>
nod, lcos would depend on threading anyways
<hkaiser>
distributed lcos depend on actions/components...
<simbergm>
exactly
<hkaiser>
ok, gotcha
<hkaiser>
thanks
<simbergm>
so the concurrency module that's coming up next contains barrier, deque, itt stuff, spinlock{_pool}, thread name, and the local register_locks stuff
<hkaiser>
btw, boost spinlock is 100% self-contained, so we could move it out of boost
<simbergm>
ok, that would maybe be worth it
<hkaiser>
simbergm: wouldn't the lockfree stuff be ok as part of this module as well?
<simbergm>
hkaiser: indeed, it should be moved as well
<hkaiser>
simbergm: sounds good to me, thanks for all the work you guys are doing
<jbjnr__>
don't call it concurrency though. that should be saved for lockfree containers and stuff.
<hkaiser>
simbergm, rori: once you're through with modularization you will know HPX better than anybody else :-)
<simbergm>
jbjnr__: it will contain those as well
<simbergm>
but suggestions are welcome
<jbjnr__>
I was playing with libcds last night and wishing we had more containers in hpx
<hkaiser>
jbjnr__: why not use those directly?
<jbjnr__>
we need a lockfree deque that is super fast
<jbjnr__>
mostly because - time
<hkaiser>
lol
<jbjnr__>
we needed that decent gsoc student to do it
<hkaiser>
be my guest
<hkaiser>
simbergm: I was thinking more about inter-module structure
<jbjnr__>
all the mutex stuff in libcds would need to be converted to ours, then it should mostly just work. Or we leave out the stuff that uses locks, but then there's not much left
<hkaiser>
would it make sense to introduce something like module-'tiers' (whatever the term)
<jbjnr__>
I need to read up on flatcombining
<hkaiser>
and create special targets (i.e. hpx::tier0, hpx::tier1, etc.)
<hkaiser>
this might even be reflected in the directory structure of the libs directory
<jbjnr__>
sorry, misunderstood
<simbergm>
hkaiser: yes, I think that's a good idea
<simbergm>
what I have in mind at the moment is to eventually instead of creating the one big hpx library, create a few smaller ones that combine modules that are pretty much always used together, so essentially your tiers
<hkaiser>
simbergm: btw, the dependency graphs generated from the modules so far are very clean ;-)
<hkaiser>
K-ballo : will be happy
<simbergm>
something like hpx_base, hpx_threading/threadpools, hpx_configuration, hpx_runtime, etc.
<hkaiser>
right
<hkaiser>
allmost everything we have so far (except algorithm and related) would go into hpx_base/hpx_core
<simbergm>
but I think I want to have all of hpx moved into modules first before we start doing that level
<simbergm>
yep
<hkaiser>
threading might be above
<hkaiser>
and local lcos
<simbergm>
yep
<hkaiser>
nice
<simbergm>
would you mind btw if we create a massive runtime module which contains everything in hpx/runtime (except threading) for now?
<hkaiser>
lol
<hkaiser>
I think that should be last, as it ties together everything
<simbergm>
untangling that will take time... but getting that into a module would let us create hpx_compute, hpx_lcos modules already now
<simbergm>
well, it kind of sits in the middle
<hkaiser>
its the whole reason for the modularization, I think
<hkaiser>
it is the place where the circular dependencies manifest
<jbjnr__>
just do it. the problem will be leeping the docs in line as things are tangled and untangled over time
<jbjnr__>
^keeping
<hkaiser>
simbergm: I'm not sure what the best course would be - I tend to hope that the modules we separated are kind of 'ready' - otoh, we want to keep changes to a minimum
<hkaiser>
I believe that we should take the runtime_support class apart, which should be possible as it has almost no state (and is a singleton anyways)
<simbergm>
hkaiser: don't get me wrong, it's one of the most important things we need to modularize, it's just that getting that untangled will take a lot of time, and we can get all the other pieces into place before we untangle that if it goes into a module
<hkaiser>
that should allow for having different pieces in different modules
<simbergm>
it will not be left undone if that's what you're worried about
<hkaiser>
if you say so ;-)
<simbergm>
(given infinite time...)
<hkaiser>
(this IRC is logged - heh)
<simbergm>
it will be given a good shot at least
<hkaiser>
should we try to isolate the parts of the runtime that are needed for each of those modules you mentioned?
<hkaiser>
(I'm not worried about hpx_compute, btw - this should be fairly self-contained anyways)
<simbergm>
me neither, we just can't make it a module without a circular dependency right now
<simbergm>
gtg
<hkaiser>
simbergm: is it the global APIs you're concerned about?
<simbergm>
but where would you start with splitting off a module for e.g. distributed lcos
<hkaiser>
simbergm: let's discuss later once you have more time
<simbergm>
they need components, actions, naming, serialization, etc. and those are all very dependent on each other
<simbergm>
yep
<simbergm>
hkaiser: back again
<hkaiser>
welcome back
<simbergm>
we don't have to take this now, but should we try to get back to our hpx calls? you're on holidays right?
<simbergm>
thanks :P
<hkaiser>
yah, regular calls would be good
<hkaiser>
I'm travelling today but would be able to make it otherwise
<hkaiser>
I'm officially off until 19th
<simbergm>
right, no worries, I wasn't thinking about today
<simbergm>
just if we should schedule the next one already
<simbergm>
so we don't forget and I ask the same thing in a month
<hkaiser>
might be good as things progress quickly
<simbergm>
we used to do wednesdays? how about the 21st?
<simbergm>
two weeks from now
<hkaiser>
ok, sounds good - let's tie Adrian into it as well
<simbergm>
yep
eschnett has quit [Quit: eschnett]
<simbergm>
we can take the runtime then... ;) auriane will be off for a week next week so things will slow down a bit as well
<simbergm>
and I need to do other things too...
<simbergm>
jbjnr__: heller: free for a call on the 21st?
<jbjnr__>
yes. talk about???
<simbergm>
just our regular hpx calls
<simbergm>
whatever is important at the moment
<jbjnr__>
k
<heller>
I'm on vacation from 16th to 31st
<simbergm>
meaning you're free to work on hpx? ;)
<jbjnr__>
4pm our time?
<simbergm>
I guess
<hkaiser>
simbergm: I think we don't need to modularize the runtime just to be able to extract the rest
<hkaiser>
we already have modules that depend 'on everything'
<simbergm>
hkaiser: will you ask aserio to schedule it? he seems to be offline
<hkaiser>
simbergm: I'll send him a note
<simbergm>
hkaiser: the header only modules?
<hkaiser>
21st 9am/4pm?
<simbergm>
yep, sounds good
<hkaiser>
even if it's not header only, we link everything into one shared library anyways
<simbergm>
ok, we just have to add an ugly target_include_directories to the main include directory
<simbergm>
I just mean that moving all of the runtime into a module would let us create all the modules correctly without hacks, and it can then be split up in-place into smaller modules
<hkaiser>
hmm
<hkaiser>
the algorithms for instance do depend on everything else as well
<hkaiser>
what'd be different for lcos, for instance?
<simbergm>
source files
<simbergm>
cpp files
<hkaiser>
ahh
<hkaiser>
and having a single target_include_directories would mitigate the issue?
<simbergm>
I think so...
<hkaiser>
I tend to believe that this would be the easier (temporary) solution then
<simbergm>
well, either way, I don't think moving it to a module (really without any functional changes) would be much harder ;)
<hkaiser>
feels 'dirty' to me, even more so as cpp_depends looks at all the #includes
<hkaiser>
not sure if that would circumvent circularities
<hkaiser>
simbergm: but in general, I'd leave it to you - you have been thinking much more about this
<simbergm>
I feel like we're not quite on the same page... it feels much cleaner to me :/
<hkaiser>
just please don't let yourself be guided by a false sense of progress
<simbergm>
duly noted
<simbergm>
keep in mind that having the lower levels of hpx (thread pools etc.) modularized is much more important to us than having the distributed machinery modularized
<hkaiser>
we're not rushing anywhere with this modularization, really
<hkaiser>
simbergm: right - that's exactly my concern, frankly
<hkaiser>
once that's done, the rest might be left in whatever state you leave it as your superiors will prevent you from pulling through
<simbergm>
understandable
<simbergm>
I can't really say anything to make you less concerned about that except that I'll try my best to have that not happen
<hkaiser>
:D
<simbergm>
I don't want it to happen
<hkaiser>
good
<hkaiser>
thanks
<simbergm>
but then I'm not my own boss
<simbergm>
also, we'll need a lot more help from you/heller with the runtime
<hkaiser>
well, you have some control over the sequence of things
<simbergm>
yep, that's true
<hkaiser>
so having the parts that are interesting to CSCS done only after the things those parts depend on modularized would lend you some time
<simbergm>
I'll talk my bosses, ben is understanding ;) plus this is getting a bit political already so we might want to discuss this offline
<hkaiser>
simbergm: sure, I'll be happy to help where I can with the runtime
<simbergm>
hkaiser: ?️
eschnett has joined #ste||ar
<simbergm>
aaand the cuda build is broken again...
aserio has joined #ste||ar
aserio1 has joined #ste||ar
<hkaiser>
\o/
<hkaiser>
simbergm: btw, in the very end we will have to have something which is not a 'module' that exposes the global APIs
<hkaiser>
so in the en we will need that global include directory anyways
<hkaiser>
end*
<hkaiser>
essentially th eglobal functions in namespace hpx
aserio has quit [Ping timeout: 264 seconds]
aserio1 is now known as aserio
<aserio>
hkaiser: did you take a picture of those LSU tags Terrie was talking about?
<hkaiser>
yah
<hkaiser>
will send
<aserio>
Thanks!
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio1 is now known as aserio
hkaiser has quit [Ping timeout: 276 seconds]
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
lsl88 has quit [Read error: Connection reset by peer]