Added Github Actions CI

[TheTechsTech]

The coro_timing.c is comparing sub functions calls to coroutine calls.

This mco_resume is much slower, library needs optimizing, test converted from https://github.com/higan-emu/libco/blob/master/doc/examples/test_timing.cpp

minicoro:

context-switching timing test

1.366 seconds per 50 million subroutine calls (500000000 iterations)
34.548 seconds per 100 million mco_resume calls (500000000 iterations)
mco_resume skew = 25.295826

libco:

context-switching timing test

1.326 seconds per 50 million subroutine calls (500000000 iterations)
6.071 seconds per 100 million co_switch calls (500000000 iterations)
co_switch skew = 4.577628x

[dumblob]

Wow, what a difference with resume. Thanks for spotting and all the time and effort you invested into the "coroutine business"!

[TheTechsTech]

I went a totally different direction instead, moved most of my ideas into https://github.com/symplely/c-coroutine.

The library here has too many shortcomings, and can't move belong the not so low level.

[RandyGaul]

@TheTechsTech Could you please write more here about the differences, including summary of the ideas and various changes? The pros/cons of the tradeoffs, what kind of work is necessary to go from what's in mini_coro.h to what you have there?

[RandyGaul]

Specifically, I'm interested in performance related changes. So if you have other changes going on about the API or making things higher level, I would be really interested in separating those from any perf related stuff.

[edubart]

I suspect he measured i686 which has no assembly backend, not x86_64, or measured some noise. I don't bet in 6x factor speed-up unless he is not saving floating point state (which is dangerous) or doing some other dangerous trick. I already measured before that on x86_64 Windows and it took 33 CPU cycles which was already pretty low, 6x factor speedup would mean in a switch in ~5.5 CPU cycles and I don't think that is doable.

I would not bother switching to something that says to be more optimized than minicoro, minicoro is already pretty efficient when using the assembly backend and there is not much room to optimize further without consequences or feature removal. Unless you really need to target x86 32-bit which is not supported yet for the assembly backend.