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/ | GSoD: https://developers.google.com/season-of-docs/
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
simbergm has quit [Read error: Connection reset by peer]
diehlpk has quit [Quit: Leaving.]
<heller> maxwellr96: different C++ standards used when compiling boost and HPX
hkaiser has quit [Ping timeout: 276 seconds]
diehlpk has joined #ste||ar
aserio has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
hkaiser has joined #ste||ar
jaafar has quit [Ping timeout: 245 seconds]
jaafar has joined #ste||ar
diehlpk has joined #ste||ar
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
jaafar has quit [Ping timeout: 268 seconds]
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
aserio has quit [Ping timeout: 264 seconds]
aserio has joined #ste||ar
USTOBRE has joined #ste||ar
jaafar has joined #ste||ar
<Yorlik> The creator has spoken: https://www.youtube.com/watch?v=u_ij0YNkFUs (Bjarne at CppCon 2019)
jaafar has quit [Ping timeout: 276 seconds]
<hkaiser> Yorlik: unfortunately, that talk is rather uninspiring
<Yorlik> He's somewhat repeating himself. But after all it marks the talks are bing published bow.
<hkaiser> yah, keynotes are quick to be published, usually
<Yorlik> So the good stuff takes longer? :(
<Yorlik> I'm especially curious about the networking TS talks
<hkaiser> right, I have not even given my talk yet ;-)
<Yorlik> Are doing doing HPX or an application of it?
<hkaiser> mostly HPX with some applications
<hkaiser> Futurize All The Things!
<hkaiser> nowadays I should probably say co_Futurize ;-)
<Yorlik> Futures are somewhat expensive aftr all, eren't they?
<hkaiser> depends on your workload
<Yorlik> I wish I could chop below 100microsec
<zao> HPX - like programming C++ but good!
<hkaiser> if your frame rate is 50Hz, then you can handle 20000 of them in one frame
<Yorlik> The fastest corouting switch I ever measured was 9ns from a tiny library. I kinda liked that.
<hkaiser> zao: I like that!
<zao> Beats the previous slogan.
<hkaiser> indeed
<heller> hkaiser: oh, you are in colorado right now?
aserio has quit [Ping timeout: 250 seconds]
<heller> didn't realize it is happening this week ;)
<hkaiser> heller: not yet, flying tomorrow
<heller> ahh, have a good time and say hi to klaus, bryce and michael
nikunj has joined #ste||ar
<heller> hkaiser: #3961 should be good to go now, btw
<hkaiser> ok, thanks
<Yorlik> I just tested boost::serialization and it's printing "serialization::archive" into the data ????
<Yorlik> For small objects thios really is a waste of space.
<Yorlik> I used a std::ostringstream for the archive to get a package I can send over UDP.
hkaiser has quit [Ping timeout: 264 seconds]
<Yorlik> 112 bytes to send two uint64_t types
<Yorlik> and one uint16_t
<Yorlik> a "pong" package with a message type and two timestamps.
<Yorlik> Is there a way to send more efficiently, e.g. with different optiopns?
aserio has joined #ste||ar
<heller> Yorlik: what do you mean? more context needed
<Yorlik> I am trying to use boost::serialization and boost::asio to send serialized structs over the network for a test client/server messaging.
<Yorlik> Serializing a simple ping message gave me this large serialized package
<heller> aserio: looks like rostam is misbehaving again
<Yorlik> I serialized a message type and two uint64_t
<heller> ah, use hpx::serialization ;)
<Yorlik> So all in all 18 bytes of real payload
<Yorlik> Impossible
<heller> why?
<Yorlik> We don't use HPX on the UE client side
<heller> why?
<Yorlik> I would have to use it just for serialization
<heller> so?
<Yorlik> Which part of HPX would I haver to include to just use its seialization?
<heller> at the moment, everything ;)
<Yorlik> I don't plan to make the client a full HPX app
<heller> but you can use it without starting up the runtime
<heller> no problem there
<Yorlik> This is a little overkill, isn't it?
<zao> So what kind of archive type are you using?
<Yorlik> I mean - if the hpx serialization is so much more eficcient - might be a reason.
<heller> IIRC, the header of an HPX archive is about 32 or 64 bits, that'll give you what you want
<Yorlik> I used an ostringstream
jaafar has joined #ste||ar
<Yorlik> I probably would have to make my messages components for it to work, right? Or dies it work on simple structs too?
<heller> no
<heller> it works almost like boost serialization
<Yorlik> I know the api is the same
<zao> Fewer Rameys :)
<Yorlik> So - could I just use hpx_setup_target on cmake, include the hpx dll and done?
* Yorlik imagines horrible things happening to his client
<heller> yes
<heller> there seems to be another boy in town
<zao> I need to find a cross-language serialization format for float-heavy applications.
<Yorlik> cbor?
<zao> Yorlik: I'd prefer something that had a reasonably formal IDL, ad-hoc schemas with JSON/CBOR are a bit meh.
<Yorlik> Why not just flatbuffers / protobuffers then?
<zao> Well, that's the thing, I need to find what there is and pick the least horrible one.
<zao> Haven't had a good experience with the C++ side of protobuf.
<heller> zao: looked into libffi yet?
<zao> In what way?
<heller> that it might solve your problem ;)
<heller> might have just misremembered what it's use case is for though...
<heller> other than that: do what the cool kids do, just use json/yaml ;)
<zao> FFI would be more for in-process language interop, I'm doing poor-man's inter-process RPC.
<zao> Ad-hoc JSON schemas are lovely, but I've got a bit too much in the way of floating point data for it to work well.
<zao> Time will tell, I could always start with it.
<heller> i guess XMLRPC is the closest thing to a standardized beast
<heller> nowadays
<Yorlik> Seems Cmake is trolling me again. Is it correct or wrong to assume that hpx_setup_target(gc_app ) should allow gc_app to include <hpx/hpx.hpp> ?
jaafar has quit [Ping timeout: 265 seconds]
aserio has quit [Ping timeout: 245 seconds]
USTOBRE has quit [Quit: Connection closed for inactivity]
aserio has joined #ste||ar
jaafar has joined #ste||ar
<Yorlik> Anything wrong with this: ?
<Yorlik> std::ostringstream outstream;
<Yorlik> hpx::serialization::output_archive ar(outstream);
<Yorlik> I'm getting template errors for output_archive
<zao> The ctor calls the argument "Container", might be a hint to what concept is in play?
<Yorlik> Woops - is this where HPX diverges from the boost API then maybe?
aserio has quit [Quit: aserio]
<zao> You might be able to implement some traits, but hpx/traits/serialization_access_data.hpp seems to imply a vector-like?
<Yorlik> Gotta dig deeper it seems. Thanks for the hint !
<zao> (I've never used this part of HPX, just digging around on github :)
<Yorlik> Got poked by a fellow dev - kinda semi afk now.
<Yorlik> BBL
jaafar has quit [Ping timeout: 276 seconds]
jaafar has joined #ste||ar
hkaiser has joined #ste||ar
<heller> Yorlik: the tests should make the usage much clearer
<Yorlik> I'll lokk into them once my meeting is done .
jaafar has quit [Ping timeout: 265 seconds]
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
jaafar has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
jaafar has quit [Ping timeout: 268 seconds]
nikunj has quit [Quit: Leaving]