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 quit [Ping timeout: 246 seconds]
diehlpk has quit [Ping timeout: 246 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
diehlpk has joined #ste||ar
aserio has joined #ste||ar
jaafar_ has joined #ste||ar
<aserio>
hkaiser: yt?
<hkaiser>
aserio: hey
<hkaiser>
wazzup?
<aserio>
hkaiser: lol, I have a question about serialize buffer
<hkaiser>
sure
<aserio>
if I print out &buffer and &vector (the vector that I created it from and reference to)
<aserio>
should it print the same address?
<hkaiser>
no
<aserio>
why?
<hkaiser>
it should print the same if you print v.data() and sb.data()
<aserio>
ahhh they are strucs
<aserio>
structs*
<hkaiser>
yes
jaafar has quit [Ping timeout: 260 seconds]
diehlpk has quit [Ping timeout: 240 seconds]
<aserio>
hkaiser: ok, my buffer is not pointing to the right place
<aserio>
would you have any suggestions to go about trouble shooting this?
<hkaiser>
use gdb and go step bystep through the code looking at all values
<hkaiser>
but we can look at it tomorrow together
<aserio>
ok, I will also look to see if I am initializing the constructor properly
eschnett has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
hkaiser has quit [Quit: bye]
aserio has quit [Quit: aserio]
<github>
[hpx] K-ballo force-pushed throw_with_info from 3790289 to cec67fe: https://git.io/vHKTJ
<pree>
I like to implement a look_up map for cyclic distribution policy. whether I have to go for std::unordered_map or std::map. In my case I'm only inserting and looking up elements, so i preferred unordered map. Could you please add some suggestions ?
<pree>
Thank
<pree>
* thank u all
<pree>
As the no:of:elements in unordered_map = no:of:localities assigned to the distribution policy. I hope that it will not tends to linear complexity
<pree>
So we can keep it in constant-time lookup's !
Matombo has joined #ste||ar
<zao>
pree: Unless you need the ordered traversal or have cheap op<, a std::map is seldom better than a std::unordered_map.
<zao>
It's seldom that you end up running into costly hash functions (as those are evaluated once per lookup), or costly equality tests.
<zao>
It's possible that you may have data that lends itself poorly to hashing tho, so horrible cases may occur.
<zao>
Worst thing about unordered_map tends to be to compute hashes for non-trivial keys :)
<pree>
But having a logarithmic look-up in this case may be tradeoff
<pree>
Is there any way to ensure that the lookup does not tends to linear one ? @ zao
shoshijak has joined #ste||ar
mcopik has quit [Ping timeout: 255 seconds]
Matombo has quit [Remote host closed the connection]
<heller_>
jbjnr: yt?
<jbjnr>
here
<heller_>
jbjnr: as the primary contact, should I insert me or you?
<jbjnr>
I was told it's better if CSCS are not the team leaders, but for contacts ... not sure. you chosse.
<heller_>
GPU hackathon that is
<heller_>
ok, then I'll put me first ;)
<jbjnr>
understood
david_pfander has joined #ste||ar
<zao>
pree: In some cases, linear scans in vectors "so called flat maps"might be valuable too.
<pree>
zao wait! I running with some test cases in rostam I will tell you!
<zao>
I'm in meetings all day, so have fun :)
<pree>
It seems that un_map is okay for my task :)
<pree>
for test-case un_map takes 12.6 sec for overall lookup but map takes 51.23 sec .
<zao>
jbjnr: Had anything to do with Dan Still?
<jbjnr>
not that I recall
<zao>
Ok, project lead of the nordic cloud thingiemabob project I'm doing now.
<zao>
jbjnr: Got the feeling that you know everyone :)
<jbjnr>
not this time!
<jbjnr>
heller_or zao : what would be a good reference for futures? (citation I mean)
<jbjnr>
wow 1977, though the title of the paper doesn't really tell you much!
<jbjnr>
thanks
pree has quit [Ping timeout: 240 seconds]
bikineev has joined #ste||ar
pree has joined #ste||ar
shoshijak has quit [Ping timeout: 255 seconds]
bikineev has quit [Remote host closed the connection]
Matombo has joined #ste||ar
shoshijak has joined #ste||ar
K-ballo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<heller_>
jbjnr: yeah, the title doesn't tell you much, the idea of futures is very old
hkaiser has joined #ste||ar
<jbjnr>
is the chunking in hpx serialization taken from the boost serialization or is it special to HPX? does any other library use that technique?
<hkaiser>
jbjnr: hpx specific
<jbjnr>
thanks
<jbjnr>
has it ever been writtten about before?
<hkaiser>
jbjnr: the idea of zero-copy is not new, though
<hkaiser>
I have not seen it applied for serialization purposes elsewhere
<heller_>
there are probably papers about using it within MPI
<jbjnr>
does voost::mpi use anything like that?
<jbjnr>
^boost
<heller_>
our innovation is to apply it to high level datastructures and RPC
<heller_>
jbjnr: no
<hkaiser>
jbjnr: hmm, good point, we need to look
<hkaiser>
I know they have built some special serialization support for mpi
<heller_>
yes, for bitwise copy
<hkaiser>
but it could be that they just directly map onto mpi data types
<heller_>
but not for zero copy, as far as a I am aware
<hkaiser>
right
<jbjnr>
I've used the serialization a lot - and even extended it - but I am still not 100% certain what the index chunk really does. It marks the end of a normal blob of streamed data, is that all?
<hkaiser>
jbjnr: you can't zero-copy all of the data
<jbjnr>
yes I know
<hkaiser>
so you collect chunks of zero-copy data and the rest which is put sequentially into the archive as normal
<jbjnr>
so it just is used to mark the end of a blob then
<hkaiser>
the index chunks mark the boundaries between zero-copy and non-zero-copy chunks
<jbjnr>
yup
<jbjnr>
ok ta
<hkaiser>
that allows to logically re-insert the zero-copy chunks into the de-serialization stream
<github>
[hpx] sithhell created fixing_2682 (+1 new commit): https://git.io/vHK76
<github>
hpx/fixing_2682 0ef51f0 Thomas Heller: Allowing throttling scheduler to be used without idle backoff...
<github>
[hpx] sithhell force-pushed fixing_2682 from 0ef51f0 to 0def9d4: https://git.io/vHK7X
<github>
hpx/fixing_2682 0def9d4 Thomas Heller: Allowing throttling scheduler to be used without idle backoff...
<github>
[hpx] sithhell opened pull request #2686: Allowing throttling scheduler to be used without idle backoff (master...fixing_2682) https://git.io/vHK7y
<github>
hpx/master f8e4b2f Hartmut Kaiser: Fixing a name of a configuration constant
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
david_pf_ has joined #ste||ar
<github>
[hpx] Naios opened pull request #2687: Add an is_tuple_like trait for sequenceable type detection (master...is_tuple_like) https://git.io/vH6D0
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<aserio>
hkaiser: Is there a reason that the trait has to call a function called "size()" and not a function called "size_data()"?
<hkaiser>
ahh bike-shedding...
<aserio>
hkaiser: no not bike shedding
<aserio>
I thought I could call that function what I wanted
<aserio>
one sec
<aserio>
let me show you where
<aserio>
hkaiser: ...I will create a comment on the pr
<aserio>
hkaiser: I added the comment
<hkaiser>
aserio: .size() happens to be the name of the function exposed by the wrapper object
<aserio>
so that line has to read return cont.size() for it to work?
<hkaiser>
depnds on the the name exposed by your underlying type, could be foo() for all I care
<aserio>
so if I defined foo() to return a size I could write on line 82 return cont.foo()?
<aserio>
I am running into an issue where the compiler is claiming that my object does not define a size function
<hkaiser>
aserio: well, apparently it does not expose that function, otherwise the compiler wouldn't say so
<aserio>
I thought that the trait effectively exposed that function for me
<K-ballo>
the compiler is probably right
<hkaiser>
with high probability
<aserio>
K-ballo, hkaiser: I trust the compiler :p I am questioning how traits work
<K-ballo>
that's nice, once you start doubting your compiler there's no coming back :/
eschnett has quit [Quit: eschnett]
<aserio>
The trait is supposed to provide a place to define overloads so that the library class has a proper definition of a particular function correct?
bikineev has joined #ste||ar
<hkaiser>
aserio: the functions exposed by the traits should always have the same name, however the functions you call from inside the trait can be called however you like
<aserio>
Ok, that is what I thought
<aserio>
hkaiser: I am seeing an issue when I rename the user defined function inside of the trait
<hkaiser>
difficult to tell from here
<aserio>
I renamed the function file_wrapper::size() to file_wrapper::size_data()
<hkaiser>
ok, so you need to change all spots where you callit
<aserio>
I will double double check
david_pf_ has quit [Quit: david_pf_]
<K-ballo>
hkaiser: there's a fair number of `boost::throw_exception(e)`s in the codebase.. are those for enabling boost::current_exception, or for enabling boost::enable_error_info, or both?
<hkaiser>
uhh
<hkaiser>
more for consistency, I believe
<hkaiser>
I guess mostly for current_exception
<hkaiser>
for enable_error_info we use the macros
hkaiser_ has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
<K-ballo>
I just started to get a feeling that it's mostly for current_exception, as enable_error_info is used explicitly when needed
<hkaiser_>
yes
<hkaiser_>
I agree, we use the macros if we need the error_info
<K-ballo>
in that case I should replace them with plain throw on the std::current_exception branch
<hkaiser_>
ok
jakemp has quit [Ping timeout: 260 seconds]
<K-ballo>
there's also a couple places that assume only exceptions deriving from boost::exception are ever thrown, like lcos::server::latch, that's slightly suspicious
<hkaiser_>
K-ballo: that's probably a bug
<K-ballo>
yeah, or maybe there was a genuine limitation back then when it was written
<K-ballo>
but it doesn't make much sense today
<hkaiser_>
nod
akheir has quit [Remote host closed the connection]
<aserio>
hkaiser_: I double checked, I think I changed all the mentions and all of the errors come from output_container.hpp, input_container.hpp, and serialization_access_data.hpp
<hkaiser_>
aserio: then you probably changed the traits API
<aserio>
hkaiser_: I am 90% confident I didn't touch that section in your code, It was working, I renamed it, and it broke
RostamLog has joined #ste||ar
gentryx_ has joined #ste||ar
RostamLog_ has quit [Ping timeout: 240 seconds]
hkaiser_ has quit [Ping timeout: 240 seconds]
gentryx has quit [Ping timeout: 240 seconds]
<github>
[hpx] K-ballo force-pushed compat-exception from 46373fe to e85003d: https://git.io/vH8FM