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/
<Yorlik>
Which of the boost libraries does HPX need?
<K-ballo>
from the ones that need building/linking?
<Yorlik>
Yes
<K-ballo>
those are listed somewhere in the prerequs, the header only ones are not
mdiers_ has quit [Remote host closed the connection]
<Yorlik>
Seems trating warnings as errors is not really a good idea when building boost ...
mdiers_ has joined #ste||ar
<simbergm>
Yorlik: thanks for noticing, will update
<zao>
Yorlik: Heh, definitely not :)
<zao>
Spoke to the Spack guy last night, "yeah, some recipes are not quite-as-maintained" :)
<Yorlik>
I have to overcome a ton of newbie hurdles in the moment.
<Yorlik>
I've been doing solely Lua scripting the last 4 years
<zao>
I wonder if I should contribute this back upstream... do we have any release yet where we've fixed that exception snafu, or should one clamp at 1.68 onward?
<Yorlik>
And a wee bit of C#
<Yorlik>
The first big wall for me in the moment is learning modern CMake and adopting a superbuild pattern
david_pfander has joined #ste||ar
david_pfander1 has joined #ste||ar
mdiers_ has quit [Remote host closed the connection]
david_pfander1 has quit [Ping timeout: 240 seconds]
mdiers_ has joined #ste||ar
<Yorlik>
Does HPX expect boost to be built as shared libs?
<Yorlik>
Because my libs are called libboost_xyz and HPX is looking for boost_xyz
<zao>
Guessing you're on Windows?
<zao>
I forget whether we disable autolinking or not.
<Yorlik>
Yes
<Yorlik>
I'm using a CMake project in VS
<Yorlik>
Trying to integrate boost libs and hpx into my project superbuild
<Yorlik>
Since our client will be on windows and we will have sherd code I can't really get away from that cross platform thing
<Yorlik>
sherd = shared
<zao>
Docs suggests --build-type=complete on Windows, which builds all variations.
<zao>
Fair warning - HPX is a bit memory-hungry when compiling/linking some bits, so be careful :)
<zao>
Mostly for the tests/examples, tho.
<Yorlik>
My inexperience with CMake is the worst - I'm going through some harsh lessons.
<zao>
Bonus points for using VS's built-in interpretation of CMake :)
<Yorlik>
Example: Creating a CMake Variable with SET(MYVAR SomeValue PARENT_SCOPE) Does not also add the variable to your local scope
<Yorlik>
Actually VS is not the issue
<zao>
Heh.
<Yorlik>
It's CMake itself - VS is actually a improvement, since the json config takes the burdon oiff me to write command lines.
<Yorlik>
I just have two configuration files in my superbuild: One for VS and one for Sublime
<Yorlik>
Sublime CMake Builder is really nice for the Linux side of thins
<Yorlik>
And adding stuff from my CMake build to intellisense is easy - so - I actually like it.
<Yorlik>
However - cross compiling is a harsh miustress at times.
<zao>
I've long said that "CMake is the least horrible build generator out there", still holds.
<Yorlik>
Yup
<Yorlik>
Unreal engine uses a custom C# written build system.
<Yorlik>
I'll have to deal with that too once we integrate the client side of things
<Yorlik>
I'm building boost with multithreading enabled and all libraries are named boost_xyz-mt.dll - I hope that won't be an issue ß
<Yorlik>
Can't wait to have my superbuild stable - it still likes to explode every now and then.
<zao>
ißue :)
<K-ballo>
Unreal engine and HPX?
<Yorlik>
The idea is to make a custom server with hpx which uses a client dll which communicates with Unreal Engine
<Yorlik>
So Unreal is just a wrapping around the real client
<Yorlik>
But the client dll and the server will have some shared code
<Yorlik>
Since it affects the simulation there might even be hpx in it
<Yorlik>
But we'll have an internal API between UE and the client
<Yorlik>
Essentially the idea is to make the client an Unreal plugion
<Yorlik>
Main application for hpx is the server
<Yorlik>
And the task based Lua engine we want to create
<Yorlik>
A Lua State will only have immutable global state while the game objects are just reacting on events with Lua tasks which run on the Lua states
<Yorlik>
All dynamic game object data is meant to live in the game objects, probably in some sort of multithreaded buffered ECS
<Yorlik>
At least thats the plan
<K-ballo>
who is "we" above?
<Yorlik>
A bunch of people - advanced hobbyists, some of them programmers
<Yorlik>
No company.
<K-ballo>
sounds pretty cool
<Yorlik>
We've been working together for 4 years already until we ultimately decided to abandon the crappy platform we were on.
<Yorlik>
So we had a serious setback, but gained a lot of freedom now
<K-ballo>
ooh, which platform was that?
<Yorlik>
Its a game created by a small indie studio in Virginia
<Yorlik>
They make it moddable, but its horrible.
<Yorlik>
AFter 4 years we had enough
<Yorlik>
Name is "Legends of Aria"
<Yorlik>
I'm happy we quit it
<Yorlik>
Now the plan is to make our own game fully from scratch
<Yorlik>
It's scary, but we see it as a doable challenge.
<Yorlik>
Main constraint is to keep it fun all the time, no matter how far we go. :)
<Yorlik>
Does it matter for hpc if I build boost with or without multithreading support?
<Yorlik>
hpx
* Yorlik
messes it up all the time
<K-ballo>
I thought boost had retired the single-threaded builds
<K-ballo>
they no longer show up witith --build-type=complete at least
<Yorlik>
There still is an option for b2
<Yorlik>
I had it on and my taggede builds now are all named boost_xyz-mt.dll
<Yorlik>
Just swapped threading out for single this time
<K-ballo>
aren't all those params conflicting? a complete build type together with all those build flags?
<K-ballo>
my b2 command line on windows is just `b2 --build-type=complete address-model=32,64 -j8` because I still build 32bit for some reason (you'll need 64bit for hpx)
<Yorlik>
I had problems when I used system layout - but I might be doing something wrong. I'm still very new to this
<K-ballo>
building boost is painful... we are trying to phase that out, but it will take forever
<Yorlik>
I saw a convo on git which showed that.
<Yorlik>
After its a big and complex system
<Yorlik>
Phasing out stuff means you ave to do it yourself or find a good replacement ...
<Yorlik>
That's not trivial.
<zao>
Blargh... just installed singularity-3.0.3 on my machine. Tarbombed my build tree and then installed into /usr/local contrary to all existing Go resources. \o/
<zao>
Move the whole project to Golang, don't document shit, don't make security or feature fixes to 2.x.... *angry rant*
<zao>
And oh, break the interface.
<Yorlik>
Sounds very .... modern ;)
<zao>
Straying into off-topicness, but we have to use it :(
<heller_>
is singularity getting mature? now why would I want to use it instead of plain old docker?
<zao>
heller_: They've recently shed their old C codebase for Go, currently at 3.0.3.
<zao>
The use case is more HPC-friendly, tagline being "bring-your-own-environment".
<zao>
Bring a container with the OS, deps and program you need to run, invoke `singularity exec container.simg /awesome-hpx-app` in your batch job.
<zao>
No persistent daemon with weird rights, in many configuration not even needing suid binaries for Singularity.
<zao>
We use it at HPC2N in production to host the horrible CentOS bullshit that ATLAS LHC jobs require.
<zao>
They've got functionality to expose NV GPUs, some MPI impls, and other aspects of the surrounding world into the container.
<zao>
Also sharing the networking or running with full network isolation, also things like binding paths into the container, with or without writable overlays.
<zao>
Nice in theory, great when it works :)
<Yorlik>
There is no scarcity of great concepts ...
<ste||ar-github>
hpx/fixing_3639 cc44301 Hartmut Kaiser: Fixing ticket 3639, dataflow now works with functions that return a reference.
ste||ar-github has left #ste||ar [#ste||ar]
ste||ar-github has joined #ste||ar
<ste||ar-github>
[hpx] hkaiser opened pull request #3640: Dataflow now works with functions that return a reference (master...fixing_3639) https://github.com/STEllAR-GROUP/hpx/pull/3640
ste||ar-github has left #ste||ar [#ste||ar]
daissgr has joined #ste||ar
<Yorlik>
hkaiser: Just checked out vcpg - really a nice tool - thanks for the tip. Still I have to figure out how to get my CMake thing right. Gotta get through my self tought crash course in build engineering. ;)
daissgr has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 264 seconds]
jaafar has joined #ste||ar
diehlpk_work has joined #ste||ar
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<K-ballo>
can't build release anymore :| vs gave up
<K-ballo>
1>Error: The operation could not be completed. Unspecified error
parsa[[[w]]] has joined #ste||ar
<K-ballo>
hkaiser: does it work for you? either release or relwithdebuginfo
aserio1 has joined #ste||ar
<K-ballo>
wiping the .vs folder solves it, some sort of experimental caching/fast load gonewrong
aserio has quit [Ping timeout: 252 seconds]
aserio1 is now known as aserio
hello has joined #ste||ar
<hello>
hello all.
<hello>
how to debug long time met bug???
<hello>
how to debug bug that occur after long time?
<aserio>
hello: It depends on the error. In general, you try to reduce your problem down to a minimal reproducible case
<hello>
but it takes too time to occour again...
<aserio>
What error are you getting
<hello>
segment fault
<hello>
and I dump, nothing got.
<hello>
and valgrind also nothing got.
<aserio>
can you send the error in a link
<hello>
./run.sh: line 11: 577 Segmentation fault (core dumped)
<aserio>
What are you doing at line 11
<hello>
run my c++ program
<hello>
the program use 256G memory
<aserio>
Well then you have a memory leak
akheir has quit [Remote host closed the connection]
<aserio>
are you using pointers?
<hello>
my machine is 378G
<hello>
yes, but velgrind nothing got.
<aserio>
Don't
<hello>
My program run well in scale 2-29, but failed at 30.
<aserio>
There is a 99% p
<hello>
???
<aserio>
chance that you missed an index or something
<hello>
yes
<aserio>
I would advise rewriting your code to get rid of the raw pointers
<hello>
no , I am using c
<hello>
not using c++, I want to get speed.
<hello>
and optimize
<aserio>
lol, then you must suffer the consequences :p
akheir has joined #ste||ar
david_pfander has quit [Read error: Connection reset by peer]
david_pfander has joined #ste||ar
<hello>
new progress
<hello>
I found the program segment fault at outEdgeArray[pos] = dst;
<hello>
and outEdgeArray is 0x0
<hello>
but I don't know who changed it.
<aserio>
I assume you did because it is your code...
david_pfander has quit [Ping timeout: 250 seconds]
<hello>
thank
<hkaiser>
K-ballo: I fixed that future<R&> issue we talked about yesterday
<K-ballo>
hkaiser: I saw it, looks ok
<K-ballo>
shared state should not need to know about remote (in set_remote_state), but I can look into that in the future
<ste||ar-github>
hpx/fixing_3639 cd4481c Hartmut Kaiser: Fixing ticket 3639, dataflow now works with functions that return a reference.
<hkaiser>
heller_, K-ballo: I have added another overload to future_data_result<Result&> and the compilation error goes away - however I'm not sure if this is a correct solution
<khuck>
can someone remind me what this error means: terminating with uncaught exception of type hpx::detail::exception_with_info<hpx::exception>: <unknown> (while trying to resolve: =3:7910): HPX(network_error)
<heller_>
yes and no ;)
<hkaiser>
khuck: could be zombies lurking
<heller_>
K-ballo: another HPX process is running on the same machine
<khuck>
impossible
<K-ballo>
?
<khuck>
K-ballo: mistaken identity - he meant me
<hkaiser>
wasn't me this time ;-)
<khuck>
yeah, usually hartmut does it
<khuck>
heller_: I am the only user on the machine, it's only been up 2 days, and nothing else is running
<hkaiser>
khuck: =3:7910 is a strage ip address
<khuck>
hkaiser: agreed
<heller_>
khuck: ss might help
<khuck>
heller_: ss?
<hkaiser>
does it use ipv4 or ipv6?
<K-ballo>
...
<heller_>
khuck: the new netcat
<heller_>
anyway, looks like it can't resolve =3 to an IP