llvm dev - Mar 2020 - Efficient Green Thread Context-Switching

Sorry, I certainly didn't mean to be dishonest. I was just repeating one of
the comparisons given by the research paper. Regardless, even setjmp() uses a
structure of 148 bytes in size (on my machine). The main point is that with
compiler support, many context switches can be easily reduced to just a few
instructions and only 8 byte of memory, and even in the worst case they will
outperform setjmp() by a factor of 2. That’s very significant for modern servers
which could expect millions of contexts to exist simultaneously. It would also
really help small IOT processors to multitask, which is something they’re
normally bad at. I think the use-cases and efficiency achieved is compelling
(especially as computing becomes more and more parallel/concurrent).
> On Mar 27, 2020, at 2:29 PM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Fri, Mar 27, 2020 at 01:51:48PM -0500, Joshua Thomas Wise via llvm-dev
wrote:
>> The paper shows the results of many benchmarks, all of which show this
>> model heavily outperforming existing models of context switching, in
>> both speed and memory usage. For example, it mentions that the POSIX
>> functions makecontext() and swapcontext() save a structure that’s 936
>> bytes in size (768 on my machine), but their model generates context
>> switches that save only 8-80 bytes of CPU state, depending on which
>> existing optimizations are able to apply to the specific context
switch.
>> In some cases, the entire context switch is reduced to 1 or 2
instructions.
> 
> Take a look at the the setjmp/longjmp intrinsics. IMO it is dishonest to
> compare with makecontext/swapcontext, which generally have to save the
> full FPU state and that's where the majority of the data is.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Mar 27, 2020 at 02:58:03PM -0500, Joshua Thomas Wise
wrote:
> Sorry, I certainly didn't mean to be dishonest. I was just repeating
> one of the comparisons given by the research paper. Regardless, even
> setjmp() uses a structure of 148 bytes in size (on my machine).
Let me repeat. Please take a look at the setjmp/longjmp intrinsics. On
support architectures they boil down to at most 5 pointers.

Joerg

The first time you said “setjmp/longjmp intrinsics” I thought it was a typo, and
that you were talking about the C standard library functions. If you’re actually
talking about LLVM intrinsics, are they documented? I don’t see any intrinsics
with those names in the language reference (https://llvm.org/docs/LangRef.html
<https://llvm.org/docs/LangRef.html>).
> On Mar 27, 2020, at 3:30 PM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Fri, Mar 27, 2020 at 02:58:03PM -0500, Joshua Thomas Wise wrote:
>> Sorry, I certainly didn't mean to be dishonest. I was just
repeating
>> one of the comparisons given by the research paper. Regardless, even
>> setjmp() uses a structure of 148 bytes in size (on my machine).
> 
> Let me repeat. Please take a look at the setjmp/longjmp intrinsics. On
> support architectures they boil down to at most 5 pointers.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/f016373c/attachment.html>