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/
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
hkaiser has quit [Quit: bye]
EverYoung has quit [Ping timeout: 260 seconds]
pree has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
<pree>
what the HPX_REGISTER do ? Is it something related to AGAS service stuff's. I found lot more in hp
<pree>
* hpx components . And how they are useful?
<pree>
and what's the diff between hpx_regiter_action and hpx_register_action_declaration ?
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
patg has joined #ste||ar
pree_ has joined #ste||ar
pree has quit [Ping timeout: 240 seconds]
patg has quit [Quit: See you later]
<heller_>
pree_: the difference between declaration and definition
pree_ has quit [Ping timeout: 260 seconds]
pree_ has joined #ste||ar
<pree_>
sorry i was disconnected. But my question is what HPX_REGISTER actually do ? Because I didn't come from distributed background.
<pree_>
It makes me think why we need this.
quaz0r has quit [Ping timeout: 245 seconds]
quaz0r has joined #ste||ar
Matombo has joined #ste||ar
<heller_>
pree_: they register actions for portable serialization
<taeguk>
In hpx, Doesn't Circle CI perform all unit tests?
<taeguk>
It seems to perform only hello_world tests...
<taeguk>
and inspection..
<jbjnr>
taeguk - it should run unit tests ...
<jbjnr>
but I can't see them either on the circleci page
<heller_>
It does not, unfortunately
<heller_>
It would take way too long
<heller_>
We clearly need a better pr testing
<heller_>
Better testing infrastructure in general
<jbjnr>
odd. running the unit tests only takes 5 minutes if none of them hang and with a ctest timeout of (say) 30 seconds and an overall kill of the ctest, we could surely run the unit tests as well
<jbjnr>
heller_: question :
<jbjnr>
why is there an executor_base class and an executor class, but they are not part of the same heirarchy?
<taeguk>
Currently, Circle-Ci just check compile-success, inspection-success, and just hello world tests. I think it is very lack. It should be improved.
<jbjnr>
taeguk correct
<taeguk>
Most of time (3hours) is used for just only checking compile-success.
<jbjnr>
you can (and should) do a "ctest -R tests.unit " before you submit your PR of course.
<heller_>
jbjnr: ask Hartmut, no idea ;)
<jbjnr>
ok
<heller_>
jbjnr: 5 minutes on a fast machine, iirc
<jbjnr>
of cpourse, the problem is that we never have a green dashboard with all tests passing, so no PRs would ever be allowed if all tests had to pass :(
<jbjnr>
use ctest -V to see verbose and then you might see the reason
<jbjnr>
do a "make help" and you can see all the targets. there are pseudo targets to help you build test.unit.parallel for example, then ctest -R tests.unit.parallel
<jbjnr>
to ust build/run subsets of the tests
<taeguk>
jbjnr: Good. Thank you to your advice.
Matombo has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<heller_>
jbjnr: blame hartmut, he always comits broken tests :P
<jbjnr>
but the executor only hold a pointer to the executor_base, so is it actually bad?
<hkaiser>
how can it slice if both types just hold a pointer to the implementation?
<hkaiser>
you shouldn't add members to your customized_pool_executor, though
<jbjnr>
well, I'm assigning a derived class to the scheduled_executor, so I am doing a 'bad thing' but in this case it ought to be safe. I just wanted to have a second opinion
<jbjnr>
I wanted to avoidn executors by pointer
<hkaiser>
no bad thing, perfectly valid operation
<jbjnr>
ok, great
<jbjnr>
aah. meeting. gtg
<hkaiser>
I'm assuming the custom_pool_executor is derived from scheduled_executor
<heller_>
jbjnr: did my access to tave got removed?
<heller_>
jbjnr: I should read the MOTD...
<jbjnr>
heller_: system wide maintenance today
<jbjnr>
all machines down
<jbjnr>
hkaiser: yes, the custom pool executor is derived from scheduled_executor.
denis_blank has joined #ste||ar
bikineev has joined #ste||ar
hkaiser has quit [Quit: bye]
akheir has joined #ste||ar
aserio has joined #ste||ar
<wash[m]>
aserio: I am planning to be on the call
<aserio>
wash[m]: thanks
hkaiser has joined #ste||ar
<github>
[hpx] hkaiser opened pull request #2664: Adding uninitialized_move and uninitialized_move_n (master...uninitialized_move) https://git.io/vHBqZ
<wash[m]>
aserio: on skype
<aserio>
wash[m]: the meetings now take place at 10:30am
<aserio>
(8:30atPT)
<wash[m]>
Oh
<wash[m]>
I am in eastern time
<wash[m]>
So it's 11:30, haha
<github>
[hpx] Naios opened pull request #2665: Hide the `detail` namespace in doxygen per default (master...hide_detail) https://git.io/vHBY0
<pree_>
while Invoking copy-constructor for components ( on gid of the component) Are we making 2 copies on same component instance ? because hpx::components::copy function already creates a copy and gives it's gid.
<zao>
My interpretation of a 'gid' is that it's the distributed analogue of a shared_ptr.
<zao>
Copying a gid itself should just make another ref to the same component, while explicitly copying a component clones the component itself, however you do that.
<zao>
(note, I have no idea how HPX actually is designed)
<pree_>
Thanks @ zao
Matombo has joined #ste||ar
bikineev has joined #ste||ar
<aserio>
wash[m]: Are you on?
<wash[m]>
Yes
<wash[m]>
At least it shows me as on on my end, bryce.lelbach
<aserio>
Calling
hkaiser has quit [Quit: bye]
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
justwagle has joined #ste||ar
hkaiser has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
justwagle has quit [Quit: Leaving]
david_pfander has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
denis_blank has quit [Quit: denis_blank]
denis_blank has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
Matombo has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<denis_blank>
Is there any difference between `dataflow(<callable>, <futures>...)` and `when_all(<futures>...).then(<callable>)` - also regarding its cababilities (launch policies...)? Because when crawling the codebase, I perceive the opinion that we theoretically could deprecate `dataflow`, because it basically duplicates `when_all(...).then(...)`.
<denis_blank>
hkaiser: ^
<K-ballo>
one shared state vs two
<K-ballo>
does that mean `when_all` lets non-futures pass thru now?
<hkaiser>
denis_blank: dataflow is the same (conceptually) as when_all().then()
<pree_>
Can anyone please tell me what are the differences bwt hpx::managed::component and hpx::fixed::component ? I didn't find in docs
<pree_>
thanks
<hkaiser>
but it's implementation is more efficient
<hkaiser>
pree_: fixed_components have a predefine global id
<hkaiser>
managed_components get one assigned
<denis_blank>
K-ballo: No, it's not possible yet (but lets assume it would, for the comparison).
<K-ballo>
fair, but I don't think when_all should accept non-future inputs
<pree_>
Okay. I will look at it's use cases. Thank you @hkaiser
<hkaiser>
: I agree
<hkaiser>
pree_: I think you can ignore fixed_components
<hkaiser>
they are used internally only
<pree_>
oh okay !
<denis_blank>
K-ballo, hkaiser: Theoretically it's possible to return an intermediate future class from when_all which delays the creation of its state so we would just create one shared state when using `when_all(...).then(...)`. Assuming that would it be theoretically possible then, to deprecate dataflow?
<K-ballo>
yes, if you assume all the things that can't be done or aren't a good idea, then it would be possible :)
<K-ballo>
someone once's suggested an expression template kinda return for when_all, I think it was chandler
<hkaiser>
denis_blank: I don't think you should try to 'optimize' when_all() for the case that it has a then()
<K-ballo>
we don't want to go there, those are different separate things
<hkaiser>
right
<K-ballo>
but yes, it is technically possible, for some definition of possible
aserio has quit [Ping timeout: 246 seconds]
<denis_blank>
Alright, thank you for your answers
<hkaiser>
K-ballo: the difference between value-construct and default-construct is significant for build-in data types, yes?
Matombo has joined #ste||ar
<hkaiser>
i.e. new (p) T; and new (p) T();
<K-ballo>
yep
<hkaiser>
ok
<K-ballo>
and for all trivially-constructible-types
<hkaiser>
sure
Matombo has quit [Remote host closed the connection]
<heller_>
denis_blank: also consider the signature of callable. Two very different things there
pree_ has quit [Ping timeout: 260 seconds]
<diehlpk_work>
heller_, hkaiser When do we have our meeting today?
<denis_blank>
heller_: In which way are the signatures different?
aserio has joined #ste||ar
eschnett has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
akheir has quit [Remote host closed the connection]
aserio has joined #ste||ar
bikineev has quit [Remote host closed the connection]
<hkaiser>
K-ballo: how can I verify whether a value-constructor was actually called for a variable
<hkaiser>
sorry, 'whether a variable was vaue-constructed
<hkaiser>
value*
<hkaiser>
(for testing purposes)
<K-ballo>
you can't, really, not 100% guaranteed
<hkaiser>
nod
<hkaiser>
thought so
<K-ballo>
if you have a union, it tends to show...
<hkaiser>
ok, how so?
<K-ballo>
value-constructed union value-initializes the first alternative and zero-fills the rest
<K-ballo>
default-constructed union doesn't touch any bytes
<hkaiser>
I would like to be able to test uninitialized_value_construct
<hkaiser>
how could I do that?
<K-ballo>
union { int first; char canary[256]; } u{}; u.canary[255] == 0;
<K-ballo>
but there's always a chance the garbage on the stack was already 0
<hkaiser>
I could malloc th ememory and prefill with 0xcd
<K-ballo>
sounds good
<hkaiser>
k
<K-ballo>
hkaiser: btw I was lazy above and accessed an inactive union member, don't do that, just memcmp against 0
<K-ballo>
or walk the bytes or whatever
<K-ballo>
actually you don't even need the union
<hkaiser>
K-ballo: what do you mean
<K-ballo>
if you can prefill the memory with 0xcd, then for a trivially-constructible-type value-init will fill with 0s whereas default-init won't touch it
<hkaiser>
default-init can be tested with a simple type which has an explicit default constructor
<K-ballo>
sure, any type that is trivially constructible
<K-ballo>
say, int
<K-ballo>
if you are in control of the memory then it's easy