nanmiao11 has quit [Remote host closed the connection]
bita_ has quit [Ping timeout: 260 seconds]
jbjnr has joined #ste||ar
kale[m] has joined #ste||ar
kale[m] has quit [Read error: Connection reset by peer]
kale[m] has joined #ste||ar
k-ballo[m] has left #ste||ar ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
akheir has quit [Quit: Leaving]
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
hkaiser has joined #ste||ar
nanmiao11 has joined #ste||ar
karame_ has joined #ste||ar
<gnikunj[m]>
hkaiser: FTXS deadline extended by 1 week. Scott emailed me informing about the change.
<gnikunj[m]>
we have another week to try and show results on a benchmark.
kale[m] has quit [Ping timeout: 240 seconds]
weilewei has quit [Remote host closed the connection]
kale[m] has joined #ste||ar
weilewei has joined #ste||ar
<hkaiser>
gnikunj[m]: nice!
<gnikunj[m]>
hkaiser: btw I have mostly polished the current version. Don't think there is any theoretical change anymore, more like structural changes here and there.
<gnikunj[m]>
I'd say its more like a pre-final draft
<hkaiser>
yes, looks good so far, I'll do a once over soon
<gonidelis[m]>
hkaiser: sorro for the overshigtes
<gonidelis[m]>
I guess I was caught up in the process
<hkaiser>
gonidelis[m]: np at all
<gonidelis[m]>
pretty bad mistakes
<gonidelis[m]>
I ll fix them asap
karame_ has quit [Remote host closed the connection]
bita_ has joined #ste||ar
nanmiao11 has quit [Remote host closed the connection]
weilewei has quit [Remote host closed the connection]
nanmiao11 has joined #ste||ar
jaafar has joined #ste||ar
<gnikunj[m]>
hkaiser: yt?
<hkaiser>
here
<gnikunj[m]>
hkaiser: If I pass a custom class to a channel, does the custom class requires to have a default constructor?
<gnikunj[m]>
I'm getting this error when trying to compile the code: /work/ngupta/src/hpx/libs/serialization/include/hpx/serialization/detail/non_default_constructible.hpp:26:9: error: no matching function for call to 'partition_data::partition_data()'
<hkaiser>
yes, that's because serialization requires default-constructible types
<gnikunj[m]>
aah, ok. Adding a default constructor won't add any adverse effects to the code right?
<hkaiser>
no, if you can sensibly initialize your type
<gnikunj[m]>
well its working without having one, so I'm sure I'm not doing anything wrong with the code. I'll add a default constructor then. Thanks!
<gnikunj[m]>
hkaiser: if I'm adding a custom class to a channel, is there anything specific I need to do other than to make the custom class serializable? I'm getting weird link time errors
<hkaiser>
if you type is serializable things should be fine
<hkaiser>
*your*
<gnikunj[m]>
this is the type of link time error I'm getting: 1d_stencil_replay_distributed.cpp:(.text._ZNK3hpx7actions20transfer_base_actionINS_4lcos6server7channelI14partition_dataS5_E21set_generation_actionEE18get_component_typeEv[_ZNK3hpx7actions20transfer_base_actionINS_4lcos6server7channelI14partition_dataS5_E21set_generation_actionEE18get_component_typeEv]+0x1): undefined reference to
<gnikunj[m]>
freenode_gonidelis[m]: you don't need ranges to get that functionality
<K-ballo>
that's been available since C++11
<gonidelis[m]>
cool
<gonidelis[m]>
ranges are more likely bounded to the algos, right?
<K-ballo>
bounded?
<gonidelis[m]>
I mean, their functionallity won't be that visible if you don't apply sth on your range.
<gonidelis[m]>
It's not just that they remove the iterator constraint
<K-ballo>
apply?
<gonidelis[m]>
yeah, an algo
<K-ballo>
I don't understand what the underlying question is
<gonidelis[m]>
Do ranges help us get rid of the iterators?
<gonidelis[m]>
probably no... we had gotten rid of iterators before ranges were introduced (since C++11 as you mentioned above_
<gonidelis[m]>
)
<gonidelis[m]>
*
<K-ballo>
we haven't gotten rid of iterators
<K-ballo>
nor we want to
<gonidelis[m]>
well I didn't have to use them in the code that I sent you
<gnikunj[m]>
freenode_gonidelis[m]: I think you're confusing between what ranges do vs what range based for loops do
<K-ballo>
but yes, the main facility a range library brings is the ability to pass `rng` instead of `rng.begin(), rng.end()` when we want to operate on an entire range
<gonidelis[m]>
thus we are certainly more relaxed
<K-ballo>
the code that you sent does use iterators, you just don't see them
<gonidelis[m]>
freenode_gnikunj[m]: yeah could be that ;/
<gonidelis[m]>
are c++20 ranges useful whithout using the `views::` thing
<gonidelis[m]>
?
<gonidelis[m]>
plus
<gonidelis[m]>
Is there some iterator-based way to apply the sentinel functionallity in a container?
<gnikunj[m]>
hkaiser: what is the general cause for "this future has no valid shared state: HPX(no_state):" error?
<gnikunj[m]>
I haven't called a get on it twice
<hkaiser>
then it's not initialized, or you have called .then()
<hkaiser>
.then() invalidates it as well
<gnikunj[m]>
I have called .then on it, yes
<K-ballo>
gonidelis[m]: containers have sentinels already: .end()
<gonidelis[m]>
what if I want some middle value randomly placed inside my container that satisfies a predicate to be my stentinel K-ballo
<gonidelis[m]>
?
<K-ballo>
what then? you just do it
<K-ballo>
there's nothing special about containers there
<gonidelis[m]>
could I do it before c++20 ranges?
<gonidelis[m]>
using iterators?
<gonidelis[m]>
K-ballo:
<K-ballo>
yes, at a much higher cost
<gnikunj[m]>
hkaiser: how do I get the result if I'm attaching a continuation to a future using .then() and calling get on the new future?
<K-ballo>
given an iterator type and a sentinel type, you can always create a new iterator type that's either one or the other
<hkaiser>
the new future (returned from then) gives you whatever the continuation returns
<gnikunj[m]>
it is giving no valid state error
<gonidelis[m]>
K-ballo: ok I am a little confused... so bottom line: do c++20 ranges facilitate this whole process of "much higher cost" ?
<hkaiser>
gnikunj[m]: you might have swallowed an exception
<K-ballo>
yes, a sentinel is by any metric you choose "cheaper" than an iterator that's a union of another iterator and a sentinel
<gnikunj[m]>
hkaiser: crap, copy paste error
<gonidelis[m]>
K-ballo: bravo ranges then!
<gnikunj[m]>
why is it always a stupid copy paste error :/
<hkaiser>
lol
<gnikunj[m]>
for a moment I was questioning my understanding of futures :|
<gonidelis[m]>
hkaiser: sorry for not handling the errors on my PR yet, it's just that I want to complete this blogpost and I am trying to make it a little reader-friendly....
<hkaiser>
gonidelis[m]: take your time
<hkaiser>
no rush
<gnikunj[m]>
hkaiser: I have better errors to work with now. Segmentation fault ;-)
kale[m] has joined #ste||ar
<jbjnr>
hkaiser, just running benchmarks on your synchronization branch now. Will get results in morning.
<hkaiser>
jbjnr: thanks a lot!
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
jbjnr has quit [Ping timeout: 240 seconds]
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
<gnikunj[m]>
hkaiser: some good news. At least now we're not in 8s and 300s category. I was able to scale things down to 28s and 44s w/wo distributed resilience. All the overheads are due to network bandwidth really, but we can't do much about it.
<gnikunj[m]>
I'll play around more in the morning to see if I can get it lower further