On Wednesday, 30 March 2016 at 15:50:47 UTC, Jin wrote:
> This is java bloatware. :-(

I've never used the library so I can't comment on that, but the actual data structure/algorithm is really pretty simple.  The core components are atomic counters and a static array.  I think it would be a good data structure for channels.

On Wed, 2016-03-30 at 15:50 +0000, Jin via Digitalmars-d wrote:
> On Wednesday, 30 March 2016 at 15:22:26 UTC, Casey Sybrandy wrote:
> > 
> > > 
> > > Have you considered using a Disrupter (http://lmax-exchange.github.io/disruptor/) for the channels? Not sure how it compares to what you're using from Vibe.d, but it's not a hard data structure to implement and, IIRC, it allows for multiple producers and consumers.
> > Oh, and yes, I know that it would have to be rewritten in D unless there's a C version somewhere.  I actually did it once and it wasn't too bad.  I don't think I have a copy anymore, but if I do find it, I can put it up somewhere.
> This is java bloatware. :-(

I think that is probably just slander.

Whilst there are some known problems with The Disruptor, blithely
labelling it "java bloatware" is most likely an uneducated, and
probably ill-judged, comment.

-- 
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 Wed, 2016-03-30 at 17:01 +0000, Casey Sybrandy via Digitalmars-d wrote:
> On Wednesday, 30 March 2016 at 15:50:47 UTC, Jin wrote:
> > 
> > This is java bloatware. :-(
> I've never used the library so I can't comment on that, but the actual data structure/algorithm is really pretty simple.  The core components are atomic counters and a static array.  I think it would be a good data structure for channels.

If I recollect correctly, the core data structure is a lock-free ring
buffer, and the parallelism "trick" the use of multicast with atomic
indexes. This works fine for the problem of creating a trading
framework, but I suspect the architecture is just too big for realizing
channels. In particular, the really important thing about channels over
(thread|process)-safe queues is the ability to select. I have no idea
how select is implemented on Windows but the classic Posix approach is
to use file descriptors to represent the queues and select or epoll
system calls to get the kernel to realize the select. As to how JCSP
does select on the JVM, I shall have to go and delve into the source
code…

-- 
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 Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
>
> http://wiki.dlang.org/Go_to_D

Any performance comparison with Go? esp. in real word scenario?

Can it easily handle hundreds of (go)routines?

On Sat, 2020-05-16 at 20:06 +0000, mw via Digitalmars-d wrote:
> On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
> > http://wiki.dlang.org/Go_to_D
> 
> Any performance comparison with Go? esp. in real word scenario?
> 
> Can it easily handle hundreds of (go)routines?

Seems to have been created four years ago and then left fallow. Perhaps it should be resurrected  and integrated into Phobos? Or left as a package in the Dub repository?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 17 May 2020 at 15:17:44 UTC, Russel Winder wrote:
> On Sat, 2020-05-16 at 20:06 +0000, mw via Digitalmars-d wrote:
>> On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
>> > http://wiki.dlang.org/Go_to_D
>> 
>> Any performance comparison with Go? esp. in real word scenario?
>> 
>> Can it easily handle hundreds of (go)routines?
>
> Seems to have been created four years ago and then left fallow. Perhaps it should be resurrected  and integrated into Phobos? Or left as a package in the Dub repository?

;)

https://github.com/nin-jin/go.d/issues/2

Kind regards
Andre

On Saturday, 16 May 2020 at 20:06:47 UTC, mw wrote:
> On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
>>
>> http://wiki.dlang.org/Go_to_D
>
> Any performance comparison with Go? esp. in real word scenario?
>
> Can it easily handle hundreds of (go)routines?

Go can easily have some ten thousand green threads. I once did a test run to see how many. On a 4 GB machine 80.000 green threads aka goroutines were created till out of memory occured.

Communicating sequential processes as in Go relies on being able to create a large amount of threads. With a paradigm of threads doing blocking takes on channels any application would otherwise quickly run out of threads. In D something similar could be done using fibers. Using fibers is also the approach chosen in Java extending the JVM to have CSP-stye concurrency as in Go, see https://www.youtube.com/watch?v=lIq-x_iI-kc

Then you also need continuations. Lets say inside a function a blocking take is done on two channels in a row. The first channel has some input, the next one has not. In between comes a context switch. When switching back the value taken from the first channel has to be put back into the context. This is why continuations are needed.

Really nice work! Please keep it going :-)

On Tuesday, 19 May 2020 at 08:42:14 UTC, Bienlein wrote:
>
> Then you also need continuations. Lets say inside a function a blocking take is done on two channels in a row. The first channel has some input, the next one has not. In between comes a context switch. When switching back the value taken from the first channel has to be put back into the context. This is why continuations are needed.
>

The continuation is implicit when using fibers, isn't it?

On Sunday, 17 May 2020 at 15:17:44 UTC, Russel Winder wrote:
> On Sat, 2020-05-16 at 20:06 +0000, mw via Digitalmars-d wrote:
>> On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
>> > http://wiki.dlang.org/Go_to_D
>> 
>> Any performance comparison with Go? esp. in real word scenario?
>> 
>> Can it easily handle hundreds of (go)routines?
>
> Seems to have been created four years ago and then left fallow. Perhaps it should be resurrected  and integrated into Phobos? Or left as a package in the Dub repository?

FYI: channels are also part of vibe-core since a while:

https://github.com/vibe-d/vibe-core/blob/master/source/vibe/core/channel.d

On Tue, 2020-05-19 at 08:42 +0000, Bienlein via Digitalmars-d wrote:
> On Saturday, 16 May 2020 at 20:06:47 UTC, mw wrote:
> > On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:
> > > http://wiki.dlang.org/Go_to_D
> > 
> > Any performance comparison with Go? esp. in real word scenario?
> > 
> > Can it easily handle hundreds of (go)routines?
> 
> Go can easily have some ten thousand green threads. I once did a test run to see how many. On a 4 GB machine 80.000 green threads aka goroutines were created till out of memory occured.

It wouldn't surprise me if std.parallelism couldn't do something analogous. There are tasks that are executed (potentially with work stealing) by threads in a threadpool. The problem is that the std.parallelism API is dedicated to data parallelism rather than the process/channels concurrency/parallelism of CSP (the theoretical foundation for goroutines – sort of but you have to read Rob Pike's articles to see why).

I am fairly certain, but have not yet checked, that the idea of task is very similar in std.parallelism and jin.go – which is based on vibe.d's event loop as I understand it (but could be wrong). Vibe.d allows a threadpool, though I suspect most people use it single threaded. So Vibe.d and std.parallelism have a lot in common. I'll bet there is much that could be factored out and shared, but realistically this isn't going to happen.

> Communicating sequential processes as in Go relies on being able to create a large amount of threads. With a paradigm of threads doing blocking takes on channels any application would otherwise quickly run out of threads. In D something similar could be done using fibers. Using fibers is also the approach chosen in Java extending the JVM to have CSP-stye concurrency as in Go, see https://www.youtube.com/watch?v=lIq-x_iI-kc

I wonder if we should use "thread" for heavyweight (OS?) thread, "fibre" for fibre (including lightweight threads from before threads became threads), and task for the things that get put into the job queues of a threadpool. D already has threadpool in std.parallelism, perhaps it needs extracting (as in Java) so it can be the basis of Vibe.d – or vice versa, obviously.

> Then you also need continuations. Lets say inside a function a blocking take is done on two channels in a row. The first channel has some input, the next one has not. In between comes a context switch. When switching back the value taken from the first channel has to be put back into the context. This is why continuations are needed.

Are you sure? Isn't the whole point of tasks (processes in CSP jargon) and channels is that you don't need continuations. A CSP computation should not even understand the idea of a context switch. If it matters, has perhaps, the concept of fibre intruded in a way that violates the abstraction?

> Really nice work! Please keep it going :-)
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk