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: 245 seconds]
EverYoun_ has joined #ste||ar
EverYou__ has joined #ste||ar
EverYou__ has quit [Remote host closed the connection]
EverYou__ has joined #ste||ar
EverYou__ has quit [Remote host closed the connection]
EverYoun_ has quit [Ping timeout: 248 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<github>
[hpx] hkaiser created fixing_config_entry (+1 new commit): https://git.io/vA6fR
<github>
hpx/fixing_config_entry 549be5a Hartmut Kaiser: Making sure resource partitioner is not accessed if its not valid
parsa has joined #ste||ar
<github>
[hpx] hkaiser opened pull request #3202: Making sure resource partitioner is not accessed if its not valid (master...fixing_config_entry) https://git.io/vA6f0
parsa has quit [Client Quit]
EverYoung has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
hkaiser has quit [Quit: bye]
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser has joined #ste||ar
vamatya has quit [Ping timeout: 240 seconds]
Anushi1998 has joined #ste||ar
parsa has joined #ste||ar
<parsa>
hkaiser: ping
<hkaiser>
parsa: hey
<parsa>
hkaiser: is there a way to extract the underlying dynamicmatrix from the custommatrix?
<hkaiser>
parsa: what do you mean by 'extract'?
<parsa>
custommatrix does not seem to work with my iterators
<hkaiser>
create a copy?
<parsa>
the original
<hkaiser>
sure it does
<hkaiser>
why shouldn't it?
<parsa>
because this: "error C2938: 'ElementType_<blaze::CustomMatrix<T,true,true,false>&>' : Failed to specialize alias template"
<parsa>
hkaiser: just know that the last three commits are there for the sake testing… their changes are not suitable for production and i'll remove them
<hkaiser>
parsa: it just compiles if you remove that reference
<hkaiser>
not sure why you wanted to make it a reference in the first place
<parsa>
it was supposed to be a const&
<hkaiser>
even then
<parsa>
what do you mean?
<hkaiser>
if you write auto a = arg_a.matrix(); your code compiles
<hkaiser>
as it should
<parsa>
what do i have to do to make const auto a& compile?
<hkaiser>
why do you want to have a const&?
<parsa>
to make sure it does not create a copy
<hkaiser>
it will not, look at how .matrix() is implemented
<parsa>
why does that const mess things up?
<hkaiser>
it always returns a custommatrix, the th ewhole point of it
<hkaiser>
it's not the const& messing with things but the decltype(a) below that turns into a const& as well
<parsa>
oh
<parsa>
ugh
<hkaiser>
but there is no reason whatsoever to make 'a' a const&, really
<parsa>
makes sense… still, i'd have thought it would work
<parsa>
on to the next question
<parsa>
same file, line 89
<hkaiser>
well, it didn't - you created a row_iterator<customematrix<...>&>, which does not make sense
msca8h has joined #ste||ar
<hkaiser>
ok?
<parsa>
for some reason that can't be a const either
<parsa>
why
<parsa>
?
<hkaiser>
that can be a simple T as well, as along as you instantiate the iterator with a custommatrix, that is
<hkaiser>
but I don't see any reason for it not to be a const&, if that's what you prefer
<hkaiser>
but then you will not be able to actually modify the data through the iterator
<parsa>
thanks a lot… i've been stuck on this since 3
<parsa>
pm
<hkaiser>
get a break
msca8h has quit [Read error: Connection reset by peer]
nanashi55 has quit [Ping timeout: 256 seconds]
nanashi55 has joined #ste||ar
hkaiser has quit [Quit: bye]
sharonhsl has quit [Quit: sharonhsl]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
vamatya has joined #ste||ar
msca8h has joined #ste||ar
msca8h has quit [Read error: Connection reset by peer]
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
Nikunj has joined #ste||ar
sharonhsl has quit [Quit: sharonhsl]
sharonhsl has joined #ste||ar
jaafar has quit [Ping timeout: 248 seconds]
sharonhsl has quit [Ping timeout: 248 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Ping timeout: 252 seconds]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
sharonhsl has joined #ste||ar
david_pfander has joined #ste||ar
david_pfander has quit [Ping timeout: 252 seconds]
sharonhsl has quit [Quit: sharonhsl]
sharonhsl has joined #ste||ar
sharonhsl has quit [Client Quit]
vamatya has quit [Ping timeout: 245 seconds]
<Guest75560>
[hpx] msimberg closed pull request #3198: Set pre_main status before launching run_helper (master...msimberg-patch-1) https://git.io/vAoOe
<simbergm>
jbjnr: is pycicle github status maybe not being set again? :/
david_pfander has joined #ste||ar
david_pfander1 has joined #ste||ar
david_pfander has quit [Ping timeout: 265 seconds]
david_pfander1 is now known as david_pfander
sharonhsl has joined #ste||ar
<zao>
Did you notice the Appveyor over-time failure? "Build execution time has reached the maximum allowed time for your plan (60 minutes)."
<zao>
Do we need a faster build or an actual appveyor plan?
<simbergm>
zao: yeah, it's a bit worrying, I want to ask hkaiser if hello world still(/again) hangs for him
<simbergm>
hoping it's just a slow build
<zao>
I should re-test it on my box.
<zao>
simbergm: Can we instrument the build to print out the time it took to do the actual build, prior to running hello?
<simbergm>
zao: no idea, especially about windows
<simbergm>
maybe one can just print the current time between steps?
<zao>
That'd be the simple way :D
<simbergm>
or maybe cmake has some hooks that we can run before and after build steps? just guessing...
<zao>
Does this work locally for you on some system?
<Nikunj>
yes it does
<Nikunj>
zao: clang can't find libhpx.so and libhpx_init.a
<Nikunj>
zao: Although clang is pointing searching in the right directory, it won't find it
<zao>
nikunj: I would recommend that you gather information to diagnose the problem. Verify that $HPX_LOCATION is what you expect, print the output of pkg-config, see if you can tell $CXX to be more verbose.
<zao>
Maybe even dump the contents of the .pc file.
<zao>
(unless that is available as a downloadable artifact already)
<Nikunj>
zao: I don't have docker locally set up.
<zao>
nikunj: You're working in a PR, you could do those experiments there.
<zao>
I don't know if you have enough rights to attach with SSH to your build, but that could also be an option.
<Nikunj>
zao: I sadly do not have the rights :(
<Nikunj>
That's why I've been experimenting with stuff to make it working
<Nikunj>
zao: Could you tell the location of HPX_LOCATION in the circle build?
<zao>
No idea.
<Nikunj>
zao: I see. Thanks for the help :)
<zao>
nikunj: You could theoretically commit a hello.sh to your PR branch and see the output in the CI run.
<Nikunj>
zao: That's what I'm currently doing.
<zao>
(as in that you can add diagnostic spam to your hello.sh and see how it goes)
<Nikunj>
zao: Ok
<Nikunj>
zao: I guess I've found out the error in my code
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
marco has joined #ste||ar
marco is now known as Guest42771
MoFa_ has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
parsa has quit [Quit: Zzzzzzzzzzzz]
Nikunj has quit [Ping timeout: 260 seconds]
Nikunj has joined #ste||ar
david_pfander has quit [Ping timeout: 248 seconds]
parsa has joined #ste||ar
parsa has quit [Client Quit]
hkaiser has joined #ste||ar
<parsa[w]>
hkaiser: can i return a std::vector<double> in std::vector<primitive_argument_type>?
<hkaiser>
no
<hkaiser>
but you can return a vector<primitive_argument_type> in that primitive_argument_type
<parsa[w]>
i was using int until it failed on clang (explicit ctor error) which suggested using double
<parsa[w]>
i probably should change it to int64_t
<hkaiser>
nah, int should work, more precisely int64_t
<hkaiser>
nod
<hkaiser>
otherwise it looks ok
<parsa[w]>
well it crashes in the test with "primitive_argument_type does not hold a numeric value type (type held: 'std::vector<primitive_argument_type>'): HPX(bad_parameter)"
parsa has joined #ste||ar
<hkaiser>
parsa: well, if you ask it for a numeric value it will not be happy to find a vector of those, wouldn't it?
<parsa[w]>
hkaiser: that was indeed the problem. now how is the expected value in the tests is supposed to be constructed?
<hkaiser>
iterate over the vector you get back and compare against the expected indiecies?
<Nikunj>
@hkaiser: About the GSoc Project. I was trying my hand on designing custom hooks ( we decided upon custom hooks as best way to implement ) and I found that this way is unnecessarily big. This way relies heavily on the environment you use. With stark differences between windows, linux and mac I feel custom hooks is not a good method.
<Nikunj>
As for initialising environment functions relies on the choice of compiler as well as environment of use.
anushi has joined #ste||ar
<zao>
simbergm: RDP:d home, hello-world has stopped being stupid and interspersing output at least now, and doesn't seem to crash anything.
Anushi1998 has quit [Ping timeout: 252 seconds]
<hkaiser>
nikunj: that's what I expected, yes
hkaiser has quit [Quit: bye]
<Nikunj>
@hkaiser: As of now, I feel that global variable is the best method. My reasons are: 1) It is both environment and compiler independent as we are initialising using struct 2) It does a lot of work in a little code 3) Implementing it will be easier and more efficient
K-ballo has joined #ste||ar
<jbjnr>
diehlpk_work: thanks for comments on gsoc doc
<jbjnr>
simbergm: balls. looks like you're right and the status isn't being set. grrr.
<simbergm>
zao: how stupid was hello world for you before? it looks like hello world on appveyor only times out with VS 2015, you tried with 2017?
<simbergm>
heller_: I guess no update about allscale suspension problems? if it takes longer do you think that's something we could skip for the release, or at least just go with the changes I proposed for now and see later if you need something more?
<jbjnr>
wash: yt? what's your email address these days
<jbjnr>
or wash[m] ^^
<jbjnr>
depending on which you use at the moment
hkaiser has joined #ste||ar
<simbergm>
hkaiser: thanks for looking at 3182
<simbergm>
I tried your branch out, couldn't compile it as is but if I move that one include which is outside the include guards into its normal place it compiles
<simbergm>
and it either fixes or avoids whatever problems the thread_pool_executors test was having, no hangs anymore
<hkaiser>
simbergm: it compiles on circleci
<hkaiser>
(except for som eheader tests, which I will fix)
<simbergm>
hkaiser: okay, even better, maybe I checked out an older version
<hkaiser>
nod
<hkaiser>
would you mind trying again?
<simbergm>
no, can do that
<hkaiser>
tks
<parsa[w]>
hkaiser: can we make node_data expose its T as a type so we can replace doubles in our code with it?
<simbergm>
hkaiser: also, do you use VS 2017? those appveyor timeouts seem to happen only on VS 2015, but actually relatively frequently
<hkaiser>
simbergm: yah, noticed that
<hkaiser>
parsa[w]: feel free
<hkaiser>
parsa[w]: do you have code where this would be helpful?
<hkaiser>
I'm asking as I don't see this to be useful :/
<parsa[w]>
in argmax i hard coded double
<hkaiser>
why is writing node_data<double>::type better than writing just double?
<parsa[w]>
node_data<super_double> might exist at some point
<parsa[w]>
node_data<quadruple>
<hkaiser>
sure, but then your code would bet templatized in the first place and you would use node_data<T>, which brings me back to asking what is better in writing node_data<T>::type over just T?
<parsa[w]>
because with it we will have one hard-coded double in any of the primitive's code which is defined in arg_type
<hkaiser>
parsa[w]: as said, feel free to add - no harm, I don't see it to be useful, though
<parsa[w]>
fair enough
<simbergm>
zao, heller_: you concluded that the migrate_component test was still misbehaving?
<K-ballo>
using T = double;
<zao>
simbergm: I tested three commits, the ones before/after merging the branch in, and the then-current master head.
<zao>
They were equally broken.
<zao>
I have not tested anything more recent.
<simbergm>
zao: ok, thanks :/
<simbergm>
hkaiser: all good on fixing_3182, thanks!
<hkaiser>
simbergm: ok, thanks, I'll fix the remaining things, then it's good to go
<Nikunj>
@hkaiser: I feel that we should use global variable declaration method to work at runtime. My reasons for the same are: 1) It is both environment and compiler independent as we are initialising using struct 2) It does a lot of work in a little code 3) Implementing it will be easier and more efficient
<hkaiser>
nikunj: fine by me, but I anticipate initialization sequencing issues that will have to be fixed all over the place
<Nikunj>
@hkaiser: Here is what I've thought: 1) Create a hpx_initialise.hpp which contains all the initialising data (that includes setting up global variable as well creating the struct) 2) Including hpx_initialise.hpp in hpx system (i.e. adding the hpx_initialise to various files that'll need it) 3) Correcting initiliasing sequence
<hkaiser>
nanashi55: ok - pls look at the init_globally example, that gives you already at least half of what you're looking for
<hkaiser>
nikunj: ^^
aserio has joined #ste||ar
<Nikunj>
@hkaiser: Yes going through init_globaly gave me the idea for it's implementation. I'll start working on it locally and look for potential flaws in this method (if any).
<hkaiser>
k
<diehlpk_work>
hkaiser, heller_ What could be the topic for the article?
jakub_golinowski has joined #ste||ar
<hkaiser>
diehlpk_work: what do they want?
<diehlpk_work>
Realated to Open Source and GSoC
galabc has joined #ste||ar
<hkaiser>
hmmm
<hkaiser>
not sure
<zao>
I'll see if I can run the test on current master 8c0d1767f12, if I remember how :)
<zao>
Global init? After the misery I had with FreeBSD initialization, I wish you luck :D
<zao>
(of course, that was mostly due to ass-umptions about argc/argv)
<diehlpk_work>
hkaiser, I was thinking 10 gute Gruende fuer die Mitarbeit bei einem Open Source Projekt
victor_ludorum has joined #ste||ar
<hkaiser>
diehlpk_work: if you have a list of 10, sure ;)
jakub_golinowski has quit [Ping timeout: 252 seconds]
shahrzad has quit [Read error: Connection reset by peer]
<zao>
simbergm: Running a few tests on current master, tests.unit.components.distributed.tcp.migrate_component still occasionally times out.
<zao>
(8c0d1767f125a595b2b1dbdbbd077d14752ffb9b for reference)
jakub_golinowski has joined #ste||ar
<github>
[hpx] hkaiser force-pushed fixing_3182 from a03d43b to 99d21fe: https://git.io/vAaOj
<github>
hpx/fixing_3182 99d21fe Hartmut Kaiser: Fixing return type calculation for bulk_then_execute....
victor_ludorum has quit [Quit: Page closed]
<zao>
simbergm: Same kind of failures in logs, I think.
<Zwei_>
I understand what's going on, but I don't understand *why*. If, thread A write to x first, then y, how comes x can still be false in thread B if y is true?
<Zwei_>
is it something to do with hardware cache?
anushi has quit [Ping timeout: 240 seconds]
mcopik has joined #ste||ar
<Zwei_>
Hmm... this is probably the wrong place to ask about this. I'll try somewhere else :)
<K-ballo>
not necessarily, we could be expected to know that stuff... we try to stay away from it
<K-ballo>
Zwei_: you say thread A writes to x first then y, how do you reach that conclusion?
<Zwei_>
Well, this is for discussing your software. Not for people trying to learn concurrency. I don't want to spam this channel :)
<simbergm>
hkaiser: only thing with 3182 is that bulk_then_execute returns a future<void> instead of a vector<future<void>> like bulk_async_execute
<Zwei_>
K-ballo: shouldn't each thread run in a happens-before manner? That's what the book said.
<simbergm>
I don't care either way but I guess they should be the same
<Zwei_>
Maybe I got the wrong understanding...
<zao>
simbergm: I had hello_world.exe running in a loop on my Windows machine. It is now showing an abort() dialogue box.
anushi has joined #ste||ar
<Zwei_>
K-ballo: "... and the store of x [1] happens-before the store of y [2]"
jakub_golinowski has quit [Ping timeout: 245 seconds]
<zao>
(built with VS2015)
<zao>
(in debug)
<simbergm>
zao: ugh, that means an uncaught exception or?
<simbergm>
any details?
<Zwei_>
Anyway, going to take this to some appropriate channel on slack I think. Thanks for your input K-ballo :)
<K-ballo>
Zwei_: just because there's a happens-before relation, it doesn't mean it has to actually happen before, the order cannot be observed since the writes are relaxed
<K-ballo>
or, it could actually happen before, but the side effects not made visible in order
<zao>
simbergm: Sadly no, I hit the button to break into a debugger but the process apparently just disappared as the loop continued.
<K-ballo>
because, again, the memory consistency model used is relaxed
<zao>
Process 1 failed with an unexpected error code of -1073741819 (expected 0)
<zao>
Process 0 failed with an unexpected error code of -2147483645 (expected 0)
<simbergm>
zao: ok, no worries
<zao>
Console said this.
<Zwei_>
K-ballo: Oh.... man this is weird.
<zao>
(0xc000'0005 and 0x8000'0003)
<Zwei_>
takes some getting used to.
<K-ballo>
that's why we try to stay away from it :P
<zao>
(the latter status code is probably due to trying to attach the debugger)
<Zwei_>
K-ballo: OH, I thought you meant that in reference to me asking questions in here. Still, I'll restrict myself from asking noobish questions here, and try to find better places :)
<Zwei_>
Thanks a lot! <3
<simbergm>
can't really make any sense of that unfortunately :/
<zao>
In short, it still spuriously hits what I'd reckon is a std::terminate or abort.
<K-ballo>
Zwei_: basically, that's what "relaxed" means, that it does not imply any order of effects
<simbergm>
zao: this is also on 8c0d176...?
<zao>
simbergm: Yes.
<simbergm>
ok
<Zwei_>
This C++ concurrency in action book is quite a rough introduction to concurrency... after this I'll read "The Art of Multiprocessor Programming" to iron out any thorny questions I have.
<K-ballo>
the memory model stuff, anything but sequential consistency.. it's mind bending
aserio has quit [Ping timeout: 245 seconds]
vshetty has joined #ste||ar
<Zwei_>
K-ballo: thanks again! Hopefully in a few months time, I'll know enough to actually start contributing. I've used MPI during my PhD, but didn't experiment with MPI much (normally try to pre-calculate stuff, and reduce communication to one all-to-all call at the beginning of the solver, then anything else is point-to-point with the pre-calculated info).
<Zwei_>
multithread is much harder to program :(
<Zwei_>
fun though!
aserio has joined #ste||ar
<simbergm>
hkaiser, heller_, jbjnr: regarding the release, as far as I can tell the only real blocking issues are the VS2015 build, the migrate component test and the current backlog of PRs
<simbergm>
is there anything else that you think *must* be in the release? (I've already pruned the 1.1.0 issue on github a bit)
<simbergm>
I think we've reached the point where fixing any other remaining issues would push back the release an unknown amount of time
<simbergm>
and I'd like to push the release forward *if* you are all happy to do so as well
vshetty has quit [Remote host closed the connection]
eschnett has joined #ste||ar
galabc has quit [Quit: Leaving]
<Zwei_>
So does HPX normally just use the default sequential consistent ordering? Or is acquire-release ordering more used?
<K-ballo>
we go sequentially consistent for almost everything, but a few select things.. like refcount, for instance
<Zwei_>
I see, thanks!
<K-ballo>
libraries we rely on, like boost.lockfree, would probably go lower
<Zwei_>
"The Art of Multiprocessor Programming" assumes sequentially consistency as well. I'll stick with that for now :)
EverYoung has joined #ste||ar
victor_ludorum has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoun_ has quit [Read error: Connection reset by peer]
EverYoun_ has joined #ste||ar
nanashi55 has quit [Ping timeout: 248 seconds]
EverYoun_ has quit [Read error: Connection reset by peer]
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
nanashi55 has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
vamatya has joined #ste||ar
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
aserio has quit [Ping timeout: 256 seconds]
aserio has joined #ste||ar
Nikunj has quit [Quit: Page closed]
jaafar has joined #ste||ar
david_pfander has joined #ste||ar
CaptainRubik_ has joined #ste||ar
david_pfander has quit [Ping timeout: 252 seconds]
mcopik has quit [Ping timeout: 252 seconds]
<github>
[hpx] hkaiser force-pushed fixing_3182 from 99d21fe to 9f6de66: https://git.io/vAaOj
<github>
hpx/fixing_3182 9f6de66 Hartmut Kaiser: Fixing return type calculation for bulk_then_execute....
victor_ludorum has quit [Quit: Page closed]
aserio has quit [Ping timeout: 245 seconds]
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
Smasher has joined #ste||ar
aserio has quit [Read error: Connection reset by peer]
aserio has joined #ste||ar
CaptainRubik_ has quit [Quit: Page closed]
david_pfander has joined #ste||ar
<jbjnr>
hkaiser: heller_ do you know wash's current email address please?
<jbjnr>
I should have realized I have messages from him on the operation bell list
<jbjnr>
so I'll use his gmail account
aserio has quit [Ping timeout: 240 seconds]
aserio has joined #ste||ar
apsknight has joined #ste||ar
parsa has joined #ste||ar
eschnett has quit [Quit: eschnett]
aserio has quit [Ping timeout: 248 seconds]
zbyerly_ has quit [Remote host closed the connection]
apsknight has quit [Quit: apsknight]
aserio has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
aserio1 is now known as aserio
parsa has quit [Quit: Zzzzzzzzzzzz]
hkaiser has quit [Quit: bye]
<zao>
Ooh... I wonder if appveyor lets programs pop UI... in that case, the hang may just be the abort dialogue.