hkaiser 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/
jaafar has joined #ste||ar
mbremer has quit [Quit: Leaving.]
parsa has joined #ste||ar
parsa has quit [Client Quit]
parsa has joined #ste||ar
<hkaiser>
K-ballo: we should be able to contact him
parsa has quit [Quit: Zzzzzzzzzzzz]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 250 seconds]
parsa has joined #ste||ar
parsa has quit [Remote host closed the connection]
parsa has joined #ste||ar
parsa_ has joined #ste||ar
parsa has quit [Quit: *yawn*]
parsa_ is now known as parsa
parsa has quit [Client Quit]
parsa has joined #ste||ar
parsa[w] has quit [Quit: Leaving]
jbjnr has joined #ste||ar
david_pfander has joined #ste||ar
<Yorlik>
Seems /boost/auto_link.hpp is the key to get my build working ...
* Yorlik
digs some more ...
hkaiser has joined #ste||ar
nikunj1997 has quit [Ping timeout: 268 seconds]
<jbjnr>
heller_: yt?
<Yorlik>
Do you do any CI on Windows for HPX? If yes: How?
<jbjnr>
Yorlik: there's a CI run by appveyor I think
nikunj has joined #ste||ar
<Yorlik>
Just asking because I'm still fighting to build on Windows. I'm following precedures more now, but there are strange things happening. Still not sure if it's me doing stupid things or something in the depths of the build system being broken. The vcpkg build worked.
<heller_>
jbjnr: what's up?
<jbjnr>
just wanted to ask about lazy thread init and remove_wait_or_new
<heller_>
yeah
<jbjnr>
I feel like I need to look at these
<heller_>
there are so much things to do ;)
<heller_>
sure
<jbjnr>
but I know you were tweaking context????
<jbjnr>
so maybe you have stuff you want to change
<heller_>
i have
<heller_>
but everything is moving sooo slowly
<heller_>
and I don't want to get new stuff in until we have a more stable master
<jbjnr>
what's broken?
<heller_>
everything
<jbjnr>
and who broke it!
<heller_>
everyone ;)
<jbjnr>
lies. I have committed nything in ages :)
<jbjnr>
lies. I haven't committed nything in ages :)
<heller_>
the problem is: once the CI becomes unstable, noone really looks closely, and everything is just being looked at as "yeah, unrelated, has been there before"
<heller_>
and then crap piles up
<heller_>
so my quest now is to clean that mess up
<jbjnr>
don't care bout that. what is actually broken?
<heller_>
see my recent commit spree ;)
<Yorlik>
Technical debt can become horrible. I'm a friend of early polishing.
<heller_>
wait_all seems to be broken, sync_put_parcel, function (now fixed), executor parameters
<Yorlik>
That's one of the reasons why I'm so stubbornly trying to integrate boost, hwloc and hpx into my cmake superbuild.
nikunj has quit [Ping timeout: 246 seconds]
<heller_>
jbjnr: exception handling in general is a huge pile of something
<Yorlik>
It seems going the route over MSBuild is now starting to work.
<Yorlik>
Still - I don't understand why the -bigobj setting is not working when I build using Ninja
<heller_>
ninja being experimental on windows, maybe?
nikunj has joined #ste||ar
<Yorlik>
Well - I guess it's not officially HPX supported. All in all for my stuff it works like a charm.-
<Yorlik>
But since HPX is CMake based, I'd guess any CMake supported build system ~should work.
<Yorlik>
Seems I'm hitting the devil lurking in the details.
Yorlik has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
<Yorlik>
It's weird - having an MSBuild prject now the compile works. But exploring all the project settings there is no ocurrence of the -bigobj option anywhere (at least I couldn't find any.) The MS docs say it lives in the compoiler command lines additional options, but there is nothing.
K-ballo has joined #ste||ar
<Yorlik>
Allright - found it - seems it configuration dependent ...
<Yorlik>
Now the question is why it doesn't work with Ninja as build system - though I feel tempted to skip that question.
<heller_>
ninja is not a multi config build system
<Yorlik>
You mean building multiple configs in one run isn't possible?
<heller_>
no, switching configs on the fly
<heller_>
via the visual studio UI
<Yorlik>
I use CMakeSettings.json for that
<Yorlik>
So ninbja is oblivious of it anyways
<Yorlik>
I just use different build directories for every config in the json file.
<Yorlik>
Interestingly enough I actually find the -bigobj setting in the ninja file - now it's even more weird why it doesn't get passed to the compiler properly
<heller_>
*shrug*
<Yorlik>
It seems to build correctly with Ninja now - which is even more scary - because I don't really know why. I had forgoten to pass one Variable before though: HPX_WITH_BOOST_ALL_DYNAMIC_LINK
<Yorlik>
Not sure why the builds before exploded with the object count error.
<Yorlik>
its at 274 / 464 now
<Yorlik>
Never been that far before
<heller_>
nice
<heller_>
good that it works now
<Yorlik>
It still uses the mangled library names thoug
<heller_>
would be nice if you could document your setup
<heller_>
so no success in linking?
<Yorlik>
I'll do that and test it
<Yorlik>
It works - because I have the libs
<Yorlik>
But it supports bigobj now
<Yorlik>
I will make a stripped down version of my superbuild and document it
<Yorlik>
Will need a bit though - I really want to start playing with HPX - all this building mess was painful.
<Yorlik>
375/464 now :)
<Yorlik>
A part of the problem surely was me not RTFMing enough.
<Yorlik>
But still there's oddities
<Yorlik>
E.G. HPC complaining when the unmangled libraries are missing but requesting the mangled ones. I'll dog a bit more to understand that better.
<Yorlik>
s/dog/dig/g
<Yorlik>
Since I started using discord, which allows post correction my typing became horrible - not really used to IRC discipline anymore ;)
<heller_>
btw, don't mix debug and release builds ;)
<Yorlik>
I wont
<Yorlik>
I have strictly separate release and build install and build foldrs
<Yorlik>
for everything
<Yorlik>
I think I need a break now - next step will be helloworld business :)
<Yorlik>
Thanks a lot for all the help I received and sorry for the hassle I might have caised - I know a newbie trying to unconventionally build a complex system can be a nuisance ;)
<Yorlik>
However - success :)
* Yorlik
heads out for break
nikunj has joined #ste||ar
nikunj has quit [Ping timeout: 240 seconds]
<K-ballo>
heller_: any options I should tweak for your benchmark?
<heller_>
K-ballo: work_delay would be a nice start
<heller_>
K-ballo: I'd assume that your changes have a nice effect on the smaller grain sizes
nikunj has joined #ste||ar
<K-ballo>
looks like noise to me
<heller_>
ok, too bad
<heller_>
K-ballo: I did see some positive effect
<K-ballo>
heller_: which params did you run it with? it was all over the place here
<heller_>
for j in 1 10 100 1000; for i in 1 2 4 8; echo "$i threads, $j"; ./bin/foreach_scaling_test --hpx:threads=$i --work_delay=$j; echo ''; end; end
<heller_>
varying delay and threads
<K-ballo>
and where were the positive effects? localized or overall?
<simbergm>
what's the universal way to do that? or just ifdefs?
<K-ballo>
the rules changed many times since C++11, and compilers differ in their treatment of the issues as DRs.. so...
<K-ballo>
it's a bit of a mess
<simbergm>
what is least wrong? ;)
<K-ballo>
no idea...
<K-ballo>
leaving the std::move should be fine in that NRVO cannot happen for a param anyways, so it would not be messed up by it
<K-ballo>
what was the warning? redundant std::move?
RostamLog has joined #ste||ar
<K-ballo>
I'll just revert back to async_execute and leave the optimization as future work for someone else
<hkaiser>
currently, the implementation of async_execute just forwards to a dispatch point anyways, so doing the same for sync_execute would be an option
<hkaiser>
K-ballo: sure, I can have a look at that
<zao>
The one I set up for my home box has something like `depends_on('boost@:1.68.0', when='@:1.2.0')` and `depends_on('hwloc@:2.0', when='@:1.2.0')`.
<zao>
And also spells HPX_WITH_MALLOC correctly, so the one in Spack needs some maintenance :D
<zao>
Hrm, the second depends_on there is incorrect, bah.
<zao>
Don't conference and code, kids.
<heller_>
time for a PR against spack i guess ;)
<heller_>
I like spack a lot as well
<heller_>
especially when being combined with hierarchical modules
<heller_>
aka lmod (the lua modules)
<heller_>
woohoo, three successful master builds on circleci in a row
<simbergm>
heller_: thanks for doing this (I thought circleci email notifications were broken for a while...)
<heller_>
He
<heller_>
simbergm: I am just annoyed be the test failures ;)
<jbjnr>
I
<jbjnr>
I
<jbjnr>
I'm impressed
<jbjnr>
99% tests passed, 2 tests failed out of 790
aserio has quit [Quit: aserio]
<heller_>
I really need 100% to be able to sleep ;)
<jbjnr>
(on my laptop)
<jbjnr>
launch_process is knackerd
<jbjnr>
and tests.regressions.performance_counters.papi_counters_basic_functions is the other, probably an easy fix
<jbjnr>
see y'all t'morrow
<jbjnr>
PS. nice job heller_ on fixing things
<heller_>
simbergm: btw, dropping gcc4 and clang3 is something we should do
<heller_>
hartmut agreed there
jbjnr has quit [Ping timeout: 252 seconds]
ShmuelLevine has quit [Read error: Connection reset by peer]