Re: Please support Coroutines TS in C++
ping
On Thu, Aug 31, 2017 at 11:22 AM, Ramón García wrote:
> (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.
Re: -ffunction-sections and -fdata-sections documentation
On 13/10/17 09:06, Sebastian Huber wrote:
> Hello,
>
> I would like to update the documentation of these compiler flags and
> have some questions. The -ffunction-sections and -fdata-sections
> documentation is currently:
>
> Do these options affect the code generation?
>
-fdata-sections certainly can affect code generation on some targets.
Testing with this sample, using gcc 6.3 for the ARM with -O2:
int a, b, c;
void foo(void) {
a = 1;
b = 1;
c = 1;
}
Generated assembly code is:
foo():
mov r2, #1
ldr r3, .L2
str r2, [r3]
str r2, [r3, #4]
str r2, [r3, #8]
bx lr
.L2:
.word .LANCHOR0
With -fdata-section, you get:
foo():
mov r3, #1
ldr r0, .L2
ldr r1, .L2+4
ldr r2, .L2+8
str r3, [r0]
str r3, [r1]
str r3, [r2]
bx lr
.L2:
.word .LANCHOR0
.word .LANCHOR1
.word .LANCHOR2
I only realised this recently, but it can make a significant difference
on targets that don't use direct addressing modes (such as ARM). It is
maybe worth mentioning this in any changes to the gcc documentation.
Re: Questions about a patch fixing bug #61414
On Mon, Oct 16, 2017 at 01:06:04AM +0100, Jonathan Wakely wrote:
> On 14 October 2017 at 17:19, Sam van Kampen via gcc wrote:
> > On Sat, Oct 14, 2017 at 04:43:33PM +0100, Jonathan Wakely wrote:
> >> On 14 October 2017 at 15:50, Sam van Kampen wrote:
> >> > Dear maintainers,
> >> >
> >> > Having come across https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
> >> > (bug #61414) quite often myself I decided I wanted to fix it.
> >> >
> >> > By reading through parts of the GCC internals manual I have
> >> > managed to add a warning flag, the code for which I will submit to
> >> > gcc-patches, but since this is my first time contributing to GCC I have
> >> > some questions.
> >> >
> >> > 1. When it comes to the patch, should I post it to the bug tracker
> >> >before sending it to gcc-patches?
> >>
> >> No. Patches go to the mailing list, not bugzilla.
> >>
> >> But you can add the URL of the gcc-patches mail to bugzilla (and then
> >> somebody should add the "patch" keyword to the bug).
> >
> > Noted.
> >
> >> > 2. A better fix for this bug would be to only warn when the number
> >> >of defined enumerators would not fit inside a bitfield of the
> >> >specified size. Seeing as I don't know the GCC internals very
> >> >well, I'm wondering if anyone could point me in the right
> >> >direction when it comes to getting the number of defined
> >> >enumerators in an enum type.
> >>
> >> Why does the number of enumerators make any difference?
> >
> > I suppose the number of enumerators does not make any difference, but
> > rather the enumerator with the highest integer value. For instance, in
>
> And the lowest value, consider enum X { Y = -200, Z = 5 };
>
> > this example:
> >
> > enum class A { A, B, C; };
> > struct D { A enum_field : 2; };
> >
> > the enumerator with the highest integer value is C, with an integer
> > value of 2. This enum type therefore fits inside the bit-field in
>
> But it doesn't, because as I think it says in the bug report, a scoped
> enum (i.e. enum class) has a fixed underlying type, and all values of
> the underlying type are valid values of the enumeration type.
>
> enum class A { a, b, c };
> A max = A{std::numeric_limits>::max()};
>
Fair enough, I suppose that is the way they are defined in the standard
(and that is the document we have to follow, after all). I wish there
was a way of defining scoped enums that have a precision that is lower
than eight bits, but it is what it is.
> > struct D, and so the compiler should not emit a warning in my eyes.
> >
> > Of course, you can cast an integer to an enum type and assign it that
> > way, which should probably trigger a warning if the value could be too
> > large (it already triggers -Woverflow if the value is a compile-time
> > constant).
>
> As I said in the bug report, PR 51242 comment 27 suggests a more useful
> warning.
>
>
Right. On the code:
enum class FooEnum {A,B,C,D,E,F};
struct Bar { FooEnum baz:2; };
Bar b; b.baz = FooEnum::F;
clang 5.0.0 warns with:
warning: implicit truncation from 'FooEnum' to bit-field changes value
from 5 to 1 [-Wbitfield-constant-conversion]
(when adding -Wbitfield-enum-conversion, clang warns with an error that
is similar to the error gcc gives by default, but points at an
assignment (whether it fits or not) instead of a declaration)
and gcc (trunk) warns with:
warning: overflow in conversion from ‘FooEnum’ to ‘signed char:2’
changes value from ‘(FooEnum)5’ to ‘1’ [-Woverflow]
Neither compiler warns when a value is assigned that is not known to
fit. So what do you propose:
1. Keeping the current warning on declaration and warn if we don't
know whether a value fits?
2. Keeping the current warning and warning when we know a value
does not fit?
3/4. Dropping the current warning and doing one of the above?
In any case, I'll send the flag-only patch to gcc-patches, since that
and a discussion on other warnings to add are logically separate changes.
> >> > 3. When it comes to documentation and tests, I've documented the
> >> >flag in doc/invoke.texi and will add a test in the test suite,
> >> >hopefully when the patch includes the check specified in 2. Are
> >> >there are any other places I should add documentation?
> >>
> >> No, that's all.
> >
> > Thanks.
> >
> > Sam
Re: Please support Coroutines TS in C++
On 16 October 2017 at 08:25, Ramón García wrote:
> ping
As previously stated, nobody is working on it.
GCC is Free Software, so if you really need ths feature you are free
to add it yourself.
>
> On Thu, Aug 31, 2017 at 11:22 AM, Ramón García
> wrote:
>> (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.
Re: -ffunction-sections and -fdata-sections documentation
On 16/10/17 12:31, David Brown wrote:
On 13/10/17 09:06, Sebastian Huber wrote:
Hello,
I would like to update the documentation of these compiler flags and
have some questions. The -ffunction-sections and -fdata-sections
documentation is currently:
Do these options affect the code generation?
-fdata-sections certainly can affect code generation on some targets.
Testing with this sample, using gcc 6.3 for the ARM with -O2:
int a, b, c;
void foo(void) {
a = 1;
b = 1;
c = 1;
}
Generated assembly code is:
foo():
mov r2, #1
ldr r3, .L2
str r2, [r3]
str r2, [r3, #4]
str r2, [r3, #8]
bx lr
.L2:
.word .LANCHOR0
With -fdata-section, you get:
foo():
mov r3, #1
ldr r0, .L2
ldr r1, .L2+4
ldr r2, .L2+8
str r3, [r0]
str r3, [r1]
str r3, [r2]
bx lr
.L2:
.word .LANCHOR0
.word .LANCHOR1
.word .LANCHOR2
I only realised this recently, but it can make a significant difference
on targets that don't use direct addressing modes (such as ARM). It is
maybe worth mentioning this in any changes to the gcc documentation.
I already sent a documentation patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00959.html
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Please support Coroutines TS in C++
On 10/16/2017 07:06 AM, Jonathan Wakely wrote: On 16 October 2017 at 08:25, Ramón García wrote: ping As previously stated, nobody is working on it. Not because nobody cares, but because of lack of time against higher priority things. nathan -- Nathan Sidwell
