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 quit [Quit: eschnett]
bikineev_ has quit [Remote host closed the connection]
bikineev has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
vamatya has quit [Ping timeout: 255 seconds]
K-ballo has quit [Quit: K-ballo]
eschnett has joined #ste||ar
hkaiser has quit [Quit: bye]
eschnett has quit [Quit: eschnett]
eschnett has joined #ste||ar
vamatya has joined #ste||ar
vamatya has quit [Ping timeout: 240 seconds]
bikineev has quit [Read error: No route to host]
bikineev has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
bikineev_ has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
pree has quit [Remote host closed the connection]
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
bikineev_ has quit [Remote host closed the connection]
pree has quit [Remote host closed the connection]
vamatya has joined #ste||ar
quaz0r has quit [Ping timeout: 260 seconds]
quaz0r has joined #ste||ar
bikineev has joined #ste||ar
vamatya has quit [Ping timeout: 248 seconds]
hkaiser has joined #ste||ar
bikineev has quit [Ping timeout: 248 seconds]
taeguk has joined #ste||ar
<taeguk> Excuse me, Does dataflow with hpx::launch::sync just invoke an function?
<taeguk> I thought yes in the past... But in my experiment, it seems not.
<hkaiser> taeguk: it waits for all futures to become ready before invoking that function
<jbjnr> taeguk should do something like that - when the last future in the dataflow becomes ready, the task will be executed - what is not behaving as expected?
<jbjnr> hkaiser: you're up early. good day
<hkaiser> jbjnr: hey - can't sleep - as usual
bikineev has joined #ste||ar
<taeguk> And Does main thread calling dataflow wait until dataflow will finish to invoke the function?
<hkaiser> no
<hkaiser> the thread which invokes dataflow will return a future which will become ready after the function was invoked
bikineev has quit [Remote host closed the connection]
<jbjnr> and using the sync policy will cause the last task (future) that becomes ready to run the dataflow task
<taeguk> oh... and then what does the sync policy mean exactly?
<jbjnr> the sync policy says, "don't put this new task in the queue and run it on 'any' thread, instead, run it now on the thread of the task that jas just become ready"
<jbjnr> ^has just
<hkaiser> taeguk: it means that no new thread is created to run the function, the thread which makes the last future ready runs the funtion direcly (synchronously)
<taeguk> doesn't the sync policy ensure that there is only one running thread?
<hkaiser> no
<taeguk> oh... my terrible misunderstanding........
<taeguk> For example,
<taeguk> auto task1 = dataflow(hpx::launch::sync, ....);
<taeguk> auto task2 = dataflow(hpx::launch::sync, ....);
<taeguk> auto task3 = dataflow(hpx::launch::sync, ....);
<taeguk> task1 and task2 and task3 can be running concurrently??
<jbjnr> yes
<taeguk> oh my god..
<jbjnr> :(
<hkaiser> well, that depends on the arguments to those dataflow calls, but in general yes
bikineev has joined #ste||ar
<taeguk> okay i got it. I had to think why the naming is 'sync' instead of 'seq'.
<taeguk> Thank you for answer! :)
<hkaiser> taeguk: because of the c++11 standard: http://eel.is/c++draft/futures#future.syn-1 - we just have added launch::sync
bikineev has quit [Ping timeout: 248 seconds]
<jbjnr> hkaiser: general question for you : you make changes to code on many different branches of hpx - how many copies of hpx do you have checked out - do you have loads of them, or do you just switch between branches frequently in the same tree? (I'm curios, because I keep 3 copies of hpx around for 2 main projects, plus other stuff and I wonder how you manage yours)
<hkaiser> jbjnr: mostly one copy, switching branches
<jbjnr> crumbs
<taeguk> hkaiser: I have one more question..
<taeguk> There are 'finalitems' for waiting 'f3's.
<hkaiser> yes
<taeguk> But, in my new version for sequential executed f3, 'finalitems' doesn't necessary.
<hkaiser> k
<taeguk> Removing 'finalitems' in my new version is okay? I'm worried about inconsistency.
<taeguk> My new version is just selected by 'tag'
<hkaiser> hmmm
<taeguk> scan_partitioner____.cpp
<taeguk> This is my new version of scan_partitioner.
<taeguk> There are two worries.
<taeguk> 1. Removing 'finalitems' in my new version causes inconsistency of interface of scan_partitioner. f3 don't require fitems when using the new version.
<taeguk> 2. And the new version of scan_partitioner don't use template parameter 'Result2', but 'Result2' is still passed...
<taeguk> Above code is the new version of scan_partitioner with removing finalitems.
<hkaiser> taeguk: using wait/wait_all is not a good idea
<hkaiser> why not use dataflow instead?
<hkaiser> wait will suspend the current thread while dataflow will not
<hkaiser> you want to avoid suspending threads as much as possible
<taeguk> But, I use wait_all for sequntially executed f3.
<taeguk> suspending is intended for sequentially execution of f3.
<hkaiser> why not use dataflow and enforce the needed sequentiality by introducing data dependencies?
<taeguk> hmm because the interface of f3 needs curr and next.
<hkaiser> you can always pass more arguments to dataflow for more data dependencies and unwrap those using a lambda or so
<hkaiser> dataflow([&f](F1 && f1, F2 && f2, F3 && f3) { return f(move(f1), move(f2)); }, f1, f2, f3);
<taeguk> Okay, good idea. I'll do that.
<hkaiser> here f3 is used to enforce a dependency only
<taeguk> Above maybe f must be passed by value for avoiding dangling reference.
<hkaiser> whatever
<taeguk> hmmm thanks for your suggestion.. And back to my original question,
<taeguk> How do you think about removing finalitems?
<hkaiser> I think those are still needed by f4, no?
<taeguk> in scan_partiitioner with the tag which means sequentially excuted f3.
<taeguk> f4 requires finalitems still.
<hkaiser> yes
<hkaiser> so why remove them?
<taeguk> But, what I do is removing finalitems from f4 in my new version.
<hkaiser> but if you remove them - I would suggest to create a new partitioner, not just a tag dispatched variation of the existin gone
<taeguk> yes that's what I'm worried.
<taeguk> hmm
bikineev has joined #ste||ar
<taeguk> If leaving finalitems doesn't have a significant effect to performance, I want to leave them.
<hkaiser> k
<hkaiser> sounds good to me
<taeguk> Do you think that finalitems doesn't have a significant effect to performance ?
<hkaiser> I don't know
<taeguk> hmm okay..
<taeguk> Do you think it is not good to have different interfaces for each tag?
<hkaiser> I don't think having different interfaces for different tags is a good idea
<taeguk> But, having individual scan_paritioner causes code duplications.
<hkaiser> taeguk: let's worry about that if your new partitioner turns out to be the answer we're looking for
<taeguk> okay.
<taeguk> But I have one more question. having different interfaces for each tag doesn't mean having different parameters. It means having same parameter but the interface of f4 is different.
<hkaiser> taeguk: sure
<taeguk> Is still not good to you?
<hkaiser> I tink haveing different interfaces for tag dispatched functions is not good - might cause problems which are difficult to spot
<taeguk> Hmm,, okay. As I think, your saying is correct, too.
<taeguk> I'll have different scan_partitioner.
<taeguk> But I don't know what name is good to new scan_partitioner for sequentially executed f3.
<taeguk> new scan_partitioner is still partitioner, too..
<taeguk> And my new suspicion: Is there a need to pass vector of finalitem to f4?
<taeguk> passing the last element of vector of finalitem to f4 is insufficient?
<taeguk> Currently, all things using scan_partitioner just utilize the last element of finalitems.
<taeguk> If we modify the interface of f4 for passing just the last element of finalitems, all issues that we discussed above are solved.
bikineev has quit [Remote host closed the connection]
heller has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
heller has joined #ste||ar
<github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/v7hAx
<github> hpx/gh-pages 0c933dd StellarBot: Updating docs
bikineev has joined #ste||ar
bikineev has quit [Ping timeout: 248 seconds]
Matombo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
denis_blank has joined #ste||ar
K-ballo has joined #ste||ar
eschnett has quit [Quit: eschnett]
<K-ballo> 1> main.cpp(36): error C2491: 'hpx::traits::component_type_database<test_server,void>::get': definition of dllimport function not allowed
<K-ballo> 1> main.cpp(36): error C2491: 'hpx::traits::component_type_database<test_server,void>::set': definition of dllimport function not allowed
<K-ballo> what may I be doing wrong?
<jbjnr> a function declared as export is being read as inport, usually a missing project_EXPORTS definition from cmake or elsewhere that means the #define isn't setup
parsa has quit [Quit: Zzzzzzzzzzzz]
<K-ballo> I may be missing some export macro, yeah
<hkaiser> HPX_COMPONENT_EXPORTS?
<K-ballo> HPX_APPLICATION_EXPORTS;
<hkaiser> nod
aserio has joined #ste||ar
denis_blank has quit [Quit: denis_blank]
<github> [hpx] Naios opened pull request #2845: Add Visual Studio 2015 to the tested toolchains in Appveyor (master...msvc14_appveyor) https://git.io/v7jRx
denis_blank has joined #ste||ar
<aserio> jbjnr: hey, I was checking in on the resource_manager branch. Are there still some features missing?
mcopik has quit [Ping timeout: 240 seconds]
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
denis_blank2 has joined #ste||ar
denis_blank has quit [Ping timeout: 240 seconds]
eschnett has joined #ste||ar
EverYoung has joined #ste||ar
patg has joined #ste||ar
vamatya has joined #ste||ar
denis_blank2 has quit [Quit: denis_blank2]
taeguk has quit [Quit: Page closed]
pree has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
pree has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
pree has joined #ste||ar
aserio has quit [Ping timeout: 246 seconds]
<github> [hpx] hkaiser created fixing_2846 (+1 new commit): https://git.io/v7jH3
<github> hpx/fixing_2846 670d01f Hartmut Kaiser: Unify serialization of non-default-constructable types...
<pree> Is registering components and actions using HPX_REGISTER_COMPONENT(), HPX_REGISTER_ACTION() makes an entry in AGAS table irrespective of localities ? Or it makes the address space in which that allocated as the region of AGAS ?
<pree> *in which that component
<pree> what are the supported parcel ports in hpx ? I know MPI is supported. But I don't know how using MPI as the backend parcel port hpx is gaining greater performance than MPI.
<pree> Please note I don't know MPI.
<pree> HPX is my first parallel && distributive computing tool.
<pree> thanks
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
aserio has joined #ste||ar
<aserio> hkaiser: will you be joining us today?
<hkaiser> aserio: sorry, missed the time...
mcopik has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<github> [hpx] hkaiser created fixing_2847 (+1 new commit): https://git.io/v5eJZ
<github> hpx/fixing_2847 92a8ac7 Hartmut Kaiser: Enable returning future<R> from actions where R is not default-constructible...
pree has quit [Ping timeout: 240 seconds]
parsa has joined #ste||ar
<heller> Last day of vacation
<K-ballo> uh oh...
* K-ballo better gets on with the reading
<jbjnr> aserio: I'm not sure. I have not looked at some of hkaiser 's latest additions. The features I want to add but have not done so yet are : "give me the cpu's nearest the network, gpu etc". better control of threads when you use a random access strategy when assigning to pools (like n cores per nthose cases.uma domain instead of sequential assignment) - or odd cores on one pool, even an...
<jbjnr> ...another - some thread numbering might be flakety in
<jbjnr> several other tweaks I can't remember now, but them main stuff is working and ready for use
<aserio> jbjnr: so the plan is still to push this now and add those features as we go?
<jbjnr> aserio: I would say so. no need to hold back the current work as the new features won't change existing stuff appreciably
<aserio> So all it is waiting for is your review?
<jbjnr> yes. I've been a bit preoccupied this last week and not been hpx'ing
<jbjnr> sorry
<jbjnr> (next week I'm having a few day off btw)
<jbjnr> sorry again :(
<aserio> Its ok
<jbjnr> ^ somehow the text above got munged. bloody trackpad on linux again, always moving my cursor around randomly as I type - it doesn't make sense at all does it ^
<aserio> jbjnr: I am excited that it is nearly done!
<jbjnr> don't be
<aserio> There are some really cool stuff that can be implemented on it
<jbjnr> indeed
<aserio> also, I need to get back to Shoshana
<aserio> I was planning to wait until the branch was merged....
<aserio> but I might go ahead and get her info now
<jbjnr> I'll try to review it this weekend
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
akheir has quit [Remote host closed the connection]
<K-ballo> "mutecis"? no way!
bikineev has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
eschnett has quit [Quit: eschnett]
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
aserio has quit [Quit: aserio]
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
EverYoun_ has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
EverYoun_ has quit [Ping timeout: 246 seconds]
bikineev has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar