On Fri, 2015-03-27 at 22:48 +0000, ketmar via Digitalmars-d-announce wrote:
> 
[…]
> the whole "userspace threads" concept is a reimplementation of kernel threads and sheduling. ;-)
> 

And kernel threads are a reimplementation of user space threads.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 28 Mar 2015 11:02:23 +0000, Russel Winder via Digitalmars-d-announce wrote:

> On Fri, 2015-03-27 at 22:48 +0000, ketmar via Digitalmars-d-announce wrote:
>> 
> […]
>> the whole "userspace threads" concept is a reimplementation of kernel threads and sheduling. ;-)
>> 
>> 
> And kernel threads are a reimplementation of user space threads.

hm. yes, that was "coroutines on steroids".

On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote:

> The data points we have suggest that the scarcity of D programmers is an imaginary problem, because enterprises just hire good people and they pick it up (ask Don at Sociomantic or Dicebot for example).  Modern business has a misplaced emphasis on credentials.  And if you have a large code base it is not like a new guy can just dive in, anyway.  There is a signalling effect at work also, at least for the time being.

+1

/P

Am 28.03.2015 um 10:17 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@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.

On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote:
> You can access TLS from an event callback just as easy as from a fiber.

Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread.

> And why can't you do the same with fibers and schedule the fibers accordingly?

You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete.

> 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.

I don't understand how randomization can help you here.

> They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests

A good load balancer measure back-pressure (load information from the instance) and fire up new instances.

> 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.

This is something you can do on paper. A language feature should support a wide set of applications.

On Friday, 27 March 2015 at 04:24:52 UTC, Walter Bright wrote:
> On 3/26/2015 7:06 PM, weaselcat wrote:
>> vibe has (experimental?) green threads, doesn't it?
>> I don't keep up with vibe, so I may be wrong.
>
> I don't know, but if it does have good 'uns they should be moved into Phobos!

It does, and it should. In fact, I'd consider it massive selling point for D if it were; "you want easy Go-like concurrency? D has that too". Right now, it's available easily for writing servers: just use vibe.d. But it'd be great if the concurrency was available without depending on the rest of the library.

I see no difference between "go func" and "runTask()". "select" might be a different matter, though, I don't know.

Atila

On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
> but it is broken! the whole point of async i/o servers is that such
> servers spend most of their time waiting for i/o. and if you need to do
> some lengthy calculations, you either spawns a "real thread" and commands
> it to wake you up when it is finished, or asking external server to do
> the job (and wake you when it is finished).

Nah. The point is to get parallel work done with less complexity, but at some performance cost. A design where you have to accurately predict running time per task in order to get decent latency is basically adding back the complexity in order to get a simplistic language/runtime with no benefits to the programmer.

In essence, you should ideally be able to break a task into all it's independent parts and run them in parallel (i.e.. futures, events etc). Preferably batch them to get better performance, and sort them based on when they have to complete. Then have a mechanism that exerts back-pressure if deadlines are in danger, telling the load balancer to back off. How you go about it depends on the application, but that ought to be the ideal for anything that resembles a modern soft realtime platform.

> the whole thing of cooperative multitasking is to be... cooperative.

Nah. Cooperative multitasking is a sorry excuse that belongs to the 80s. This should be as transparent as possible. You cannot insert "yield" into an external library.

On Saturday, 28 March 2015 at 13:27:56 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
>> but it is broken! the whole point of async i/o servers is that

Note: I presume that you meant servers and no OS-level async i/o (the limitations of unix select() is a different story).

On Sat, 28 Mar 2015 13:27:55 +0000, Ola Fosheim Grøstad wrote:

> In essence, you should ideally be able to break a task into all it's independent parts and run them in parallel (i.e.. futures, events etc). Preferably batch them to get better performance, and sort them based on when they have to complete. Then have a mechanism that exerts back-pressure if deadlines are in danger, telling the load balancer to back off. How you go about it depends on the application, but that ought to be the ideal for anything that resembles a modern soft realtime platform.

then you have to switch to some functional language, preferably one that does cps transformations in the compiler. as you told somewhere else, D is too broad to be restricted to this.

On Sat, 2015-03-28 at 12:58 +0000, Atila Neves via Digitalmars-d-announce wrote:
> 
[…]
> It does, and it should. In fact, I'd consider it massive selling point for D if it were; "you want easy Go-like concurrency? D has that too". Right now, it's available easily for writing servers: just use vibe.d. But it'd be great if the concurrency was available without depending on the rest of the library.
> 
> I see no difference between "go func" and "runTask()". "select" might be a different matter, though, I don't know.

I need to be convinced that the concurrency and parallelism model of vibe.d is in fact equivalent to that of goroutines, currently I would say they are very, very different.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder