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/
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
EverYoun_ has quit [Ping timeout: 265 seconds]
EverYoun_ has joined #ste||ar
EverYoung has joined #ste||ar
EverYoun_ has quit [Ping timeout: 256 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
jakub_golinowski has quit [Quit: Ex-Chat]
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
jakub_golinowski has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
jakub_golinowski has quit [Remote host closed the connection]
Smasher has quit [Remote host closed the connection]
mcopik_ has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
mcopik has quit [Ping timeout: 256 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
daissgr has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
parsa has joined #ste||ar
EverYoung has quit [Ping timeout: 252 seconds]
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
shailesh has joined #ste||ar
shailesh has quit [Remote host closed the connection]
hkaiser_ has joined #ste||ar
hkaiser has quit [Ping timeout: 256 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser_ has quit [Ping timeout: 264 seconds]
daissgr has quit [Ping timeout: 256 seconds]
diehlpk has quit [Remote host closed the connection]
<github> [hpx] hkaiser pushed 1 new commit to master: https://git.io/vAhpT
<github> hpx/master 737f04b Hartmut Kaiser: Merge pull request #3223 from STEllAR-GROUP/msimberg-patch-2...
nanashi55 has quit [Ping timeout: 256 seconds]
nanashi55 has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
mcopik_ has quit [Ping timeout: 240 seconds]
nikunj has joined #ste||ar
jaafar has quit [Ping timeout: 276 seconds]
victor_ludorum has joined #ste||ar
victor_ludorum has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
nikunj has quit [Quit: Page closed]
hkaiser has quit [Quit: bye]
nikunj has joined #ste||ar
mcopik has joined #ste||ar
nikunj has quit [Ping timeout: 260 seconds]
<github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/vAjtS
<github> hpx/gh-pages 779df19 StellarBot: Updating docs
mcopik has quit [Ping timeout: 240 seconds]
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Remote host closed the connection]
daissgr has joined #ste||ar
Smasher has joined #ste||ar
K-ballo has joined #ste||ar
daissgr has quit [Ping timeout: 240 seconds]
daissgr has joined #ste||ar
<Zwei> Okay, I've finished reading/studying C++ Concurrency in Action, so I'm going back to this: https://github.com/STEllAR-GROUP/hpx/issues/3034
<Zwei> Just a question of terminology, which I didn't see covered in the book I read, what does "HPX serialization" mean?
<Zwei> From what I've read in the book, serialization, in hand-wavey-terms, is synchronization, so threads are "serialized" with multithreading primitives such as mutexes, condition variables, etc...
<Zwei> is that what you mean?
<Zwei> If so, why can't we just use call_once or something similar?
<Zwei> I guess I'll read the blog post linked.
<Zwei> gotta go out now, ttyl
mcopik has joined #ste||ar
<zao> Zwei: Serialization is also the act of encoding and decoding data from a transport format.
<zao> Saving to files, converting data to a format suitable for network comms, etc.
<zao> Literally translating state into a stream of bits/bytes and back again, retaining object types and relationships.
<zao> (but yes, you're right in that it also means ordering parallel operations when you're talking about threading)
<Zwei> zao: I see, thanks :)
<Zwei> I'll read the blog post linked in that issue later. Just prepping for a coding interview atm, this needs to be done by Monday, been putting it off :-/
<zao> Procrastinating? Never heard of it <_< :)
<Zwei> heh, procrastinating by doing other constructive things. I don't want to practice arrays and strings problems. Learning about multithreading is much more fun!
<K-ballo> it means to turn into a series, could be bits, could be events
<Zwei> Still trying to get my head around it, I'll prob have a better idea once I've read that blogpost mentioned. (I.e. "to serialize empty structs without explicit serialization functions" means to turn into a series.... how?)
<Zwei> Oh, don't answer that question, don't want to waste your time.
<Zwei> I should read and get more info first
<Zwei> then I'll come back if I have more questions :)
<K-ballo> we turn objects into a series of bits to send them over the network and reconstruct them on the other side
<K-ballo> we do that for remote action invocation, both for the arguments and for the result
<Zwei> OH! I see. Kinda like message passing then?
<K-ballo> kinda.. message passing sounds more high level, but possibly yeah
<Zwei> thanks K-ballo!
<zao> Say that you want to send a string to someone over the network. You need to decide for both sides on how to store it, and how to indicate to the other side what's on the wire.
<zao> So you may emit a small integer first indicating the type of the thing that comes, then maybe a fixed-size integer indicating the length of the string, and then the characters one by one.
<zao> Or you may assume on the other end that a null-terminated string is coming, and they can just consume bytes until they find an end.
<zao> On the sending end you'd be serializing, on the receiving end you'd be deserializing.
<zao> Simple datatypes like that are easy. It gets way more fun when you have objects that refer to other objects, and you want that relationship to persist on the other side.
<zao> Then you need to represent object identity with some sort of wire-friendly identifier, or otherwise have enough information to re-establish state on the other side.
<zao> So for "message passing" over most fabrics to make sense, you need to serialize into messages first.
<Zwei> I see
<Zwei> I've done similar stuff, but not that low level. Basically, sending doubles over a network, with MPI, when dealing with distributed matrices.
parsa has joined #ste||ar
<Zwei> Right, going to spend the next two days drilling the programming puzzles, then take this coding test. I'll get back to working on concurrency/HPX afterwards :)
<Zwei> This has been my only sanity during the job searching process, love you guys :D
<zao> I forget with all the new faces, are you aiming to participate in GSoC, or just a fan? :)
<Zwei> Just a fan.
Anushi1998 has joined #ste||ar
<Zwei> Been looking for a good open source C++ project to contribute to for a while, then I found this, and I've done *some* parallel programming before, so I decided to learn more and contribute :)
<zao> It's indeed alluring.
nikunj has joined #ste||ar
eschnett has joined #ste||ar
K-ballo has quit [Ping timeout: 268 seconds]
mcopik has quit [Ping timeout: 256 seconds]
K-ballo has joined #ste||ar
mcopik has joined #ste||ar
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
mcopik has quit [Ping timeout: 260 seconds]
Anushi1998 has quit [Ping timeout: 245 seconds]
mcopik has joined #ste||ar
K-ballo has quit [Ping timeout: 260 seconds]
K-ballo has joined #ste||ar
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
Smasher has quit [Changing host]
Smasher has joined #ste||ar
<jbjnr> Zwei: just fyi - there is some info about our latest work on serialization in here ftp://ftp.cscs.ch/out/biddisco/hpx/Applied-Computing-HPX-ZeroCopy.pdf
jaafar has joined #ste||ar
<Zwei> jbjnr: Thanks, noted :)
mcopik has quit [Ping timeout: 240 seconds]
Anushi1998 has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
victor_ludorum has joined #ste||ar
anushi has joined #ste||ar
Anushi1998 has quit [Ping timeout: 252 seconds]
mcopik has joined #ste||ar
mcopik has quit [Ping timeout: 256 seconds]
diehlpk has joined #ste||ar
Anushi1998 has joined #ste||ar
nikunj has quit [Quit: Page closed]
Anushi1998 has quit [Remote host closed the connection]
Anushi1998 has joined #ste||ar
nikunj has joined #ste||ar
diehlpk has quit [Ping timeout: 265 seconds]
victor_ludorum has quit [Ping timeout: 260 seconds]
diehlpk has joined #ste||ar
victor_ludorum has joined #ste||ar
Anushi1998 has quit [Ping timeout: 276 seconds]
eschnett has quit [Quit: eschnett]
jaafar has quit [Ping timeout: 260 seconds]
thundergroudon[m has quit [Quit: removing from IRC because user idle on matrix for 30+ days]
jaafar has joined #ste||ar
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Client Quit]
victor_ludorum has quit [Quit: Page closed]
mcopik has joined #ste||ar
jaafar has quit [Ping timeout: 276 seconds]
mcopik has quit [Ping timeout: 264 seconds]
mcopik has joined #ste||ar
mcopik has quit [Ping timeout: 240 seconds]
hkaiser[m] has joined #ste||ar
hkaiser[m] has quit [Read error: Connection refused]
<diehlpk> heller_, I started to work on the draft for the article
eschnett has joined #ste||ar
jaafar has joined #ste||ar
eschnett_ has joined #ste||ar
jaafar has quit [Ping timeout: 248 seconds]
eschnett has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
eschnett_ has quit [Quit: eschnett_]
jaafar has quit [Ping timeout: 256 seconds]
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
<nikunj> I think I have found the underlying reason as to why quicksort example is breaking. I think it is due to breaking in hpx::components::memory_block implementation itself. I was able to produce the same output with a very basic code which only creates a memory_block, access_memory_block and then simply freeing the memory_block.
<nikunj> Using gdb to debug the example, I found that the thread was always giving a SIGSEGV signal which broke the code.
<K-ballo> access to the memory_block after free?
<nikunj> @K-ballo: that can be the case
<nikunj> I have just started to inspect for reasons that is breaking the example. Debugging it gave me SIGSEGV in one of the threads which broke the code. Playing with the code I found that the quicksort implementation is correct.
<nikunj> Then I tried implementing the simplest of memory_block to check if it is the underlying reason for breakage
<nikunj> And this code of mine broke as well with the very same reason ( using gdb ) i.e. SIGSEGV in the thread.
<nikunj> @K-ballo: I am currently reading the code for memory_block to inspect for breaking points.
<zao> Interesting.
<nikunj> @K-ballo: Could you please help me regarding which file should I dig into in detail to search for any breaking? I think it is hpx/runtime/components/server/memory_block.hpp, but it is more of a hunch ( since every file was originating from here ).
<K-ballo> I'm not familiar with memory_block myself, but from the path that sounds like the right place, possibly