On Fri, 2014-03-07 at 19:16 +0000, Graham Fawcett wrote:
> On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
> 
> > It's just a pity no-one yet has a
> > realization of π-calculus as well – other than the programming
> > language Pict, and the Scala library PiLib.
> 
> JoCaml, an extension of Ocaml, also comes to mind. It's join-calculus, not pi-calculus, but I understand that each can be encoded in the other.

I haven't done anything with OCaml other than compiling Unison, so didn't realize they had gone this route.

Re join-calculus vs π-calculus, I have no direct experience, but I suspect that it will be like actors and dataflow and CSP: each can be realized in one of the others, but if you want things to be efficient you realize them separately.

-- 
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 Friday, 7 March 2014 at 12:23:09 UTC, Atila Neves wrote:

>My point was that just by writing it in Go doesn't mean magical performance benefits because of its CSP, and that vibe.d's fibers would do just fine in a direct competition. The data seem to support that.

Right. I was refering to a large number of threads apparently not being a problem in Go. It was not about execution speed. This way, admittedly, I highjacked the thread a bit.

>68K connections is nothing. I'll start getting interested when his benchmarks are 200K+.  Event-based systems in C can handle millions of concurrent connections if implemented properly.  I'd like to believe vibe.d can approach this as well.

That's good to hear. I read a blog from a company that changed from using C with libevent to Go. I searched for it now for quite a while, but couldn't find it again. From what I remember they claimed they could now handle much more connections using Go.

> One question - doesn't Vibe.d already use green threads?

What they are saying on their web site is that they are using fibers and at the same time they say they are using libevent. That is confusing for me. On http://vibed.org/features they write: "Instead of using classic blocking I/O together with multi-threading for doing parallel network and file operations, all operations are using asynchronous operating system APIs. By default, >>libevent<< is used to access these APIs operating system independently."

Further up on the same page they write: "The approach of vibe.d is to use asynchronous I/O under the hood, but at the same time make it seem as if all operations were synchronous and blocking, just like ordinary I/O. What makes this possible is D's support for so called >>fibers<<".

>It does. Bienlein has a very vague knowledge of topics he
>comments about.

I thought the vibe.d guys would shed some light at this at the occasion, but no luck. What I don't understand is how fibers can listen to input that comes in through connections they hold on to. AFAIKS, a fiber only becomes active when it's call method is called. So who calls the call method in case a connection becomes active? That is then again a kernel thread? How does the kernel thread know something arrived through a connection? It can't do a blocking wait as the system would run out of kernel threads very quickly.

>I think what Go and Erlang do is to use green threads (or equivalent,
>goroutines in Go) for the applications side and a kernel thread pool
>within the runtime doing "work stealing" on the green threads. This is
>more or less (ish) what the Java Fork/Join framework of Doug Lea does as
>well.

When in Go a channel runs empty the scheduler detaches the thread that served it and attaches it to a non-empty channel. In Go all this is in the language and the runtime where it can be done more efficiently than in a library. AFAIU, this is a main selling point in Go.

>Vert.x is caliming to be able to handle millions of active connections.

All right, as you can't have millions of threads on the JVM they must do that through some asynchronous approach (I guess Java NewIO). I read that an asynchronous solution is not as fast as one with many blocking threads as in Go or Erlang. I don't understand why. It was just claimed that this were the case.

On 07/03/14 10:15, John Colvin wrote:
> Having said that, I've been getting similar results from gdc and dmd recently
> too, with ldc coming out as a very clear winner.

Yup, this has been my experience for a while now too.  I don't know what changed in the LLVM backend (or LDC's exploitation of its features) but LDC is clearly ahead in its ability to optimize D code.

That said, the main place where DMD lags AFAICS is number-crunching.  Other stuff, probably not so much; and at least in my own benchmarks of various bits of code, there are occasional surprises where some particular case seems to run faster when compiled with DMD.

On 2014-03-07 21:11:12 +0000, Bienlein said:

> What they are saying on their web site is that they are using fibers and at the same time they say they are using libevent. That is confusing for me. On http://vibed.org/features they write: "Instead of using classic blocking I/O together with multi-threading for doing parallel network and file operations, all operations are using asynchronous operating system APIs. By default, >>libevent<< is used to access these APIs operating system independently."
> 
> Further up on the same page they write: "The approach of vibe.d is to use asynchronous I/O under the hood, but at the same time make it seem as if all operations were synchronous and blocking, just like ordinary I/O. What makes this possible is D's support for so called >>fibers<<".

That is all correct.  Libevent supplies the polling an async io.   D provides the ability to do fibers.   Mixed together you get a very probust, easy to program, scalable, web platform.   See below.

> 
>> It does. Bienlein has a very vague knowledge of topics he
>> comments about.
> 
> I thought the vibe.d guys would shed some light at this at the occasion, but no luck. What I don't understand is how fibers can listen to input that comes in through connections they hold on to. AFAIKS, a fiber only becomes active when it's call method is called. So who calls the call method in case a connection becomes active? That is then again a kernel thread? How does the kernel thread know something arrived through a connection? It can't do a blocking wait as the system would run out of kernel threads very quickly.

Fibers are cooperatively multitasked routines.  Whenever vibe-d uses a libevent IO function, it yields it's current operation back to the event loop.  When a libevent poll indicates there is data waiting, it resumes that fiber where it was left off.   The vibe-d event loop is essentially the scheduler for the fibers.

On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
> On Fri, 2014-03-07 at 16:53 +0000, Sean Kelly wrote:
> […]
>> 68K connections is nothing. I'll start getting interested when his benchmarks are 200K+.  Event-based systems in C can handle millions of concurrent connections if implemented properly.  I'd like to believe vibe.d can approach this as well.
>
> There used to be a 100k problem, i.e maintaining more than 100k active,
> that means regularly causing traffic, not just being dormant for a few
> centuries, but so many frameworks can now support that , that it has
> become a non-metric. I don't know if Spring, JavaEE, can handle this but
> on the JVM Vert.x certainly, I suspect Node.js can as well. Vert.x is
> caliming to be able to handle millions of active connections.
>
> I suspect it is now at the stage that the OS is the bottle neck not the
> language of the framework.

I think the biggest issue at very large number of connections is memory use. In fact, I don't expect even vibe.d to scale beyond a few hundred K if it allocates a fiber per connection. It would have to use a free list of fibers and make a top-level read effectively release the current fiber into the free list.  Scaling at this level in C generally meant retaining little to no state per connection basically by necessity.

On Friday, 7 March 2014 at 19:03:29 UTC, Dicebot wrote:
> On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
>> I suspect it is now at the stage that the OS is the bottle neck not the
>> language of the framework.
>
> I think specialized operating systems devoted to single service will be the future of high load web projects similar to current realities of hard real-time services.

I think you are right. There seems to be a lot of attention now that C10K is winding down toward addressing the next bottleneck; the OS. People are increasingly circumventing the OS and reading/writing directly from/to the network interface.

http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html

On Friday, 7 March 2014 at 18:56:05 UTC, Andrei Alexandrescu wrote:
> On 3/7/14, 12:45 AM, Bienlein wrote:
>> If you want to give D a boost, put Go-style CSP and green threads into
>> it as well. Then D will start to fly. Otherwise it will have to continue
>> competing against C++ as its sole application area where it will always
>> remain a niche player, because of the market dominance of C++.
>
> Interesting you should mention that. Walter has been mulling over a possible DIP on that.

Would be awesome if D got some kind of CSP. I used to reproduce deadlocks and race conditions for some years in a shop floor manufacturing system and fix them. From that experience I can say that you really run into much less trouble whith channels as in Go compared to using locks, sempahores, etc. You can even gradually improve your concurrent solution as you can stick to channels to which your threads are bound to. Without them threads go through everything where locks don't help with the structuring but only increase complexity.

If you realize there is some mutex missing, it can be very hard to move it in place and only have little code in the mutex block. Changing concurrent code based on locks is very deadlock critical. So being defensive you put the mutex block around a lot of code rather than refactoring it to get the mutex block small to have little lock contention. With CSP you only have to fix the way you deal with some channel or introduce some other channel. CSP is truly a step ahead IMHO.

-- Bienlein

On Fri, 2014-03-07 at 23:18 +0000, Bienlein wrote:
[…]
> Would be awesome if D got some kind of CSP. I used to reproduce
[…]
> to have little lock contention. With CSP you only have to fix the way you deal with some channel or introduce some other channel. CSP is truly a step ahead IMHO.

Actors, dataflow and CSP are three different models of using processes and message passing. They are applicable in different situations. Clearly dataflow and CSP are closer to each other than either to actors. Go has chosen to focus only on CSP (sort of, see previous emails) and ignore dataflow and actors at the language level. This may be an error. In GPars, we have chosen to keep all three distinct and implemented separately. This has given a clear performance benefit over implementing one as the base and the others on top.

And don't forget data parallelism, but std.parallelism already provides good stuff in that department for D — though it could do with some new love.

I guess D could be said to have actors already using spawn and the message queue.

Dataflow is though where "Big Data" is going. There are commercial offerings in the JVM space and they are making huge profits on licencing, simply because the frameworks work.

-- 
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 Saturday, 8 March 2014 at 11:23:17 UTC, Russel Winder wrote:
> I guess D could be said to have actors already using spawn and the
> message queue.

In std.concurrency, the documentation states that: "Right now, only in-process threads are supported and referenced by a more specialized handle called a Tid. It is effectively a subclass of Cid, with additional features specific to in-process messaging". Is there any timeline on when out-process threads will be supported? I think that would bring D closer to being able to achieve Erlang style concurrency.

Sure, I'd love to see CSP in D as well. I think that Go's
advantage is simplicity. If you want to try the same code on more
system threads, all you need to do is increase GOMAXPROCS. With
vibe.d it requires some work. It's not a lot of work but it isn't
as easy as with Go.

OTOH, D + vibe.d give you more control. If I want to have a
dedicated thread to do some tasks and tweak the system, I can. I
tried a bunch of different approaches to use threads to try and
make it go faster that (AFAIK) I wouldn't have been able to in
Go. None of them ended up speeding anything up, but I learned a
lot and it was fun trying.

Atila

On Friday, 7 March 2014 at 18:01:53 UTC, Russel Winder wrote:
> On Fri, 2014-03-07 at 12:23 +0000, Atila Neves wrote:
> […]
>> I suspect you might have missed the point of my original blog post. Yes, it shows D beating Erlang and Go, and that's something I obviously like. But that wasn't the point I was trying to make. My point was that just by writing it in Go doesn't mean magical performance benefits because of its CSP, and that vibe.d's fibers would do just fine in a direct competition. The data seem to support that.
>
> That doesn't mean a CSP and dataflow implementations for D (à la
> DataRush, GPars, Go, PythonCSP, PyCSP) shouldn't attempted.  Sadly I
> think I do not have the time to drive such an endeavour, but I wish I
> could contribute to it if someone else could drive.