Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparing boost.coroutine2 (stackful) to stackless coro implementation... #4

Open
germandiagogomez opened this issue Jun 2, 2017 · 5 comments

Comments

@germandiagogomez
Copy link

germandiagogomez commented Jun 2, 2017

Well, needless to say, but, unless I am really confused... it does not make even sense to compare stackful to stackless coroutines and conclude that co2 implementation is faster. It does not even mention that they implement different things and that stackful is more costly by its own nature and capabilities.

@jamboree
Copy link
Owner

jamboree commented Jun 2, 2017

Are you mentioning the comparison at Performance section?

It's just for showing the overhead of context-switch. What comparison do you want to see?

@germandiagogomez
Copy link
Author

Are you mentioning the comparison at Performance section?

It's just for showing the overhead of context-switch. What comparison do you want to see?

That was my point: you are comparing a stackless context switch to a stackful context switch and concluding that your library is faster with no mention about the differences and difference in power (if I am not wrong and I misunderstand something).

@jamboree
Copy link
Owner

I don't think I have made any conclusion here, anyway, it's just a very basic comparison of context-switch overhead. For the differences in stackless/stackful coroutines, you can see my answer here.

@ozra
Copy link

ozra commented Oct 10, 2017

I, for one, like the benchmark and the comparison of techniques. That's what I want to know: what can I gain from fitting my code in stack-less vs. full blown stack-switched co's. Please keep it.

@germandiagogomez
Copy link
Author

@ozra There is nothing wrong in keeping the benchmark itself. It is just that it is misleading how things are explained. :) Just my two cents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants