undefined | Better HN

0 pointsmanwe1507y ago0 comments

There's already many fast, portable, standalone C libraries for this. For instance, see table 1 of https://www.gnu.org/software/pth/rse-pmt.ps. The assembly code for a context switch is pretty minimal (on most platforms, it's just setjmp and longjmp) if you don't try manage the signal state. I would be surprised if there was significant variance in performance (other than whether it chooses to switch the signal mask). Additionally, many language runtimes directly support it without any extra effort on your part. So if you choose to instead use one of those language, you get a fast portable solution without needing to do any extra work to pick a support library (for example, D-Lang LDC, PyPy, Go, Julia).

0 comments

spc4767y ago

I implemented coroutines for C with assembly [1] (x86 32 and 64 bit). I took advantage of the calling convention to cut down on the amount of state to save (4 registers for x86 32b and six for x86 64b). Mixing this with signals is probably unwise [2]. So far I've tested the code on Linux and Mac OS-X and it works (although I might not use it for C++ either).

[1] https://github.com/spc476/C-Coroutines

[2] In my not-so humble opinion, using signals at all is not wise.

gpderetta7y ago

The shortest contest switch sequence I could come up on x86-64 is three instructions:

  xchg  %rsp, %rdx
  leaq  1f(%rip), %rax
  jmp   *%rsi

It it expect the target stack ptr/ip pair to be in rdx/rsi and saves the current stack ptr and ip in rdx/rax. It does not save any register and uses gcc asm clobbers to instruct the compiler to save any other register.

Code at [1]. The comments about hacks and ub is because I'm trying to transparently propagate exceptions across coroutines, otherwise the stack switching us fairly robust (although GCC specific).

[1] https://github.com/gpderetta/delimited/blob/master/delimited...

girvo7y ago

Signals, done correctly, are hard. I agree with your NSHO for the most part. Neat code!

bgongfu7y ago

Not faster than dealing directly with ucontext from what I've seen; many wrap it directly and the rest tend to emulate using signals, setjmp and prayers.

I would love to be wrong though...

manwe150OP7y ago

ucontext modifies the signal mask, requiring a syscall. That’s very expensive (as shown by the boost benchmark above), and usually unnecessary. “emulate” is a rather negative sounding way to describe running effective the same code as ucontext does (which also happens to typically be the same as sigsetjmp) - it’s not like ucontext has some privledged permissions. It’s “just” a context switch.

bgongfu7y ago

I was under the impression that Boost Context is more than that; at least that's what the amount of assembler code tells me; but I'll be the first to admit I don't have much patience for deciphering modern C++. I get that it's possible to invoke the same functionality as ucontext minus signal masks manually, but I'm not convinced it would save enough cycles to pay for the added complexity.

1 more reply

bgongfu7y ago

For the record: I just benchmarked GnuPth with NULL sigmask against ucontext for the example in the post and it's slightly (3.4/3.2s) slower.

j / k navigate · click thread line to collapse

0 comments

spc4767y ago

[1] https://github.com/spc476/C-Coroutines

[2] In my not-so humble opinion, using signals at all is not wise.

gpderetta7y ago

The shortest contest switch sequence I could come up on x86-64 is three instructions:

  xchg  %rsp, %rdx
  leaq  1f(%rip), %rax
  jmp   *%rsi

Code at [1]. The comments about hacks and ub is because I'm trying to transparently propagate exceptions across coroutines, otherwise the stack switching us fairly robust (although GCC specific).

[1] https://github.com/gpderetta/delimited/blob/master/delimited...

girvo7y ago

Signals, done correctly, are hard. I agree with your NSHO for the most part. Neat code!

bgongfu7y ago

Not faster than dealing directly with ucontext from what I've seen; many wrap it directly and the rest tend to emulate using signals, setjmp and prayers.

I would love to be wrong though...

manwe150OP7y ago

bgongfu7y ago

1 more reply

bgongfu7y ago

For the record: I just benchmarked GnuPth with NULL sigmask against ucontext for the example in the post and it's slightly (3.4/3.2s) slower.

j / k navigate · click thread line to collapse