Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"

[Sönke Ludwig via Digitalmars-d-announce]

Am 28.03.2015 um 10:17 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang at gmail.com>":
> On Friday, 27 March 2015 at 16:48:26 UTC, Sönke Ludwig wrote:
>>> 1. No stack.
>>
>> That reduces the memory footprint, but doesn't reduce latency.
>
> It removes hard to spot dependencies on thread local storage.

You can access TLS from an event callback just as easy as from a fiber.

>
>>> 2. Batching.
>>
>> Can you elaborate?
>
> Using fibers you deal with a single unit. Using events you deal with a
> request broken down into "atomic parts". You take a group of events by
> timed priority and sort them by type. Then you process all events of
> type A, then all events of type B etc. Better cache locality, more fine
> grained control over scheduling, easier to migrate to other servers etc.

And why can't you do the same with fibers and schedule the fibers 
accordingly? There is no difference between the two models, except that 
fibers provide additional persistent state in the form of a stack.

>
> But the fundamental problem with using fibers that are bound to a thread
> does not depend on long running requests. You get this also for multiple
> requests with normal workloads, it is rather obvious:
>
> @time tick 0:
>
> Thread 1…N-1:
> 100 ms workloads
>
> Thread N:
> Fiber A: async request from memcache (1ms)
> Fiber B: async request from memcache (1ms)
> ...
> Fiber M: async request from memcache…
>
> @time tick 101:
>
> Thread 1...N-1:
> free
>
> Thread N:
> Fiber A: compute load 100ms
>
> @time tick 201:
> Fiber B: compute load 100ms
>
> etc.

It's you who brought up the randomization argument. Tasks are assigned 
to a more or less random thread that is currently in the scheduling 
phase, so that your constructed situation is simply *highly* unlikely.

>
> Also keep in mind that in a real world setting you deal with spikes, so
> the load balancer should fire up new instances a long time before your
> capacity is saturated. That means you need to balance loads over your
> threads if you want good average latency.

They *do* get balanced over threads, just like requests get balanced 
over instances by the load balancer, even if requests are not moved 
between instances. But IMO it doesn't make sense to go further with this 
argument with some actual benchmarks. It's not at all as clear as you'd 
like what the effects on overall performance and on average/~maximum 
latency are in practice for different applications.

>
> Antyhing less makes fibers a toy language feature IMO.