K-ballo 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/
<K-ballo>
(and as long as its not an interface we need to conform to, I'd very much prefer separate advance distance and advance to sentinel overloads)
<hkaiser>
nod
<hkaiser>
it was my fault to name it advance_to_sentinel, wasn't aware of the std facility
<gonidelis[m]>
so we just sentinels support for both advance_dist and advance_sent (this already supports sentinels actually) and we are set
<gonidelis[m]>
a bit of parts moving and renaming, a couple of additions and we are set
<hkaiser>
ok
<K-ballo>
only advance to sentinel needs support for sentinels
<K-ballo>
a distance is not (generally) a sentinel
<hkaiser>
K-ballo: distance should work with an iterator and a sentinel
<K-ballo>
advance distance, advance(it, dist), not distance(first, last)
<gonidelis[m]>
i may as well add the (iter, n, sent) overload to advance_sent and we have all we want
<hkaiser>
nod
<gonidelis[m]>
K-ballo: what? why?
<K-ballo>
what why what?
<gonidelis[m]>
what's your suggestion on distance(first, last)? should it support sentinels?
<K-ballo>
I have no suggestion for distance(first, last)
<gonidelis[m]>
i lost your point somewhere within your commas
<gonidelis[m]>
<K-ballo "advance distance, advance(it, di"> use a verb or two
<K-ballo>
advance distance operates on distances, not sentinels
<gonidelis[m]>
so you suggest i remove the deref op
<K-ballo>
that's talking about the Value thing in the Sentinel thing
<K-ballo>
as in the value of a sentinel
<K-ballo>
if you keep looking at the logs, you may find three or more other occurences of me saying this mythical "sentinel value" that compares against values instead of iterators is not a thing
<gonidelis[m]>
so you suggest i remove the deref op
<gonidelis[m]>
?
<K-ballo>
I wouldn't know, what's the deref op doing there? why did you add it?
<gonidelis[m]>
> 3) Increments given iterator i for n times, or until i == bound, whichever comes first.
<gonidelis[m]>
i wanted to check if i == bond
<gonidelis[m]>
i != bond ^^
<K-ballo>
then why check *i == bond?
<gonidelis[m]>
hm
<K-ballo>
if for some reason you actually mean it, then you are missing some extra concept check
<gonidelis[m]>
what does bond include?
<K-ballo>
include, as in?
<K-ballo>
what values can it take? what types can model it?
<gonidelis[m]>
i mean, it's a sentinel ok. but i expect it to represent a value
<K-ballo>
a sentinel represents a sentinel
<K-ballo>
what does it mean for a sentinel to represent a value?
<gonidelis[m]>
that it's not a distance or an end iterator
<K-ballo>
an end iterator is a sentinel
<gonidelis[m]>
i know
<gonidelis[m]>
i want this sentinel to represent i value
<K-ballo>
you haven't yet said what it means for a sentinel to represent a value
<gonidelis[m]>
i think that's what the ref says for the (3) next overload at least
<K-ballo>
which (3) is that?
<gonidelis[m]>
<K-ballo "you haven't yet said what it mea"> it's an int or sth
<K-ballo>
you are trying to dereference an end iterator
<K-ballo>
end iterators are not dereferenceable
<gonidelis[m]>
shit
<gonidelis[m]>
do we have a TEST macro facility for iterators? seems like HPX_TEST_EQ won't accept my undereferenced iters
<K-ballo>
probably just HPX_TEST(it == other_it)
<gonidelis[m]>
yup
<gonidelis[m]>
just run it
<gonidelis[m]>
thanks
<gonidelis[m]>
i think i did it (well except for the size_t typecast thingy)
<K-ballo>
HPX_TEST_EQ(a, b) will try to print both `a` and `b`
<gonidelis[m]>
yeah that's what it says
<gonidelis[m]>
"no good << op for these things you throw to me"
<gonidelis[m]>
or something like that
<gonidelis[m]>
K-ballo: i pinged you on the pr
<gonidelis[m]>
just in order to show the whole impl
<hkaiser>
yah, our current detail::distance is not quite right as it doesn't return a signed integral
<srinivasyadav227>
hkaiser: would datapar be supported in future or would be deprecated?, i have made some changes to datapar locally, and i need to re-build locally since there no tests, if we would continue to provide datapar support, writing some tests would be better?
<srinivasyadav227>
hkaiser: and regarding gsoc Seperate datapar(#5157) would be no more available right (after seperating the is_vectorpack_policy)?
<hkaiser>
srinivasyadav227: it all depends whether we can get decent performance
<hkaiser>
but in any case, tests are important, how would you know otherwise that things actually work?
<hkaiser>
srinivasyadav227: the separation of datapar is stil something to be done, might not be a full project, though, rather something that could be done while you go
K-ballo has quit [Quit: K-ballo]
<srinivasyadav227>
hkaiser: ok first i will focus on datapar changes and performance improvements, and write some tests
<hkaiser>
srinivasyadav227: also, we do have some datapar tests
<hkaiser>
srinivasyadav227: sorry for being confusing
<hkaiser>
what I meant was that we currently use Vc, but std::simd would be very similar
<srinivasyadav227>
yes yes, i was confused because std::simd came later and would support only for gcc now, and it wasnt present when datapar was built
<hkaiser>
the difference between datapar and unseq is that datapar uses simd for vectorization, while unseq leaves the vectorization to the compiler
<hkaiser>
I meant datapar and par_unseq, same is true for dataseq and unseq
<hkaiser>
anyways, gtg
<srinivasyadav227>
hkaiser: ok, np
hkaiser has quit [Quit: bye]
<gonidelis[m]>
k-ballo: i haven't done a review before so I just did it last night and did not publish it as a comment
<gonidelis[m]>
you should have a notifcation on github now
<peltonp1>
im still strugling to configure hpx to be able to co_await a future
<peltonp1>
but I get an error from the compilation test of the coroutines
<peltonp1>
HPX_WITH_CXX20_COROUTINES - Failed
<peltonp1>
Im using gcc-trunk and the error is due to unhandled exception
<zao>
Tangential, but be careful with using ~ in the middle of command line arguments, shells are only really guaranteeing expansion at the very start of an argument, $HOME is way more reliable.
<jedi18[m]>
Nevermind I should have written better tests and tested edge cases, it's failing locally now that I've updated the tests
<ms[m]>
peltonp1: you might want to wait for hkaiser to be online (usually comes online in a few hours latest, he's in the us) and ask him for more details, but it's very possible that the feature test is simply outdated
<ms[m]>
the coroutines support in hpx is experimental at best, and not tested, but should be possible to get working again
<ms[m]>
...without much effort
<ms[m]>
as far as I know you're doing everything right (i.e. the feature check should just detect if coroutines are supported)
<peltonp1>
ok, thanks. I will try to proceed by creating the futures manually for now. The syntax just shown in the cppcon 19 slides of Kaiser is just much nicer and I was wondering if I could already use it
<jedi18[m]>
first is incremented and then later passed to the the segmented_minormax (which was why if the first element is the minimum, it wasn't getting the right answer). I guess this bug was never caught as there were no tests
K-ballo has joined #ste||ar
<gonidelis[m]>
K-ballo: proxy iterators rock!
<K-ballo>
sure
hkaiser has joined #ste||ar
<gonidelis[m]>
K-ballo: is this valid code ? `const ValueType<I> & val = *iterator`
<K-ballo>
sure
<gonidelis[m]>
so niebler says "_there is no “true-reference” requirement on the return type of *it_"
<gonidelis[m]>
what does he mean "true-reference"
<gonidelis[m]>
I mean why is there any doubt that this could work?
<zao>
Allowing things like the gosh-darned vector<bool> things?
<gonidelis[m]>
zao: yeah that's what the article is about
<K-ballo>
if iterator doesn't have a true reference type, your const ref will bind to a temporary instead
<K-ballo>
make your reference non-const, and then you are onto something
<gonidelis[m]>
So the suggestion is that we should not restrict ourselves from allowing proxy iterators to bind to const refs?
<gonidelis[m]>
K-ballo: oh ok. so it's "ok" for a constref to bind to a temporary, but it's bad for a non-const ref to bind to a temporary... and that's because?
<gonidelis[m]>
ahh because it's a temporary? and the ref being non-const treats it as a not-temporary? sth like that!!
<gonidelis[m]>
non-temporary^^
<gonidelis[m]>
huh
<K-ballo>
if the non-const ref bound to the temporary, you would be allowed to modify yet the container would not be touched
<K-ballo>
the const ref bound to the temporary cannot be modified, so you can't tell you aren't actually referencing to the container
<K-ballo>
(you can tell, just not in that obvious way)
<gonidelis[m]>
the container would not be touched?
K-ballo1 has joined #ste||ar
<gonidelis[m]>
K-ballo1: the container would not be touched because it's a temporary?
<K-ballo1>
think about it for a bit
<K-ballo1>
what should *iter = false; do, if it compiled
<gonidelis[m]>
I am seriously considering opening a chmpaign bottle. It's the first time in 9 months that a conversation of ours has reached to a concluding end! K-ballo Thanks!!
<K-ballo>
some thinking required
<gonidelis[m]>
wow... that ref is bad yeah. it does not even work as a ref ;p
<gonidelis[m]>
K-ballo: Thanks a anyways. I know your explanations are stoic on purpose
<gonidelis[m]>
wow just amazing
<srinivasyadav227>
you both are amazing ;;))))
<gonidelis[m]>
I think the community has already concluded on stop using vector<bool> but it was worth the trip, I guess
<gonidelis[m]>
freenode_srinivasyadav227[m]: lol
<srinivasyadav227>
gonidelis[m]: btw, what happend to zoom meeting for GSoC? are there any plans for it soon? (suggested by diehlpk_work few days back,)
hkaiser has joined #ste||ar
<gonidelis[m]>
freenode_srinivasyadav227[m]: It's the first time that I am hearing about a GSoC zoom meeting. Could you share the log just to give me some context
<gonidelis[m]>
?
<diehlpk_work>
srinivasyadav227, we do not have the capacity to attend the Zoom meeting and advertise our group in India
<diehlpk_work>
We normally got more student's applications as we can handle.
<diehlpk_work>
Last year we had over 25 and we can not handle this amount of students as a smaller or
<diehlpk_work>
*organization
<srinivasyadav227>
diehlpk_work: oh ok,, no problem
<srinivasyadav227>
this time we have less 5 students i guess
<diehlpk_work>
We will see
<srinivasyadav227>
ok ;)
<hkaiser>
srinivasyadav227: students usually show up during the last week before the deadline
<hkaiser>
gonidelis[m]: see pm, pls
<srinivasyadav227>
hkaiser: oh alright
<gonidelis[m]>
hkaiser: i have no pms
<hkaiser>
now
<srinivasyadav227>
hkaiser: i have couple of questions regarding unseq, shall i paste in gist and share?
<hkaiser>
srinivasyadav227: you got your answer written down, what is it you need to know additionally?
<srinivasyadav227>
its gcc implementation right,? but for other compilers would it be different?
<srinivasyadav227>
i mean would the code become compiler dependent?
<srinivasyadav227>
hkaiser: and for vectorization for unseq could we make use of omp simd?
<K-ballo>
vector<bool> is universally accepted as a design mistake, but there are other less unreasonable proxy iterators, like zip_iterator
<gonidelis[m]>
K-ballo: proxy iterators are good, vector<bool> isn't
<K-ballo>
proxy iterators are known to be just the limitations of the iterator model
<K-ballo>
there was an alternative iterator design, by dave abrahams, that got accepted into TR1 but removed at the next meeting
<K-ballo>
proxy iterators are the viable hack we got to patch that other hack over that other design mistake, and they'll have to do until we can come up with a proper design
<srinivasyadav227>
hkaiser: yes, i am working on them, would provides changes soon
<hkaiser>
nice!
<srinivasyadav227>
hkaiser: i guess first i would finish the datapar stuff completely then move onto unseq
<hkaiser>
yes, sounds good
Ri2Raj has joined #ste||ar
<Ri2Raj>
Hello everyone so finally I built hpx from source and now I'm moving forward with the terminologies as mentioned in the docs
<Ri2Raj>
So for the next step should I start with the examples in the docs
Ri2Raj has quit [Quit: Connection closed]
NO_name_sorry has joined #ste||ar
nanmiao has joined #ste||ar
bita_ has joined #ste||ar
bita_ has quit [Ping timeout: 240 seconds]
bita has joined #ste||ar
<gonidelis[m]>
@Ri2Raj that would benefit you, yes
NO_name_sorry has quit [Quit: Connection closed]
Ri2Raj has joined #ste||ar
<gonidelis[m]>
Ri2Raj: that would benefit you, yes
<Ri2Raj>
Okay So basically I was reading through the project ideas and found the idea "To implement Coroutine-like Interface " to be interesting so I reseached a bit about corountines, concurrency,asynchronous code and finally implemented a corountine in C++ using the principle of Duff's Device
<Ri2Raj>
So I was saying if someone could just go through my code and see if it's going well
<Ri2Raj>
So should I create an issue in github and ask someone to rectify the code
<srinivasyadav227>
hkaiser: could you please retrigger #5235
<hkaiser>
srinivasyadav227: done
<srinivasyadav227>
hkaiser: thanks ;)
<Ri2Raj>
hkaiser
<hkaiser>
Ri2Raj: here
<Ri2Raj>
Okay
<Ri2Raj>
wait a sec
<hkaiser>
the coroutines project is something where we don't really know yet what we want ;-)
<Ri2Raj>
int range(int a, int b)
<Ri2Raj>
{
<Ri2Raj>
static long long int i;
<Ri2Raj>
static int state = 0;
<Ri2Raj>
switch (state)
<Ri2Raj>
{
<Ri2Raj>
case 0: /* start of function */
<Ri2Raj>
state = 1;
<Ri2Raj>
for (i = a; i < b; i++)
<Ri2Raj>
{
<Ri2Raj>
return i;
<Ri2Raj>
/* Returns control */
<Ri2Raj>
case 1:; /* resume control straight
<Ri2Raj>
after the return */
<Ri2Raj>
}
<Ri2Raj>
}
<Ri2Raj>
state = 0;
<Ri2Raj>
return 0;
<hkaiser>
Ri2Raj: please don't paste code here
<hkaiser>
put it in a gist or similar and give us the link
<hkaiser>
K-ballo: strange that google docs link doesn't show me any code, just a list of files in my drive
<K-ballo>
nah, the link is bogus, I meant the one above the link
<hkaiser>
ahh
<sestro[m]>
Hi, when using the OTF2 output of APEX with HPX I randomly get errors of the type `[OTF2] src/otf2_archive_int.c:1108: error: Unknown error code: Couldn't create directories on root.` during startup and then APEX hangs when writing the output archive during shutdown. Has anybody seen this before?
<hkaiser>
sestro[m]: send a mail to Kevin Huck <khuck@cs.uoregon.edu>, please