Re: Please support Coroutines TS in C++
(repeated, forgot to reply to mailing list)
Xi Ruoyao misses completely the point!
The amount of error prone boilerplate code, that the programmer would
have to write, is huge. See examples in the excellent presentation
"C++ coroutines: a negative overhead abstraction"
https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead-abstraction
Video: https://www.youtube.com/watch?v=_fu0gx-xseY
What one can have with a coroutine library, are stackfull coroutines.
But they are not really useful. Not very scalable. The simplification
of programming has a high cost.
With stackless coroutines, one can combine the simplicity of
sequential programming, with the scalability and efficiency of
asynchronous programming.
Did you ever read Linux kernel code? There is a lot of hand written
code that tries to achieve a sequence of actions using chained
callbacks:
void A()
{
a1();
when event E1 happens, run B
}
void B()
{
b1();
when event E2 happends, run C
}
void C()
{
c1()
}
with Coroutines TS this is turned into
void A()
{
a1();
co_await E1;
b1();
co_await E2;
c1();
}
but have the same efficiency and scalability of asynchronous code.
On Sat, Aug 19, 2017 at 5:49 PM, Jonathan Wakely wrote:
> See the thread on gcc-help:
> https://gcc.gnu.org/ml/gcc-help/2017-08/msg00045.html
>
>
>
> On 19 August 2017 at 14:09, Ramón García wrote:
>> ping.
>>
>> On Tue, Aug 15, 2017 at 2:21 PM, Ramón García
>> wrote:
>>> Hello,
>>>
>>> Please consider supporting the Coroutines TS in GNU C++.
>>>
>>> It is really important to make asynchronous programming usable.
>>>
>>> Modern programs should be scalable to use the performance of multicore
>>> processors. Stackless coroutines allow the programmer to scale to
>>> millions of asynchronous requests. But without the primitives in the
>>> Concurrency TS, chaining the result of an asynchronous computation to
>>> the next step, one must program a chain of callbacks. It becomes
>>> quickly unusable.
>>>
>>> The promise/future, as specified in the concurrency TS, (that is, with
>>> the function future::then for chaining a callback to the completion of
>>> the future) make asynchronous programming somewhat more usable.
>>> Unfortunately, almost no C++ library shipped supports future with
>>> then.
>>>
>>> This is an excellent explanation of the Coroutines TS:
>>>
>>> https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead-abstraction
>>>
>>> Both Visual C++ 2017 and CLANG (SVN version) support the Coroutines
>>> TS. Please consider it.
>>>
>>> I saw that someone started an attempt at implementing it:
>>> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00435.html but there
>>> were no replies.
can we rename vec<>.safe_push() to vec<>.push()?
I understand the need for .quick_push(), when we know the size of the allocated elements before hand, but do we really need to call the common variant safe_push? Can't we just call it push()? Or is there some magic C++ rule/idiom that prohibits us from doing this? I volunteer to provide a patch if y'all agree. Aldy
Re: can we rename vec<>.safe_push() to vec<>.push()?
On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote: > I understand the need for .quick_push(), when we know the size of the > allocated elements before hand, but do we really need to call the > common variant safe_push? Can't we just call it push()? > > Or is there some magic C++ rule/idiom that prohibits us from doing this? > > I volunteer to provide a patch if y'all agree. I think having quick_push and safe_push makes you think which one to use while push would be the obvious lazy one. Aka nobody thinks of pre-allocating stuff and using quick_push anymore. Just my 2 cents... Richard. > Aldy
Re: can we rename vec<>.safe_push() to vec<>.push()?
So ok to default to a lazy one, or are suggesting we leave things as they are? Aldy On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener wrote: > On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote: >> I understand the need for .quick_push(), when we know the size of the >> allocated elements before hand, but do we really need to call the >> common variant safe_push? Can't we just call it push()? >> >> Or is there some magic C++ rule/idiom that prohibits us from doing this? >> >> I volunteer to provide a patch if y'all agree. > > I think having quick_push and safe_push makes you think which one to use > while push would be the obvious lazy one. Aka nobody thinks of pre-allocating > stuff and using quick_push anymore. > > Just my 2 cents... > > Richard. > >> Aldy
Re: can we rename vec<>.safe_push() to vec<>.push()?
On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez wrote: > So ok to default to a lazy one, or are suggesting we leave things > as they are? Either leave as-is or default to the lazy one. Richard. > Aldy > > On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener > wrote: >> On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote: >>> I understand the need for .quick_push(), when we know the size of the >>> allocated elements before hand, but do we really need to call the >>> common variant safe_push? Can't we just call it push()? >>> >>> Or is there some magic C++ rule/idiom that prohibits us from doing this? >>> >>> I volunteer to provide a patch if y'all agree. >> >> I think having quick_push and safe_push makes you think which one to use >> while push would be the obvious lazy one. Aka nobody thinks of >> pre-allocating >> stuff and using quick_push anymore. >> >> Just my 2 cents... >> >> Richard. >> >>> Aldy
Re: can we rename vec<>.safe_push() to vec<>.push()?
On 08/31/2017 07:49 AM, Richard Biener wrote: On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez wrote: So ok to default to a lazy one, or are suggesting we leave things as they are? Either leave as-is or default to the lazy one. Agreed. -- Nathan Sidwell
Re: gcc torture test pr52286.c
Paul S schrieb:
I've ported gcc to a 16 bit CPU and have all torture tests passing bar
one, pr52286.c
The offending lines of code are
long a, b = 0;
asm ("" : "=r" (a) : "0" (0));
which should cause zero to be assigned to the "a" SI sized variable.
Inspecting the generated code revealed that zero was only being assigned
to the lower 16 bit half of "a".
ldr2,0
I changed the inline asm statement to
asm ("" : "=r" (a) : "0" (0L));
(note the change 0 to 0L) which caused the correct code to be generated ...
ldr2,0
ldr3,0
Curious, I performed an RTL dump and found that without the trailing 'L'
following the '0' the output of the expand pass looks like this ...
(insn 6 5 7 2 (set (reg:SI 29 [ a ])
(asm_operands:SI ("") ("=r") 0 [
(reg:HI 30)
]
[
(asm_input:HI ("0")
../gcc/testsuite/gcc.c-torture/execute/pr52286.c:14)
]
compared to
(insn 6 5 7 2 (set (reg:SI 29 [ a ])
(asm_operands:SI ("") ("=r") 0 [
(reg:SI 30)
]
[
(asm_input:SI ("0")
../gcc/testsuite/gcc.c-torture/execute/pr52286.c:14)
]
when 0L is used instead of just 0.
so it seems that the "0" constraint on the input operand is affecting
the inferred mode of the output register operand ?
The 0 will we word_mode, presumably HImode on your machine, whereas
0L is long (obviously SImode on your machine).
The "0" constraint only tells the register allocator to use the same
reg, hence if you use (int)0 and ar eon littel endian, only the
lower 2 bytes will be set and the upper 2 bytes undefined.
Am I reading this correctly or have I missed something ?
Thanks, Paul
No, there are many test cases that are just dumped into the test
suite without proper review, so you can expect fallout when you
target has 16-bit int.
Johann
Re: can we rename vec<>.safe_push() to vec<>.push()?
Richard Biener writes: > On Thu, Aug 31, 2017 at 1:41 PM, Aldy Hernandez wrote: >> So ok to default to a lazy one, or are suggesting we leave things >> as they are? > > Either leave as-is or default to the lazy one. FWIW, I think we should leave it. The risk isn't just laziness: it could make quick_push sound more like a niche operation for special cases, rather than the one we want to use where possible. Like you say, it's useful to force people to make the choice. It's like forcing the choice between ordered_remove and unordered_remove (which I think we should keep too). Thanks, Richard > > Richard. > >> Aldy >> >> On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener >> wrote: >>> On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote: I understand the need for .quick_push(), when we know the size of the allocated elements before hand, but do we really need to call the common variant safe_push? Can't we just call it push()? Or is there some magic C++ rule/idiom that prohibits us from doing this? I volunteer to provide a patch if y'all agree. >>> >>> I think having quick_push and safe_push makes you think which one to use >>> while push would be the obvious lazy one. Aka nobody thinks of >>> pre-allocating >>> stuff and using quick_push anymore. >>> >>> Just my 2 cents... >>> >>> Richard. >>> Aldy
gcc-7-20170831 is now available
Snapshot gcc-7-20170831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 251576 You'll find: gcc-7-20170831.tar.xzComplete GCC SHA256=39b76c2a678cf4e0b275eceb7a03b89f2dd0788bc48774e5df2ff65492dde0ac SHA1=34357beb7a07858e1f64177355b9dd5016e2d6ae Diffs from 7-20170824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
