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/
zbyerly_ has joined #ste||ar
zbyerly_ has quit [Read error: Connection reset by peer]
zbyerly_ has joined #ste||ar
zbyerly_ has quit [Ping timeout: 240 seconds]
eschnett has quit [Quit: eschnett]
<K-ballo>
hkaiser: the logic in acquire_future that operates on "ranges", it only works for containers AFAICT
<hkaiser>
K-ballo: could be, it might even work for vector only
<K-ballo>
nod, that seems to be the case here and there
<K-ballo>
seems the is_range trait was extended to take just vector to containers and accidentally ranges, but code never adjusted to take it into account
<hkaiser>
right
<hkaiser>
K-ballo: btw, Antoine did some compile time comparisons for the unrolled pack stuff
<K-ballo>
alright, as long as that's status quo I don't have to worry
<hkaiser>
surprising results
<hkaiser>
K-ballo: would be nice to fix this 'status quo' but that's not really urgent, atm
<K-ballo>
yeah, I mean it's not something my ranges branches would introduce
<hkaiser>
nod
<K-ballo>
a "proper" solution might be just having acquire_future<Range> always return a vector
<github>
hpx/master fd66af3 atrantan: Take stride into account whensolving view end iterator
<github>
hpx/master 32eafa0 atrantan: Initializer_list dors not have subscript operator
<github>
hpx/master f77a8c2 atrantan: Use padding in partitioned_vector subview test
bikineev has quit [Remote host closed the connection]
<zao>
Spurious failure, didn't appear on next run.
<zao>
Which I'd expect from a threaded deadlock :)
<heller>
yup
<heller>
this particular test fails every now and then on buildbot as well
<jbjnr>
hkaiser: yt?
<hkaiser>
jbjnr: here
<jbjnr>
follow up to yesterday's question ....
denis_blank has joined #ste||ar
<hkaiser>
sure
<jbjnr>
if a task is created - but it is not yet ready to run. when the future that becomes ready that makes it in turn ready to go. In the scheduler - is there any possibility that when it transitions from Staged to pending - that it can be made to waint untail (say) N threads are ready and they are then done in a batch (like cleanup etc etc)
<hkaiser>
jbjnr: everything is possible, but not with the current schedulers
<hkaiser>
jbjnr: what do you have in mind?
<jbjnr>
sorry. what I meant was - does this happen with the current schedulers
<hkaiser>
no this does not happen
<hkaiser>
threads are added to a queue as soon as they are set to 'pending'
<jbjnr>
we create high priority tasks, but they do not run immediately. Even using my modified scheduler that maintains a sdingle HP queue
<jbjnr>
so all worker threads take from that first
<jbjnr>
I am looking for some place where in thread_queue for example the tasks that transition to pending, don't immediately go into the queue to be stolen...
<hkaiser>
jbjnr: your modified scheduler has only one high priority queue
<jbjnr>
yes
<hkaiser>
are you sure that there is a core available to steal the task if it sits in that queue?
<jbjnr>
and it is always checked before any other taks are run
<jbjnr>
"are you sure that there is a core available to steal the task if it sits in that queue?" well what we see is cores running other tasks that are not high priority before the HP ones - even though that is not possible if the HP queue is not empty - so my guess is that the HP queue is not being filled when I exepct it to be
<jbjnr>
I was hoping to find some place where an HP task becomes ready, but instead of immediately going onto the HP queue, it instead sits in another queue until N are ready and are then put in the queue (like cleanup etc). This would explain the behaviour ...
<jbjnr>
ok, I will be able to confirm that in a mo. Just got back from lunch and have added a bunch of logging code to the scheduler to dump out the pool and the queue that tasks are going to
<hkaiser>
I think it does
<hkaiser>
nvm, it should obey to that
bikineev has quit [Remote host closed the connection]
thundergroudon[m has quit [Ping timeout: 240 seconds]
taeguk[m] has quit [Ping timeout: 255 seconds]
<ajaivgeorge_>
mcopik: Only the changing the method of finding last iterator from advance to distance and the segmented_transform return type is left now. I think I can fix that myself. Do let me of any further issues. Wrt to segmented_find_end, I am kinda stuck with figuring out how to handle subsequences which are partitioned across segments. Let's have a meeting tomorrow since I cant talk much now. (throat infection)
mcopik has joined #ste||ar
thundergroudon[m has joined #ste||ar
hkaiser has quit [Ping timeout: 268 seconds]
taeguk[m] has joined #ste||ar
thundergroudon[m has quit [Remote host closed the connection]
taeguk[m] has quit [Remote host closed the connection]
hkaiser has joined #ste||ar
thundergroudon[m has joined #ste||ar
taeguk[m] has joined #ste||ar
<hkaiser>
ajaivgeorge_: yah, that's tricky - probably involves direct communication between neighboring partitions
<hkaiser>
ajaivgeorge_: which in turn might require additional functionalities exposed by the underlying container
Matombo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
<mcopik>
hkaiser: ajaivgeorge_: since you're looking for a sequence anyway, the function dispatched on segments could return a more complex object indicating the last sequence found (position), an incomplete sequence at the end (to which position it has been found) or an incomplete sequence at the beginning. first case is rather simple and requires only returning additional information at looking at last future result
<mcopik>
second may be solved by an initial processing of the segment
<mcopik>
later you have to combine results from segments until a match is found and if there's no subsequence present on a segment, you look at the flag for a begin subsequence and compare it with the preceding segment
<mcopik>
ajaivgeorge_: I'd suggest to start with writing tests by implementing a set of input data for test, with all possible cases of a subsequence spread between segments
<mcopik>
no subsequence spread, full split between two segments, all corner cases such as one element on segment I, N - 1 elements on segment I+1
<mcopik>
multiple instances of the sequence (both cases: fitting inside a segment)
<mcopik>
and of course, a sequence spread over multiple segments
<mcopik>
e.g. a sequence of length 10 located in the following pattern: 2 elements on I - 1, 5 elements on I (a part of subsequence occupying the whole segment), 3 elements on I + 1
<mcopik>
I think it'd be easier to talk about it if all cases are considered and written down
<mcopik>
I might have missed something here
ajaivgeorge_ has quit [Quit: ajaivgeorge_]
<pree>
Hi Is there any ways to register all functions of a component easily ? without specifying HPX_REGISTER_ACTION() for all functions ?
<pree>
Thank you
<hkaiser>
pree: no
<hkaiser>
you have to list them separately
<pree>
oh !
<pree>
It's ok
<pree>
thank you
<hkaiser>
I'd love to have a way, but there is none (currently)
<pree>
I also like to have something like that , because if component has many functions