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/
josef_k has joined #ste||ar
hkaiser has joined #ste||ar
jakemp has joined #ste||ar
ajaivgeorge has joined #ste||ar
ajaivgeorge_ has joined #ste||ar
ajaivgeorge has quit [Ping timeout: 240 seconds]
vamatya has quit [Ping timeout: 260 seconds]
denis_blank has quit [Quit: denis_blank]
hkaiser has quit [Quit: bye]
josef_k has quit [Ping timeout: 240 seconds]
K-ballo has quit [Quit: K-ballo]
ajaivgeorge has joined #ste||ar
ajaivgeorge_ has quit [Read error: Connection reset by peer]
EverYoung has quit [Ping timeout: 246 seconds]
jaafar has quit [Quit: Konversation terminated!]
jakemp has quit [Ping timeout: 240 seconds]
pree has joined #ste||ar
ajaivgeorge has quit [Quit: ajaivgeorge]
ajaivgeorge has joined #ste||ar
ajaivgeorge has quit [Client Quit]
ajaivgeorge has joined #ste||ar
ajaivgeorge has quit [Client Quit]
ajaivgeorge has joined #ste||ar
ajaivgeorge_ has joined #ste||ar
ajaivgeorge_ has quit [Client Quit]
ajaivgeorge_ has joined #ste||ar
ajaivgeorge has quit [Ping timeout: 268 seconds]
pree has quit [Ping timeout: 240 seconds]
pree has joined #ste||ar
ajaivgeorge_ has quit [Quit: ajaivgeorge_]
vamatya has joined #ste||ar
vamatya has quit [Quit: Leaving]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
pree has quit [Ping timeout: 240 seconds]
david_pf_ has joined #ste||ar
ajaivgeorge has joined #ste||ar
ajaivgeorge has quit [Ping timeout: 260 seconds]
ajaivgeorge has joined #ste||ar
josef_k has joined #ste||ar
pree has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
ajaivgeorge has quit [Quit: ajaivgeorge]
bikineev has quit [Remote host closed the connection]
ajaivgeorge has joined #ste||ar
mcopik has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
<ABresting>
Hey guys, this is Abhimanyu. I need some advice regarding my GSoC project i.e. I am trying to handle stack overflow in HPX.
<ABresting>
I tried to understand the method used by Rasdaman( http://www.rasdaman.org/ticket/811) which bryce/wash referred me to look into. So, I found out they used which is a static library and cannot support parallel computing, they have mentioned it clearlily with a graph reflecting the same.
<ABresting>
Implemention wise Rasdaman has used signal.h to generate a signal(SIGSEGV) upon stack overflow. The signal is backtraced to the address/piece of code which lead to stack overflow. Since, the library is not shared so only one program can use the above library at a time. So we may have some scalablity issues right there.
<ABresting>
We do need some similar implementation to reach our end goal, meanwhile, in libsigsegv, they have used quite neat and operationally well implementation, similar to which I intended to develop. Kindly provide me your insight about a shared library which is something we want right?
david_pf_ has quit [Quit: david_pf_]
<jbjnr>
ABresting: I'm not familiar with what you're doing, but the fact that hpx is a parallel library -do you mean multithreaded - or distributed - hould not really affect how stack overflows arehandled. If data beyone\d the stack end is accessor or requested (I'm not sure which ) then the problem is the same
<jbjnr>
^accessed
<jbjnr>
I presume that you want to detect when a stack overflow happens and then increase the stack to fix it ....
<jbjnr>
since stacks in hpx are just malloced blocks anyway
hkaiser has joined #ste||ar
<jbjnr>
hkaiser: good day. I saw your email - yes please go ahead and make channges - was there something you didn't like in there?
<hkaiser>
jbjnr: nothing serious enough to resubmit
<hkaiser>
nice paper!
<jbjnr>
fix it anyway cos I will email the fixed version tomorrow night anyway, regardelss of whether you make more changes. I fixed quite a few typos etc
<jbjnr>
they told me they would assign reviewers on monday, so ...
<jbjnr>
bbiab
<ABresting>
jbjnr: Hi john thanks for your reply. basically, the solution which Rasdaman has used is in a form of static library and as you know if a library is static then only one worker thread will be able to use it, so multiple programs will not be able to use it at a time. IDK even why those guys developed it this way(may be they developed it long a while back and were focusing on a concurrent solution rather than a parallel one).
<ABresting>
Anyways, HPX as a parallel library needs a shared solution like libsigsegv where each thread can have this feature.
bikineev has joined #ste||ar
<ABresting>
but as mentioned libsigsegv is quite good and tell me if I am missing something but we need some similar solution right?
Matombo has joined #ste||ar
<ABresting>
hkaiser: I need you on this one, as idk if somewhat similar stack overflow detecting library implementation(with respect to libsigsegv) for HPX may alarm any licensing issue for us down the road?
<hkaiser>
ABresting: Im not a lawyer
<hkaiser>
so it's difficult to tell
<hkaiser>
the most secue way in terms of licensing would be to keep all of the code you produce in a separate respository and make sure the integration with HPX happens only on the user's machine
<hkaiser>
most secure way*
denis_blank has joined #ste||ar
<hkaiser>
ABresting: for now I think you should not worry about the implications, just please try to keep everything to your own repository (of HPX)
<ABresting>
in my opinion, issues arise when we are using someone's algorithm, but there are only one or two ways of implementing stack overflow it which has no algorithmic dependencies.
<hkaiser>
ABresting: the issues are caused by the licensing, not the copyrights
<ABresting>
yes this is going in separate HPX repo, but implementation of stack overflow handling will not take much time
<ABresting>
then it makes things even easier for us
<ABresting>
by the way can I integrate in with HPX in my open repo?
<ABresting>
In a few days from now I may want to test it with HPX also
<ABresting>
in my own*
<hkaiser>
what do you mean by 'by the way can I integrate in with HPX in my open repo?' ?
<ABresting>
jbjnr: Currently we are focused on detecting it, as we will have to go make additional performance measures when we try and increase the stack size, as this may require migrating threads code and context.
<ABresting>
hkaiser: I mean for testing purpose, as wash told me to implement it in general linux first and then we go test it in HPX.
<hkaiser>
jbjnr: created a PR for the paper
<hkaiser>
ABresting: ok, no objections
<ABresting>
Thanks :)
<hkaiser>
ABresting: the only concern I have is to avoid tainting the main repository with non-boost-licenced code
<ABresting>
yes that is why I am not creating any PR to HPX master
<hkaiser>
k
Matombo has quit [Ping timeout: 240 seconds]
<ABresting>
by the way, whatever I developing, I code it all by myself and not using any library which can taint the boost license, so is there any way it can still create problems for any organization?
<ABresting>
I am just curious here
<hkaiser>
we'll see ;)
bikineev has quit [Ping timeout: 240 seconds]
josef_k has quit [Ping timeout: 240 seconds]
<jbjnr>
hkaiser: thanks, will look in 5 mins
josef_k has joined #ste||ar
<jbjnr>
thanks hk, I'll merge in the changes one by one. cheer
<hkaiser>
also, please use the name 'detail' for the internal namespace
<pree__>
okay !. Do you understand it ??
<pree__>
please tell me !
<hkaiser>
no, sorry, I don't understand it
<hkaiser>
:/
<hkaiser>
can you describe it in two or three sentences?
<pree__>
okay
<hkaiser>
what happens when I call bulk_create? please explain it step by step
<pree__>
bulk_create API ---> It will create the " count " no:of:components on the localities assigned to the policy.
<hkaiser>
please don't try to be terse, make your description as detailed as possible
<pree__>
okay
<hkaiser>
pree__: well, I understand that
<hkaiser>
but how will the components be distributed across the localities?
<hkaiser>
maybe I misunderstand the term 'cyclic'
denis_blank has joined #ste||ar
<hkaiser>
if I read 'cyclic' I'd assume that the policy would go around the list of localities and create one component per locality until it has created the required amount
<pree__>
yeah
<hkaiser>
possibly creating more than one component per locality if the user asked to create more components than we have localities
<hkaiser>
is that what you mean by 'cyclic'?
<pree__>
Only difference is using block_size
<hkaiser>
what is block_size?
<pree__>
mininum number of components the locality should must have
<hkaiser>
pree__: that is why I'm asking you to describe in simple words what your code is supposed to be doing
<hkaiser>
ok, how do you calculate the block_size?
<hkaiser>
is that the number of components the policy should create per locality or is it the number of components which should exist on a locality before the policy starts creating things?
<pree__>
please see this link the output
<hkaiser>
or is it the number of components which should exist on a locality after the policy has created things?
<hkaiser>
pree__: please write up what you plan to do and come back once you have it written in normal words
<pree__>
No no:of:components should create per locality
<pree__>
okay sorry
<hkaiser>
pree__: I have the impression that you don't know yourself what you want to implement
<pree__>
Then please suggest me a plan or atleast guide me
<hkaiser>
pree__: I told you what I would suggest
<hkaiser>
pree__: write down in human words what you want to implement