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/
<heller>
hkaiser: which toolset does not support lambda init captures? Gcc >= 4.9, clang >= 3.4, Intel >= 2015 and visual studio >= 2015
<heller>
Seem to support them
<hkaiser>
heller: that's my point
<hkaiser>
but all of them require -std=c++14 or similar to enable those
<heller>
Sure, so why not enable that by default?
<heller>
I don't see a point in having this macro at all
<hkaiser>
because that would require for everything else to be compiled that way as well
<hkaiser>
also, I think requiring c++14 features implies 100% of c++11 being supported by all compilers, not sure if that's true
<heller>
Ok, so what's the problem of just bumping the requirements?
<hkaiser>
are you sure nobody still relies on c++11 only?
<heller>
Hmm
<heller>
The people using cuda...
<hkaiser>
nod
<K-ballo>
would people have to build a C++14 enabled boost to be able to use a C++14 only HPX?
<hkaiser>
yes
<hkaiser>
not for msvc, though
<heller>
Gcc neither
<hkaiser>
ahh ok
<K-ballo>
because there is no msvc C++11 switch, or for some other reason?
<heller>
My problem is that this patch creates an illusion
<hkaiser>
K-ballo: because they kept the ABI stable over the last years
<heller>
Sure, all code that exists today will just continue to work
<hkaiser>
heller: what illusion? that for modern systems things are handled properly?
<K-ballo>
uhm, described like that I would have issues with that macro too
<heller>
hkaiser: that for example move only captures are now possible, but just for C++14
<K-ballo>
captures can be emulated properly on C++11
<heller>
That's my point, yeah
<K-ballo>
I thought the macro was being used to optionally turn some copies into moves, in context where copies were already needed anyhow
<hkaiser>
K-ballo: we've been living with copies for years now, why not improve the picture where we can?
<K-ballo>
as in, for C++11 you get 3 copies, 2 for C++14, 1 for C++17... that's acceptable
<hkaiser>
K-ballo: right, that's what thi smacro is doing
<K-ballo>
but you described it as "handled properly"
<hkaiser>
I was trying to be sarcastic
<K-ballo>
"properly" made me think of we require move only in 14, but in 11 we are just lazy and copy
<heller>
Well, we do don't allow move only element functions for the algorithms, iirc
<heller>
Currently that is
<heller>
Not sure if that changed tough
<heller>
though*
<K-ballo>
algorithms other than sequential-for_each require copyability for functions/predicates
<hkaiser>
the standard does not require for the algos to support move-only function objects, afaiu
<heller>
Ok
<heller>
Still, if we care for C++11, the proposed changes have to be redone to capture with bind/deferred_call, if we don't care, we can just bump the required version
david_pfander has quit [Remote host closed the connection]
<heller>
That's what I'm trying to say
<K-ballo>
bumping the requirement for C++14 for this seems unreasonable
<hkaiser>
heller: I disagree
david_pfander has joined #ste||ar
<hkaiser>
why do we have to redo the capture for c++11 now?
<K-ballo>
this is an improvement for both C++11 and C++14+
<hkaiser>
but it's much much more work, is it worth it?
<hkaiser>
K-ballo: also why would switching to bind/deferred_call improve things for c++14+?
<K-ballo>
that's not what I meant, but heh, actually there are reasons
<hkaiser>
ok, talk to me
<K-ballo>
no, it's orthogonal to the point at hand.. the current macro improvement, as I understand it, improves C++14 while not punishing C++11
<hkaiser>
K-ballo: right
<K-ballo>
dropping C++11 isn't better, it is much worse
<hkaiser>
I agree
<K-ballo>
so long as these changes don't change semantics nor requirements
<hkaiser>
the changes just move/forward things where possible, eliding unneeded copies
<K-ballo>
now I'm actually looking at the changes.. is decltype not an option for FWD?
<hkaiser>
K-ballo: pls elaborate, not sure what you have in mind
<K-ballo>
#define HPX_CAPTURE_FORWARD(var, type) var = std::forward<type>(var)
<K-ballo>
#define HPX_CAPTURE_FORWARD(var) var = std::forward<decltype(var)>(var)
<hkaiser>
yah, that would work, you're right
<hkaiser>
I can make that change, no problem
<heller>
So now we have to review if by using those macros, the usage requirements change ;)
<hkaiser>
feel free
<heller>
lol
<hkaiser>
I claim the changes don't change requirements
<heller>
Ok
<heller>
So, what would justify a move to C++14?
<hkaiser>
making cuda and similar systems catch up
<hkaiser>
talk to wash ;)
<K-ballo>
we have so little to win from moving to C++14
<hkaiser>
good point
<heller>
Mostly ease of implementation
<K-ballo>
how much of it?
<heller>
The init captures, for example
<hkaiser>
heller: we have never cared for that in the library itself - we were always willing to do more work in order to support a broader set of platforms
<K-ballo>
generic lambdas is the only think somewhat relevant to ease of implementation
<K-ballo>
init captures we can emulate, and when we not now we can make it so it doesn't hurt C++14 as well
<heller>
hkaiser: true, the init captures change that picture, imho ;)
<K-ballo>
variable templates, meh
<hkaiser>
but I feel it's not worth redoing the algos (and effectively obfuscate the implementation) by moving away from lambdas right now
<K-ballo>
relaxed constexpr, we don't really do much constexpr stuff
<heller>
Any library feature?
<K-ballo>
we never really care for library features, we can always reimplement those
<K-ballo>
integer_sequence is the only one that comes to mind right now
<K-ballo>
maybe exchange, that one is way underused
<hkaiser>
heller: your main point against this change is that it might open a door for possible problems down the road
<K-ballo>
oh, ok, std::shared_mutex
<heller>
hkaiser: yes
<hkaiser>
so it's the possiblility of problems on a small set of platforms
<hkaiser>
does this warrant not improving things significantly for the majority of our systems?
<heller>
I'm not saying the change itself is bad
<hkaiser>
this change does not hurt in any way, mind you
<heller>
We'll see if it backfires eventually
<heller>
If it does, we have plenty of options
<hkaiser>
shrug, I think it's better to make a decision (even if its wrong) than to make no decision
<heller>
I think the decision you propose is contradicting with the statement that we care for all our supported platforms equally. You disagree and that's fine. I perfectly understand that it doesn't hurt C++11 only platforms right now
<heller>
And they'll die out soon enough
<K-ballo>
we don't care for all our supported platforms equally
<heller>
True
<heller>
hkaiser: clang cuda works with c++14 btw, so does nvcc 9
<heller>
Anyway, I concur that it does improve the situation. Since you guys insist that the macros won't hurt, I'm fine. Phasing out c++11 should still be on our radar,
aserio has joined #ste||ar
<heller>
In the past, those compatibility macros hurt more than they gained though. Boost.move was one example, but sure, this is not to the same extent
<hkaiser>
heller: hmmm, why do you think those macros have hurt? they have provided a valid migration path after all - later on they've been made obsolete and have been removed
<heller>
hkaiser: I remember that differently ;)
<hkaiser>
ok
<hkaiser>
fair enough
<hkaiser>
gtg
hkaiser has quit [Quit: bye]
<heller>
It looked like a good thing but caused all sorts of problems
<K-ballo>
the Boost.Move macros were the worst
<K-ballo>
we never really did support both non-moves and moves at the same time
RostamLog has joined #ste||ar
<K-ballo>
but merits the question, are we doing C++11 builds on CI?
hkaiser has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 252 seconds]
daissgr has joined #ste||ar
taeguk has joined #ste||ar
aserio1 has quit [Ping timeout: 252 seconds]
<taeguk>
Hi, everyone :)
aserio has joined #ste||ar
<hkaiser>
hey taeguk, Happy New Year
taeguk has quit [Ping timeout: 260 seconds]
daissgr has quit [Ping timeout: 252 seconds]
<heller>
K-ballo: no, if I'm not mistaking, we don't do any c++11 builds at all
daissgr has joined #ste||ar
<hkaiser>
heller: the windows builder is doing c++11, at least it does not enable anything else
bibek has joined #ste||ar
david_pfander has quit [Ping timeout: 248 seconds]
<heller>
hkaiser: ahh, isn't msvc using the latest available by default?
<hkaiser>
don't think so
<K-ballo>
msvc uses a mix of 14/17 by default, not latest.. but IIRC we don't enable any 14/17 features unless there's an explicit -DHPX_WITH argument
<heller>
Ok
<heller>
Speaking of features... Aren't template class deductions 14?
<K-ballo>
what is "template class deductions"?
hkaiser has quit [Quit: bye]
<K-ballo>
Class Template Argument Deduction? 17
aserio has quit [Ping timeout: 248 seconds]
<heller>
Er, yes
<heller>
17, ok
<heller>
So 17 will bring quite some helpful stuff
jaafar has joined #ste||ar
aserio has joined #ste||ar
hkaiser has joined #ste||ar
jaafar_ has joined #ste||ar
jaafar has quit [Ping timeout: 252 seconds]
vamatya has joined #ste||ar
jbjnr has joined #ste||ar
diehlpk has quit [Ping timeout: 264 seconds]
aserio has quit [Ping timeout: 260 seconds]
aserio has joined #ste||ar
mcopik has joined #ste||ar
diehlpk has joined #ste||ar
Smasher has joined #ste||ar
parsa has joined #ste||ar
rtohid has joined #ste||ar
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
<aserio>
hkaiser: yt?
<hkaiser>
aserio: here
<aserio>
hkaiser: it is not picking the right overload
<aserio>
hkaiser: hpx::components::client_base<Client, Server> && c
<aserio>
should give me arbitrary clients right?
<hkaiser>
aserio: that's an rvalue ref
<hkaiser>
not a forwarding ref
<aserio>
I am moving it into the function
<hkaiser>
you either need an overload taking client_base<...> const& or just one overload taking it by value
<hkaiser>
ahh
<hkaiser>
well, then I need to see the code
<aserio>
lol
<aserio>
Should I wait until Monday or would you like a gist