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/
ct_clmsn_ has joined #ste||ar
taeguk[m] has joined #ste||ar
parsa has joined #ste||ar
rod_t has left #ste||ar [#ste||ar]
parsa has quit [Quit: Zzzzzzzzzzzz]
eschnett has joined #ste||ar
ct_clmsn_ has quit [Ping timeout: 240 seconds]
patg has joined #ste||ar
<patg> wash[m]: yt?
daissgr has quit [Remote host closed the connection]
parsa has joined #ste||ar
hkaiser has joined #ste||ar
<patg> hkaiser: wash[m] wash I made reservation
<hkaiser> patg: yah, thanks a lot
<hkaiser> how long takes the drive from ABQ?
<patg> depends on where you are and the traffic
<hkaiser> we're directly at I40
<patg> so you have to get to I 25 then go North, probably 1 hr and 15 or 30 minutes
<patg> Bryce has my phone number have him text me when you leave
<hkaiser> ok
<patg> I'll probably leave about the same time
EverYoung has quit [Ping timeout: 250 seconds]
<parsa> hkaiser: i've been waiting on appveyor forever... but other than that #99 is ready
<hkaiser> parsa: ok, tks - will look
<hkaiser> parsa: what's next?
<parsa> pfx counters
<hkaiser> nice
hkaiser has quit [Quit: bye]
patg has quit [Quit: See you later]
parsa has quit [Quit: Zzzzzzzzzzzz]
jbjnr has quit [Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]]
jaafar_ has quit [Ping timeout: 258 seconds]
jbjnr has joined #ste||ar
jbjnr has quit [Client Quit]
jbjnr has joined #ste||ar
<jbjnr> heller: yt?
<heller> jbjnr: hey
<jbjnr> you're not araound any more? too much job hunting?
<jbjnr> question ...
<heller> jbjnr: I am always around
<jbjnr> I have a specialization that is working for me to handle dataflow type operations on my custom executor, it looks like this https://gist.githubusercontent.com/biddisco/352c305d8e249426d8175c416b64503c/raw/bd21feb936e0690e366315d6c257b22db841108c/gistfile1.txt
<jbjnr> but ...
<jbjnr> it turns out that my dataflow stuff is using a mixture of futures and shared_futures
<jbjnr> what wouold be the best way (IYHO) to handle the case of mixed future<> and shared_future<> in my specializations?
<heller> tricky
<heller> but there is a trait, is_future
<heller> so you'd need to use that
<jbjnr> hmmm.
<heller> or in other words: don't spell out the concrete future type
david_pfander has joined #ste||ar
gedaj_ has quit [Ping timeout: 260 seconds]
gedaj has joined #ste||ar
gentryx has joined #ste||ar
<github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/vF477
<github> hpx/gh-pages 5bac6c4 StellarBot: Updating docs
<msimberg> jbjnr: I'm trying to run the throttle test with multiple pools, but am failing to get the number of threads of my added pool
<msimberg> setting up the pool seems okay
<msimberg> I get the "resource partitioner does not own a thread pool named 'pool-2'" when I do get_num_threads
<jbjnr> so what is incorrect?
<msimberg> am I allowed to access details of pools that I'm not running on?
<jbjnr> what is failing?
<msimberg> and according to the debugger the vector which is supposed to have two pools has only the default one
<msimberg> hpx::resource::get_num_threads
<msimberg> line 22
<msimberg> second time around
<msimberg> i.e. not for the default pool
<jbjnr> 2nd time around? you mean all is ok on the first hpx::init but not the second?
<msimberg> exactly
<jbjnr> check that when hip::init returns, it doesn't wipe the RP or something
<jbjnr> hpx::init
<jbjnr> could be that on the 2nd hpx::init, the RP is empty
<msimberg> ah good point
<msimberg> at least I'm setting up the rp correctly for the first time?
<jbjnr> and we should fix it to not do that if that's what is happening.
<jbjnr> looks ok. I presume its a cut'n'paste job
<msimberg> more or less, from one of the rp examples
<jbjnr> jugglers in a moment - you watching it?
<msimberg> it's lunch time
<jbjnr> free lunch here :) gtg
<msimberg> thanks!Q
<msimberg> jbjnr: that was indeed it, but I think the current behaviour is perfectly ok
<jbjnr> ok
hkaiser has joined #ste||ar
<heller> hkaiser: ha! I got rid of the factory create functions now ;)
<hkaiser> g'morning
<heller> good morning
<hkaiser> yah, th epools are centralized now after th eone_size_heap patch
<heller> not yet
<heller> but almost
<hkaiser> ok, let's see
<heller> turns out we had lots of multiple heaps around, especially for promise
<hkaiser> nod
<heller> not sure why it never hit us before
<heller> all in all, I am able to flesh out a lot of duplicated code we had
jbjnr has quit [Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]]
<hkaiser> good
jbjnr has joined #ste||ar
<heller> reduced the binary size by 15MB already ;) (started from 365MB)
<hkaiser> nice
<heller> for libhpxd
jbjnr has quit [Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]]
jbjnr has joined #ste||ar
jbjnr has quit [Client Quit]
jbjnr has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
<heller> hkaiser: another big question to me right now is wether to fix the disabling/enabling of components
<heller> hkaiser: local_new completely circumvents it atm
<heller> or if we shouldn't get rid of it entirely
<hkaiser> heller: I don't think we should get rid of it
<heller> ok
<heller> then I'll reenable it ;)
<hkaiser> local_new circumvents it, yes - you initial fix to use the factories for this as well would have made it work again
<heller> right
<heller> using the factories made the local_new unit test fail
<hkaiser> why do you want to get rid of factories?
<heller> there is no way to fix it
<heller> for this particular use case
<hkaiser> what is the problem?
<heller> it tries to move an object, but the test case explicitly tests that it is passed on by reference
<heller> we can't use perfect forwarding in the factories, because of virtual functions
<hkaiser> k
<hkaiser> FWIW, I doubt that we can get rid of the factories
<heller> where we try to circumvent that limitation by moving the passed parameters into a function object and use that to call the ctor
<heller> why do you think so?
<hkaiser> there was a reason why we introduced them in the first place
<heller> which is?
<hkaiser> being able to anonymously create an object without knowing its type
<hkaiser> components are plugins
<hkaiser> but YMMV
<heller> right now, you have to at least know the component ID
<hkaiser> yes
<hkaiser> I meant the c++ type
<heller> sure
<heller> but without the C++ type, you can't really do a lot with the GID you get back
<hkaiser> not sure, we might not need this particular feature, but can we really get rid of dynamic component type discovery etc.?
<heller> you mean if a component is present on a given locality or not?
<hkaiser> we iterate over all shared libraries to discover which components are present
<heller> yes
<hkaiser> but this might be unrelated - need to look closer
<heller> we currently have two seperate entities for that: the registry and the factory
<heller> the registry provides the ini config, the factory is responsible for type ID assignment, creation and destruction
<heller> I am not saying we should get rid of all those features
<hkaiser> k
<heller> the anonymously creation of components is not used at all in our code base, btw
<heller> dynamic enabling/disabling, I'm not sure wether to keep it or not ... I am tending towards no though
<hkaiser> heller: you're always quick in discarding existing functionalities
<heller> with the reason being, that it is not really a common use case, which means that the majority has to pay for something that's not used
<heller> I am here to discuss it with you, no?
<hkaiser> the price is relatively small, though
<heller> at runtime, yes
<heller> the price you pay is with the compile time
<hkaiser> this feature is used by the tests: special components needed for testing/debugging only do not get in the way for production cases
<heller> yes, I know that it is used there
<hkaiser> what is the compile-time cost? an additional if(enabled) statement?
<heller> no. the static objects with fairly long symbols and high instantiation costs
<heller> I'm wrapping up what I have now first though, without removing functionality
<hkaiser> shrug, I'd leave this in
<hkaiser> call me oldfashioned
<heller> I want a world where we don't need all this boilerplate to have components :P
<hkaiser> sure, you loose fine-control however - and I'm not sure if this would be good
<heller> I hear you
<heller> I am wondering if this fine control isn't achievable otherwise
<heller> baby steps...
<jbjnr> help!
<heller> one thing is certain however, without the factory, the runtime_support will be much, much more lightweight
<hkaiser> heller: ok - if you can still maintain proper memory management
<hkaiser> jbjnr: wazz'up?
<heller> hkaiser: yes, that's what I have right now
<jbjnr> how do I match nested parameter packs
<jbjnr> I need to specialize on future<p1>, future<p2>, shared_future<p3> ...
<jbjnr> I need the Ps, so I can't just say future and ignore the internal types
<jbjnr> so it has to match a list of futures on types, but they might be shared or normal futures
<heller> line 7 sounds wrong
<jbjnr> what about line 3?
<heller> you essentially say: tuple<false/true>
<jbjnr> oops
<heller> I can't parse you wrote here...
<jbjnr> yes, it shoud have the types of each
<heller> break it up into smaller pieces
<heller> first, you have your outer Future
<jbjnr> shit. I forgot the pouter future.
<heller> no need for it be a template-template
<jbjnr> that is not important for now. let me clean up and retry
<heller> you can extract the value type of a Future
<jbjnr> yes. I need value types of all inner futures
<heller> so: Future -> is_future<Future> && is_tuple<future_traits<Future>::result_type> && all_of<is_future<future_traits<Future>::result_type>...>
<heller> more or less
<jbjnr> lol
<jbjnr> more or less
<jbjnr> useful thanks
eschnett has quit [Quit: eschnett]
<heller> hkaiser: btw, the special components we have for testing, which are disabled by default, are suspect of the local_new improvements to circumvent the factory
K-ballo has quit [Remote host closed the connection]
<jbjnr> doe it actually expand both packs when I do this? https://gist.github.com/biddisco/2a443c29d0e5aea4cdcc2d3b55d18778
K-ballo has joined #ste||ar
<jbjnr> it should expand into future1<p1>, future2<p2>, future3<p3> ???
<jbjnr> omg. future_traits lets me do it more easily.
<jbjnr> thanks heller - seeing the future_traits made me realize there was an easier way of doing it.
<hkaiser> heller: sure, local_new optimization I introduced is broken and needs fixing
<jbjnr> YES!
eschnett has joined #ste||ar
<heller> hkaiser: almost there...