[nem-en] Re: Re: Re: language shootout: cheap-concurrency (Dmitry Ivankov)

[Kamil Skalski]

2007/5/7, Micky Latowicki <biosap at gmail.com>:
> > One question: why it is called concurrency?
> > As far as I understand the task is to use general concurrency mechanisms.
>
> Concurrency, as the term is used in this benchmark, means that you
> write something that looks sequential yet runs at the same time as
> other sequential things.

Well, I wouldn't consider running coroutines as "concurrent"
execution, though it is a fact that many languages / runtimes / OSes
are implementing concurrency in such fashion (they have a set of
"threads" composed of  "instruction pointer" and "program memory",
which they sequentially update, let it be using some priorities or
even a single instruction per step fashion).
According to Wikipedia
(http://en.wikipedia.org/wiki/Concurrent_computing) "concurrent" does
not necessarily mean parallel or "happening in the same instant".
But in my opinion it should be used only for threads, which can
actually run parallel when using multiple processors.

You did an implementation of a little operating system for concurrent
execution, which does the work well. I guess it is up to the
benchmark's creators whether to allow such design or not. Anyways, it
is quite nice code and I would like to include it in snippets as an
example of language usage and as test for compiler.

BTW. if we talk about Language Shootout, the first thing to be done is
to put Nemerle as an available language at the first place. This
probably means writing some more examples and providing authors of
service with details instruction about installation of Nemerle.

>
> In this case, the thing whose code  looks sequential - the thread - is
> the result of the IncrementorThread function. Its structure is
> isomorphic to that of a message loop, where a thread repeatedly waits
> for an int message in its input channel, does some work, and then
> emits a message to its output channel.
>
> Consider these two functions, the first of which may be the body of a thread:
>
> def IncrementorThread(inChannel, next) {
>    while(true) {
>       x = inChannel.wait();
>       next.put(x+1)
>    }
> }
>
> Compare this with an earlier version of my code:
>
>         def IncrementorThread(next)
>             co.Waiting((x)=>{ // start of loop
>                 def nextNext = next.put(x+1);  // body of loop
>                 IncrementorThread(nextNext) // return to start of loop
>             })
>
> These functions both wait for input, increment it, then emit it, and
> loop. They can both be run concurrently with other functions, except
> that the latter can do so very cheaply - no need for an OS-level
> thread.
>
> This approach has the main advantages that come with lightweight
> threads - the thread's code is concentrated in one place, there's no
> fear of race conditions, and switching between "threads" is fast.
>
> However, judging by the reception similar implementations of the
> benchmark have received, I now think that such implementations aren't
> conventional enough to be regarded as unambiguously concurrent.
>
> I guess I'll write another implementation, one that uses yield, and
> then it will be just as visibly concurrent as the python
> implementation that was accepted to the benchmark. It's too bad,
> though - I think using explicit closures, rather than the implicit
> ones created by yield, is just as convenient and more flexible.
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


-- 
Kamil Skalski
http://nazgul.omega.pl