How does Project Loom Fibers/Green threads help in Anyway ?

[kant kodali]

Hi Ron,

Thanks for the response. so its sounds more like an option for users who
like a certain design paradigm than performance itself when compared to
what we can achieve with Thread pools/ kernel threads. other words the idea
sounds very similar to Golang and as of today I have not seen any web
server written in Golang that can surpass existing servers written in
C/C++/Java by significant margins but I do agree having both options is
good(assuming the costs are reasonable) to attract more users.

Finally, I hope users don't create pool of Fibers.




On Wed, Jan 17, 2018 at 3:58 AM, Ron Pressler <ron.pressler at oracle.com>
wrote:

> Hi Kant.
>
> The idea of fibers is to let users use familiar, simple — to write, read,
> debug and profile — and backwards/legacy-compatible blocking IO calls in
> fibers, that would automatically be translated to nonblocking IO from the
> OS’s perspective. You’d write ordinary blocking code that in terms of
> performance, would behave the same as tasks using asychronous/nonblocking
> IO. So instead of choosing between simple code and performant code, you’d
> get both.
>
> Ron
>
>
>
>
> On January 17, 2018 at 10:32:45 AM, kant kodali (kanth909 at gmail.com
> (mailto:kanth909 at gmail.com)) wrote:
>
> > Hi All,
> >
> > I came across the links below and I wondering how Fibers can really help
> ?
> > when compared to using a thread pool (which is a pool of kernel threads)?
> > Sure having both options is great but I am trying to understand what
> > difference can it make in terms of performance ?
> >
> > Here is what I know
> >
> > 1) Kernel threads are expensive and the default stack size is in MB's
> > whereas Fibers can have a small stack size somewhere in KB's so one can
> > create as many of them. so what? eventually they all have to map to
> Kernel
> > threads and thread pool exists so user don't create as many as say
> Fibers.
> > isn't it?
> >
> > 2) Fibers have no idea about kernal threads and vice-versa. so if a Fiber
> > makes a blocking system call it has not idea that the kernel thread is
> > blocked and there is no upcall mechanism by any major OS.
> >
> > 3) One can argue Fibers are great when a program is making lot of async
> > calls but I wonder how this is any better in terms of performance when
> > compared to having small thread pool that makes async calls? If this is
> all
> > about expressing something gets easier in Fibers than using thread pool
> but
> > there is no performance difference then I must say this is more of a
> > subjective call so everyone can have their own opinion.
> >
> > At this time, I am not seeing how Fibers can be better performant than
> > having a pool of Kernel threads? if they are in some cases can someone
> > please provide any examples so I can enlightened?
> >
> > http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
> > https://hn.svelte.technology/item/15599854
> >
> > Thanks!
>
>