K-ballo 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/
<tarzeau>
the only last thing i must fix is get the automatic dependcy for python2 gone, and it can go into debian (and hopefully also bullseye debian/11) and future raspberrypi/ubuntu releases
<hkaiser>
that's not good, I was not aaware of that
<tarzeau>
you're welcome ;)
<hkaiser>
we will have to remove those files
<tarzeau>
looking forward to 1.5.2 :)
<hkaiser>
especially the GPL one
<tarzeau>
where's the gpl one?
<hkaiser>
the file you linked mentions GPL :/
<tarzeau>
yeah that's for what i wrote the makefile recipe for debian packaging debian/* ? i can make it anything, i wrote it after all
<tarzeau>
wtfpl, bsd, mit, you name it
<hkaiser>
ahh
<hkaiser>
will it be part of the repo?
<tarzeau>
it'll be part of the debian source package yes
<hkaiser>
but not in the HPX repository, I hope
<hkaiser>
if it has to go into the repository, please make it it bsl
<tarzeau>
i don't have access to the hpx repository
<hkaiser>
create a PR and it will go in ;-)
<tarzeau>
no it does not need be in source distributions of you, it'll only be part of debian
<hkaiser>
understood
<tarzeau>
debian preferes to not have the packaging part of the source tarball release, and that's good
<hkaiser>
ok
<tarzeau>
because a source debian package is made up of a diff.tar.xz with debian/ changes + original upstream tar.gz source
<zao>
When building a Debian/Ubuntu package you point the build scaffolding at a debian/ control tree which prepares a fresh build root somewhere, builds according to the rules and patches in the control tree, and lets you keep all the pieces when it inevitably fails miserably ;)
hkaiser has quit [Quit: bye]
surbhi has joined #ste||ar
henrietaMag has joined #ste||ar
surbhi has quit [Ping timeout: 272 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 272 seconds]
henrietaMag has quit [K-Lined]
hkaiser has joined #ste||ar
<jaafar>
Hello friends. I've been diving into the scheduler code - specifically local_priority_queue_scheduler.hpp, which seems to be active by default for my build
<jaafar>
How might I go about doing a quick hack where I force the scheduler to start assigning new threads to the queue *after* the currently active thread (i.e., the one creating work)?
<hkaiser>
jaafar: that's what the hints are for
<jaafar>
This would allow work to make progress on N-1 threads while the thread creation finished
<jaafar>
hkaiser: do the hints reset the queue index?
<jaafar>
or do they just say "please put all tasks here"
<hkaiser>
yes, they say put this thread 'here'
<jaafar>
So if I wanted to do as described, I'd have to explicitly specify the queue for each thread?
<hkaiser>
yes
<hkaiser>
you ask for the current core and use it as a hint for the new task
<jaafar>
Would I have to create a new "executor" each time I changed the hint?
<hkaiser>
yes
<jaafar>
Is that very expensive :)
<hkaiser>
no, executors are cheap to create
<jaafar>
OK cool. So I would be using the "on" method, right?
<jaafar>
i.e. I make my executor with the hint "on" the original executor?
<jaafar>
If I'm understanding this correctly
<hkaiser>
I think for the hint you'd use the prefer() syntax from the PR and then use the returned executor directly for scheduling the next task - .on() is only for execution policies
<jaafar>
OK! Thank you. I will explore.
<hkaiser>
note that I have no experience with this myself - let's see how it actually works