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/
<hkaiser>
K-ballo: nod, good question
<hkaiser>
would checking for just is_callable be enough?
<K-ballo>
I suppose, for hpx core at least
EverYoung has quit [Ping timeout: 246 seconds]
EverYoung has joined #ste||ar
patg has joined #ste||ar
bikineev has quit [Remote host closed the connection]
EverYoung has quit [Ping timeout: 246 seconds]
eschnett has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
pree has joined #ste||ar
pree has quit [Ping timeout: 245 seconds]
jaafar has quit [Ping timeout: 246 seconds]
pree has joined #ste||ar
mcopik has quit [Ping timeout: 260 seconds]
mcopik has joined #ste||ar
pree has quit [Ping timeout: 245 seconds]
pree_ has joined #ste||ar
<jbjnr>
taeguk yt? Conf cal in a few minutes ok?
<jbjnr>
or possibly taeguk[m] ^^
<taeguk>
Okay
<taeguk>
jbjnr: I'm ready.
bikineev has joined #ste||ar
david_pfander has joined #ste||ar
pree_ has quit [Ping timeout: 245 seconds]
Matombo has joined #ste||ar
bikineev has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 272 seconds]
shoshijak has joined #ste||ar
<shoshijak>
Hi all. I'm in the process of moving the command-line parsing from hpx_init(...) to the constructor of the resource partitioner, so that the resource-partitioner can expose to the user only the PUs exposed by the -affinities set in -hpx:bind etc.
<shoshijak>
Can someone tell me whether the variable "std::vector<std::string> && ini_config" used to construct the util::commad_line_handling in hpx_init is actually useful?
<shoshijak>
As far as I can tell it is used to store the parsed command line options and I see no use in letting the user supply his/her own ini_config as a parameter of hpx-init.
<shoshijak>
Objections?
mcopik has quit [Ping timeout: 260 seconds]
<heller_>
shoshijak: there is
<heller_>
shoshijak: IIRC it is filled prior to that
<heller_>
shoshijak: you can 1) provide your own vector for ini options 2) complete ini file 3) partial ini entries
<heller_>
it is indeed part of the command_line_handling
<shoshijak>
heller_ is (1) usefull, given that (2) exists?
<shoshijak>
Would anyone fill in their own vector<string> ini_config in int main() ?
<heller_>
sometimes, yes
<heller_>
to preset certain values because they make sense to the application
<heller_>
shoshijak: in general I like the idea of factoring out the command line parsing into the different components though
<shoshijak>
I did, but the contents of the INI file just get filled into ini_config during command-line-parsing and don't have much to do with passing options to hpx_init(...)
<shoshijak>
heller_ : what do you mean?
<shoshijak>
also: what about the parameter runtime_mode in the constructor of command_line_handling? I'm guessing it is superfluous to let it be set as a parameter of hpx_init since it can just be set through the command line?
<heller_>
yes, there is a lot of overlap
<heller_>
regarding ini file:
<heller_>
the ini file is our central storage of options
<heller_>
that is, all command line parameters, like --hpx:threads, have a corresponding entry in the runtime configuration (which is in the ini format)
<heller_>
the various components read their options from this runtime configuraiton
<heller_>
so yes, we parse the command line options and transform them into the ini config
<shoshijak>
yup, got that ... thanks :)
<shoshijak>
so can I remove runtime_mode from the parameters of hpx_init(...)?
<heller_>
no ;)
<shoshijak>
given there is a command line option for that
<heller_>
is this important to solve your problem?
<shoshijak>
no, I can make it work while keeping this. I just don't quite see the use ...
<heller_>
I am not objecting to reduce redundancies ...
<shoshijak>
so are you suggesting we should remove this command line option?
<heller_>
however, since it is unrelated to the problem you are solving, I am suggesting to keep that change seperated
<heller_>
one step at a time and so on ;)
<shoshijak>
okidoki
<shoshijak>
what did you mean earlier by "factoring out the command line parsing into the different components"
<heller_>
not having one global entity, but let the different components have their own runtime configuration
<heller_>
not having one global entity, but let the different components have their own runtime configuration
<heller_>
like you proposed earlier
<shoshijak>
oh... what I proposed earlier was to move the *entire* command-line-parsing to the constructor of the resource-partitioner though
<heller_>
why would you want to do that?
<heller_>
aren't there a lot of options unrelated to the RP?
shoshijak has quit [Ping timeout: 240 seconds]
shoshijak has joined #ste||ar
<shoshijak>
heller_ sorry, looks like I got disconnected for a few minutes ... did I miss something?
<heller_>
[12:02:00] <shoshijak> oh... what I proposed earlier was to move the *entire* command-line-parsing to the constructor of the resource-partitioner though
<heller_>
[12:02:29] <heller_> why would you want to do that?
<heller_>
[12:02:41] <heller_> aren't there a lot of options unrelated to the RP?
<shoshijak>
[12:03:00] <shoshijak> yes there are, but so many options are somehow kind of intertwined, and what's the point of parsing the command line options several times?
<heller_>
which ones are intertwined?
<heller_>
there is no point in parsing them several times, that's correct. That's probably the rationale of having one central instance
<shoshijak>
are all kind-of connected and needed by the RP
<shoshijak>
we can still keep one central util::command_line instance, and pass data members of this central instance to whichever other class constructor or whatever needs them
K-ballo has joined #ste||ar
<heller_>
shoshijak: yes, those are the ones the RP need.
<heller_>
shoshijak: you talked about options that are needed by the RP and other components?
<heller_>
shoshijak: what we do right now is that each component gets an instance of runtime_configuration out of which it extracts the information needed
<shoshijak>
--hpx:threads is also used in the constructorof runtime, for example
<heller_>
might be a relict and not needed anymore
<shoshijak>
not sure
<heller_>
if it really needs it, it should get the information about the number of threads fromt he RP, right>
<heller_>
?
<shoshijak>
yeah, this would make sense
<heller_>
or to put it differently, wouldn't the runtime need to instantiate an instance of the resource manager eventually?
mcopik has joined #ste||ar
<shoshijak>
no, the resource partitioner needs to be instantiated way before the runtime,since the user can setup pools in int main() and the runtime is instantiated only in hpx_init(...)
<heller_>
ok, how is the resource partitioner propagated to the runtime then>
<heller_>
how do you handle multiple localities per node?
<heller_>
(which is really only known after bootstrap, btw)
<shoshijak>
it is propagated using the util::static_ facilities, just like the runtime
<heller_>
ok
<shoshijak>
I didn't give any thought to multiple localities per node ... how does this affect the RP?
<heller_>
it affects the RP in a way that the maximum number of cores would be restricted for the process
<shoshijak>
which process?
<heller_>
the locality
<heller_>
if you run two localities per process, you don't want to share cores in between them
<heller_>
K-ballo: hey, can I install MSVC without admin rights somehow?
<heller_>
but they don't have our required version of msvc installed...
<K-ballo>
I think with VS2017 you should be able to install anywhere
<K-ballo>
even multiple instances, side by side
<heller_>
ok, I don't have admin rights on there, mind you
<K-ballo>
that said, I've never tried it myself
<heller_>
I'll try
<heller_>
would be neat to have multiple windows instances ... there is a large portion of this system essentially unused (also linux machines)
diehlpk_work has quit [Read error: Connection reset by peer]
diehlpk_work has joined #ste||ar
bikineev has joined #ste||ar
<K-ballo>
on that note, appveyor has been working wonderfully lately
hkaiser has joined #ste||ar
bikineev has quit [Ping timeout: 240 seconds]
bikineev has joined #ste||ar
<heller_>
K-ballo: what about the time limit though?
<K-ballo>
I don't know what the time limit is
<heller_>
K-ballo: I really want to replace our cloud based PR testing to reduce the time it takes for testing...
<K-ballo>
is it being slowed down by lack of hardware?
<hkaiser>
shoshijak: we parse the command line several times as we can add aliases for the command line options on the command line ;)
<hkaiser>
heller_: I disagree, I wouldn't like to have separate registries for different parts of the system
<shoshijak>
hkaiser: yes, but it makes to do each "type of parsing" (I mean "preliminary parsing" or "with aliasing") only once, right? That is what I meant
<hkaiser>
isn't that what we do?
<heller_>
hkaiser: I don't have a very strong opinion here. It makes some sense in terms of seperation of concerns.
<hkaiser>
well, we parse it a third time after all components are loaded as those can add their own options
<hkaiser>
heller_: I grew up in east germany, I like centralism ;)
<hkaiser>
shoshijak: also, 'std::vector<std::string> && ini_config' is used to pass additional confguration settings (independently from command line options)
<shoshijak>
hkaiser: but are there settings that can be set through ini_config which CANNOT be set through cmd line options?
<hkaiser>
yes, unfortunately
<hkaiser>
also, you can't add command line options programmatically, at least only painfully
<github>
[hpx] hkaiser force-pushed uninitialized_default_construct from 2ae58c9 to 0d33dcf: https://git.io/vHRP7
<github>
hpx/uninitialized_default_construct 0d33dcf Hartmut Kaiser: Adding more test cases
quaz0r has joined #ste||ar
quaz0r has quit [Ping timeout: 255 seconds]
<heller_>
K-ballo: core + inspect would be a nice start already
<heller_>
Let's see how far we get
<heller_>
wash[m]: no, we have two endpoints
<heller_>
wash[m]: sorry, one endpoint, two queues
<heller_>
K-ballo: do you mind setting appveyor up?
<K-ballo>
I might give it a try, though I'd need to figure out the caching boost part first
<jbjnr>
zao: no, the low level rdma api does not have broadcast functions, but some of the higher level apis provide some features for that (or are planning them).
<jbjnr>
zao: EISCAT 3D - say hello to Ian McCree for me - I know him well
<zao>
jbjnr: They've got some 1->100 fanout needed, and not enough bandwidth to get it out without switch broadcast assistance somehow.
<jbjnr>
wash no - we don't use one endpoint per os thread - did the chap say that this is a good thing in general
<zao>
jbjnr: Three project members had a full-day meeting in my office, as we had a sofa and whiteboard :)
<zao>
Not overly involved in it myself, but they tried to recruit me to write data shoveling software :)
<jbjnr>
data shoveling software. sounds sexy
<zao>
Kind of ambitious and interesting project, but not sure if I'd help much.
<zao>
Probably going to recruit some competent HPC people to get the coding done right.
shoshijak has joined #ste||ar
quaz0r has joined #ste||ar
quaz0r has quit [Client Quit]
quaz0r has joined #ste||ar
shoshijak has quit [Ping timeout: 255 seconds]
<heller_>
jbjnr: this one endpoint per thread is something that is supposed to be good. I've heard that from many sides already
<heller_>
I thought you had a reason for not doing it ;)
<zao>
Anyone interested in moving to Kiruna? :)
<heller_>
kiruna?
<heller_>
ahh, middle of nowhere ;)
<heller_>
do you still get gps up there?
<zao>
Heaven knows, but it's where we keep our rocket scientists.