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: 240 seconds]
bikineev has quit [Remote host closed the connection]
<denis_blank>
Is there an existing util function in the codebase like make_range(begin_iter, end_iter) which returns a container like object that returns the given begin and end iter?
<github>
hpx/fixing_2699 7df83a4 Hartmut Kaiser: Fix option description in cmake
bikineev has quit [Ping timeout: 240 seconds]
aserio has joined #ste||ar
vamatya has joined #ste||ar
Matombo has quit [Remote host closed the connection]
jbjnr_ has joined #ste||ar
<jbjnr_>
hkaiser: yt? quick question?
<jbjnr_>
(bad train internet)
<hkaiser>
jbjnr_: sure
<jbjnr_>
when a future becomes ready and a task that depends on it is waiting - does the task get changed to pending/or ready or whaever immediatly - or are they done in batches of N at a time. We are seeing a delay between when a task is theoretically ready and when it actually runs, that could be explained by this
bibek_desktop has quit [Ping timeout: 255 seconds]
<jbjnr_>
(lag between when it is ready, and when it goes into a queue and is then run)
<pree>
jbjnr_ : may I add my suggestion
<jbjnr_>
please do
<pree>
I think "the task does not changed to pending/ready". When the task again get's scheduled by the scheduler it executes without blocking for the future (.get())
<pree>
I think hpx::dataflow can do what you want exactly ,
<jbjnr_>
pree: I'm debugging scheduler code, it is low level and dataflow is not quite applicable to this scenario
<jbjnr_>
(dataflow sits on top of the schedulers)
<jbjnr_>
(indirectly)
<pree>
I don't know exactly , Please wait until expert "HPXers" reply : )
<jbjnr_>
hkaiser: ran away :(
<pree>
jbjnr_ : Okay .
<pree>
jbjnr_ :thanks for making dataflow more clear : )
bibek_desktop has joined #ste||ar
<K-ballo>
suddenly the github review UI feels clumsy
<K-ballo>
there's not enough context to know what comments are about, and somehow there's no way to see the question in full context?
<K-ballo>
(other than just scanning the entire diff, that is, something like a link to comment in place, or ability to load more context before/after)
<K-ballo>
I think it used to show about 10 lines of context, instead of just 2, didn't it?
<K-ballo>
heller: I'll get to answer your range comments eventually, may take me some time, I don't remember the details anymore so I'll have to refresh them when I have the time
thundergroudon[m has quit [Read error: Connection reset by peer]
taeguk[m] has quit [Read error: Connection reset by peer]
thundergroudon[m has joined #ste||ar
zbyerly_ has quit [Ping timeout: 240 seconds]
jbjnr_ has quit [Ping timeout: 248 seconds]
<hkaiser>
K-ballo: does the standard say anything about the memory layout of initializer lists?
taeguk[m] has joined #ste||ar
<K-ballo>
maybe, depending which one you mean
<hkaiser>
{0, 42, 43]/
<hkaiser>
?
<K-ballo>
that could be one of many "initializer lists" still
<K-ballo>
std::initializer_list<T> will point to an underlying array of T
<K-ballo>
does that answer the question?
<hkaiser>
C-array?
<K-ballo>
the layout itself of `std::initializer_list` is unspecified, but the underlying array is a plain C array, yes
<hkaiser>
ok
<hkaiser>
that answers the question, thanks
<K-ballo>
as for std::initializer_list, msvc and gcc/clang are not compatible
<K-ballo>
one does pair of pointers, the other does pointer+size
<K-ballo>
although I believe STL wanted to change the msvc one eventually to match gcc/clang
<hkaiser>
K-ballo: I was more interested in the underlying data representation
bikineev has joined #ste||ar
jbjnr_ has joined #ste||ar
ajaivgeorge has quit [Quit: ajaivgeorge]
jbjnr_ has quit [Ping timeout: 258 seconds]
bikineev has quit [Ping timeout: 246 seconds]
bikineev has joined #ste||ar
zbyerly_ has joined #ste||ar
aserio has quit [Ping timeout: 246 seconds]
david_pfander has quit [Ping timeout: 246 seconds]
zbyerly_ has quit [Quit: Leaving]
zbyerly_ has joined #ste||ar
zbyerly_ has left #ste||ar [#ste||ar]
<K-ballo>
I just rememberd!
zbyerly_ has joined #ste||ar
mcopik has quit [Remote host closed the connection]
aserio has joined #ste||ar
mcopik has joined #ste||ar
ajaivgeorge has joined #ste||ar
mcopik has quit [Remote host closed the connection]
<github>
hpx/appveyor abb18fe Hartmut Kaiser: Adding support for AppVeyor CI...
akheir has quit [Remote host closed the connection]
<github>
[hpx] hkaiser force-pushed appveyor from abb18fe to efd6a0a: https://git.io/vQzUf
<github>
hpx/appveyor efd6a0a Hartmut Kaiser: Adding support for AppVeyor CI...
aserio has quit [Quit: aserio]
<mbremer>
I'm still having some trouble getting hpx to run on the KNL nodes. Is there anything specific I need to be doing? I've attached the error. It's a little strange, because the error is for the 1d_stencil_1 example, which doesn't even seem to be using hpx really.
<mbremer>
Also for the libfabric it seems that HPX can't find PMI. I think the network is Intel Omni-Path (OPH) network, so it's probably just a matter of setting the configuration up right. Not sure if there's a point atm
<github>
[hpx] hkaiser force-pushed appveyor from e56431e to eb11282: https://git.io/vQzUf
<github>
hpx/appveyor eb11282 Hartmut Kaiser: Adding support for AppVeyor CI...