www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
LLVM 5.0.0 released
By Thom Holwerda on 2017-09-07 23:31:54

This release is the result of the community's work over the past six months, including: C++17 support, co-routines, improved optimizations, new compiler warnings, many bug fixes, and more.

The release notes contain more details.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-17
.
RE[8]: Stackless coroutines
By kwan_e on 2017-09-08 19:07:05
> I think it's almost identical to the threaded case, minus the SMP concurrency.

You can choose which thread a coroutine runs in, same with Boost Fibers. They're just ways to implement cooperative multitasking on top of pre-emptive multitasking that is threads. So SMP concurrency just has to be made explicit, and dare I say provide some support for non-SMP concurrency.

> This fits into the class of problems where the compiler can't know ahead of time whether something might happen before it runs.

The stackless coroutine proposal already does some of it. Anything that uses co_yield is deemed a coroutine and must return a future-like object (I think). No reason why a compiler can't detect nested co_yield calls, especially since such usages are visible through the type system via the mandatory return type adjustment.

The paper I linked to does it a slightly different way. Have leaf function coroutines be stackless and every other kind as stackful. It would still require the same analysis of nested co_yield calls, but again, that's no problem for the type system.

> I don't really know if anyone's implemented it under a real compiler, but it's actually pretty straitforward in principal. While stacks are normally linear structures, there's no technical reason that they have to be.

That's what the segmented stack coroutines from Boost are. They take advantage of gcc's split stack support. So stackless coroutines that are chained together to create a stackful coroutines may as well just have been complete stackful coroutines in the first place. It would be less overhead, in terms of runtime and syntax/annotation, than emulating with stackless coroutines.
Permalink - Score: 3
.
RE[9]: Stackless coroutines
By Alfman on 2017-09-08 19:22:41
kwan_e,

> You can choose which thread a coroutine runs in, same with Boost Fibers. They're just ways to implement cooperative multitasking on top of pre-emptive multitasking that is threads. So SMP concurrency just has to be made explicit, and dare I say provide some support for non-SMP concurrency.

Of course, I've implemented it myself.

> The stackless coroutine proposal already does some of it. Anything that uses co_yield is deemed a coroutine and must return a future-like object (I think). No reason why a compiler can't detect nested co_yield calls, especially since such usages are visible through the type system via the mandatory return type adjustment.

Exactly, compilers can also use this technique to support yielding in nested functions.


> That's what the segmented stack coroutines from Boost are. They take advantage of gcc's split stack support. So stackless coroutines that are chained together to create a stackful coroutines may as well just have been complete stackful coroutines in the first place. It would be less overhead, in terms of runtime and syntax/annotation, than emulating with stackless coroutines.

It makes you wonder why the C++ standard won't support it.
Permalink - Score: 2
.
RE[3]: Stackless coroutines
By FlyingJester on 2017-09-08 19:59:24
But then you're using Boost, a poorly designed, poorly tested, poorly implemented, inconsistent, gigantic library, which tries to be robust but isn't, tries to be header-only but isn't, and goes to ridiculous lengths to smooth over what are, in reality, small differences between OSes.
Permalink - Score: 1
.
RE[4]: Stackless coroutines
By fretinator on 2017-09-08 21:03:48
Opinion much?
Permalink - Score: 4
.
RE[10]: Stackless coroutines
By kwan_e on 2017-09-08 23:21:02
> It makes you wonder why the C++ standard won't support it.

I think it's just a matter of having a more complete proposal + compiler implementation. By that, I mean the author of the stackless coroutine proposal has implemented a form of it in Clang which shows its ability to optimize away coroutines, and the allure of having potentially billions of coroutines.
Permalink - Score: 2
.
RE[4]: Stackless coroutines
By kwan_e on 2017-09-08 23:50:22
> a poorly designed

By some standards. Some people prefer Java style OO libraries, for which there is POCO and Qt. But those are for people who are incapable of learning anything outside of the OO style they emulate while at university that they mistake for good design.

Boost libraries can be over engineered, but that's because they were mostly designed when it was needed to support C++03. No other library for any other language has made similar efforts to be backwards compatible (and still has the same performance characteristics as C++).

> poorly tested

Only for the compiler/architecture combination for which test boxes are hard to come by.

> poorly implemented, inconsistent,

The stuff that made into the standard are not poorly implemented, but they were unable to take advantage of new language features because of the different times they became part of the next standard. Inconsistencies are to be found in every large library. Also different domains may be served better by different styles, so that kind of inconsistency only matters if you are unable to use anything that's not purely OO, or that's not purely template magic, or that's not purely functional, depending on your limitations of understand. Good programmers don't have trouble switching between them when the problem space requires it.

> gigantic library

Some say it's too big. Some say it's not big enough.

> which tries to be robust but isn't,

No, what it's trying to be is as a testing ground for things that may go into the standard library or language.

> tries to be header-only but isn't

There's no mandate that libraries have to be header only. These design choices are left up to library author. So there's no "trying" because it isn't Boost's aim to begin with.

> and goes to ridiculous lengths to smooth over what are, in reality, small differences between OSes.

No. Most of the "ridiculous lengths" is to implement things that run across a vast number of compilers at different standards compliance levels, which happen to be across different OSes. The difference between these platform specific compilers can be huge.
Permalink - Score: 5
.
RE[11]: Stackless coroutines
By Alfman on 2017-09-09 01:27:56
kwan_e,

> I think it's just a matter of having a more complete proposal + compiler implementation. By that, I mean the author of the stackless coroutine proposal has implemented a form of it in Clang which shows its ability to optimize away coroutines, and the allure of having potentially billions of coroutines.

Yes I realize that eliminating the full stack makes it far more scalable. I've been a proponent of this model for a long time. My point was that they could have supported inner coroutines also without causing any additional overhead whatsoever for code that doesn't use it and it would have been much more flexible with regards to the algorithms one could use with it.

Consider that very frequently programmers are encouraged to break up functions for non-technical readability / aesthetic / code design reasons, but artificial language limitations on stack frames like this will force developers to compromise on where we can put code just to work around the language's limitations, so I'm agreeing with your original post.
Permalink - Score: 3

Read Comments 1-10 -- 11-17

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?