On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean@f4.ca> wrote:

> Brad Roberts wrote:
>>  Erlang is indeed a very interesting system if for no other reason that it's fairly unique.  I wish I could find 3-6 months to really get my hands dirty with it, but alas, that's behind another dozen or so projects.  Anyone wanna be my lackey, I mean research assistant?  The pay would be crappy, the housing not free, and the hours sucky.. but it'd be fun, honest!
>
> Now that I'm learning about Erlang I'm discovering that it seems to work a lot like how I wanted to approach concurrency in D, so I'm definitely going to try and find some time to play with it.

The Scala developers have tried to implement something similar to Erlang as a Scala's library 'Actors' [1].
Because of some Scala features (especially pattern matching and symbols as method names) Scala code looks like Erlang.

But attempts to implement message passing model in a universal language (like Java, Scala, C++ or D) lead to some drawbacks. At first, active entities will be represented as threads. So, to pass message from one thread to another it is necessary to use some synchronization techniques (like mutexes and condition variables). But the price of synchronization of threads by OS mechanism is too high. Because of that maximum throughput is not too high [2]. In contast Erlang VM use its own synchronization mechanisms which are cheaper than OS ones. Another limitation is the count of parallel threads on each platfom.

Next, processes in Erlang are isolated. So Erlang VM can easyly wipe out any broken or dangling process without any interference to other processes` data. With OS threads in C++/D/Java programs it not so easy. Even if we terminate thread by some way there could be damaged or inconsistent data to which other thread refer.

Next (as addition to previous), Erlang is a pure functional language. So there no any global variables or shared data beetwen processes. Erlang simply doesn't allow processes to modity some shared variable. In a imperative language is very hard to write in such style, becasue some hidden link beetwen two threads` data can be introduced by a mistake.

Next, reliabilty of Erlang programs highly depend on specific mechanism of Erlang VM -- notification of other process termination. If two processes linked one to another than Erlang VM sents special messages about linked process termination with description and additional information.

Next, Erlang is a very successful and handy DSL for isolated processes communication. Special syntax and pattern matching make Erlang programs small and readable. In staticaly typed languages without pattern matching sending and receiving messages could be much more verbose.

Just my $0.02.

[1] http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html
[2] http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf

-- 
Regards,
Yauheni Akhotnikau

BCS wrote:
> Bruno Medeiros wrote:
>> BCS wrote:
>>
>>> Reply to Pragma,
>>>
>>>> There are moments where I wish I could think *like* Rain Man,
>>>> especially when it comes to concurrency.
>>>>
>>> [...]
>>>
>>>> If nothing else, it illustrates that there's something
>>>> extraordinary about such abilities that may be permanently
>>>> out-of-reach for normal people, despite the fact that some people are
>>>> just born that way.
>>>>
>>>
>>> I have wondered if this is something like incomputableity with regards to a Turing machine. Might the normal brain be like a Turing machine and the autistic brain be something like a brain not limited in the same way? Given that some people can, for instance, identify large primes in near constant time, I'd say this is a distinct possibility.
>>>
>>> At risk of sounding politically incorrect; does anyone known of an autistic person who might be interested in learning programming?
>>>
>>>
>>
>> Autism is not synonymous with savantism, which is what you where thinking of.
>>
> 
> No, I was not necessary thinking of savantism. More generally I was thinking about people whose brains function abnormally. This covers autism, savantism, insanity, Psychopathy and genius[*] among others. Autism just happens to be (if I understand correctly) the more profound and general (savantism seems to be a subset) abnormality with regards to the type of intellect associated with CS style tasks.
> 
> * If you ask me, insanity is where the brain works differently and it get in the way, genius is where the brain works differently and it helps. They are not mutually exclusive and if fact probably correlate quite well.

Well, this conversation was centering on extraordinary abilities that made a human be able to do computer-like calculations (processing large amounts of input instantly, calculating primes, etc.).
That is savantism, not autism. Autism is a wide variety or mental and behavioral disorders (which savantism is a part of), most of them are not very pleasant or even programming-friendly. You should check wikipedia and the web, because autism is kinda of a fuzzy term, and it took me a while to start understanding it, since it seems some people use the term with slightly different (and possibly incorrect) meanings.
For instance, one of my AI/Agents teacher used the term autism as if it meant "not processing external output" which is hardly autism. I also don't think autism in general is a "type of intellect associated with CS style tasks", although some of it's sub-disorders may be (which then?).

(There was a fellow in the D NG some time ago who had Asperger's Syndrome, an autism disorder, but again, autism is not what you were looking for)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

eao197 wrote:
> On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean@f4.ca> wrote:
> 
>> Brad Roberts wrote:
>>>  Erlang is indeed a very interesting system if for no other reason that it's fairly unique.  I wish I could find 3-6 months to really get my hands dirty with it, but alas, that's behind another dozen or so projects.  Anyone wanna be my lackey, I mean research assistant?  The pay would be crappy, the housing not free, and the hours sucky.. but it'd be fun, honest!
>>
>> Now that I'm learning about Erlang I'm discovering that it seems to work a lot like how I wanted to approach concurrency in D, so I'm definitely going to try and find some time to play with it.
> 
> The Scala developers have tried to implement something similar to Erlang as a Scala's library 'Actors' [1].
> Because of some Scala features (especially pattern matching and symbols as method names) Scala code looks like Erlang.

All good points.  And I concede that it would be difficult to achieve the level of concurrency used in Erlang applications in an imperative language like D.  But I do believe that the basic style of programming could be used with reasonable results.  Processes wouldn't be quite as "throw-away" as in Erlang, which would have an impact on error handling and such, but the proper message-oriented design could do fairly well anyway.  CSP, for example, assumes a more heavy-weight process model. It doesn't span networks so well, but it at least shows that similar approaches to parallelism meet with reasonable results in imperative languages.

But my post was really about Erlang anyway :-)  It sounds very interesting and I may well end up wishing I had a project in which to use it.  I'd certainly rather layer Erlang atop D than atop C anyway.


Sean

On Thu, 19 Jul 2007 19:39:59 +0400, Sean Kelly <sean@f4.ca> wrote:

> eao197 wrote:
>> On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean@f4.ca> wrote:
>>> Now that I'm learning about Erlang I'm discovering that it seems to work a lot like how I wanted to approach concurrency in D, so I'm definitely going to try and find some time to play with it.
>>  The Scala developers have tried to implement something similar to Erlang as a Scala's library 'Actors' [1].
>> Because of some Scala features (especially pattern matching and symbols as method names) Scala code looks like Erlang.
>
> All good points.  And I concede that it would be difficult to achieve the level of concurrency used in Erlang applications in an imperative language like D.  But I do believe that the basic style of programming could be used with reasonable results.

It's true. I have used at least last five years -- we have developed our own agent-oriented framework in C++ and have used it in several projects. Agents interoperate each to another only by messages. Agents handle messages by events (special object methods) and special entity, dispatcher, dispatches agent events to one of him worker threads. Some agents can share single worker thread, some agents can own their own thread (active agents).

But as a consequence of C++ usage our code much more verbose than Erlang :(

That approach changes way of thinking completely. So now I'm a message-passing addicted man :))

But because message-passing in C++ more expensive than in Erlang, then it is necessary to divide application into rather big parts (agents). And all communication inside those parts (agent) make via ordinal synchorized calls, but there is almost no traditional multithreading programming in agent implementation. For example, our biggest project, which has been delevoped using that framework, now consists near two hundred agents and more than 90 threads.

-- 
Regards,
Yauheni Akhotnikau

Reply to Bruno,

> Well, this conversation was centering on extraordinary abilities that
> made a human be able to do computer-like calculations (processing
> large amounts of input instantly, calculating primes, etc.).
> That is savantism,

Unless I'm totally missing something (an I did check out wikipedia) savantism is to narrow a term for what I'm thinking of.

> not autism. Autism is a wide variety or mental and
> behavioral disorders (which savantism is a part of), most of them are
> not very pleasant or even programming-friendly. You should check
> wikipedia and the web, because autism is kinda of a fuzzy term, and it
> took me a while to start understanding it, since it seems some people
> use the term with slightly different (and possibly incorrect)
> meanings.
[...]
> I also
> don't think autism in general is a "type of intellect associated with
> CS
> style tasks", although some of it's sub-disorders may be (which
> then?).

OK I'll grant that autism is to wide a term for what I was thinking of (and even so might still not encompass what I'm thinking of).

I think you actually used the correct term at the top, "extra-ordinary abilities" but only if taken literally as not normal. I may be measuring a cloud with a micrometer here but I still think it would be interesting to see how an abnormal mind would approach some of these problems.

Op Thu, 19 Jul 2007 11:58:33 +0100
schreef Bruno Medeiros <brunodomedeiros+spam@com.gmail>:

> For instance, one of my AI/Agents teacher used the term autism as if it meant "not processing external output" which is hardly autism.

Actually, his use is etymologically more correct than using that word for describing the psychological phenomenon we know as "autism"...


-- 
JanC

Heh, guess I've been using mesage-based concurrency for a while without knowing there was anything special about it. But, if I'm understanding this right, in an iterative language, if there _is_ any state shared between actors, you still need explicit locking, neh?

eao197 Wrote:

> On Thu, 19 Jul 2007 19:39:59 +0400, Sean Kelly <sean@f4.ca> wrote:
> 
> > eao197 wrote:
> >> On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean@f4.ca> wrote:
> >>> Now that I'm learning about Erlang I'm discovering that it seems to work a lot like how I wanted to approach concurrency in D, so I'm definitely going to try and find some time to play with it.
> >>  The Scala developers have tried to implement something similar to
> >> Erlang as a Scala's library 'Actors' [1].
> >> Because of some Scala features (especially pattern matching and symbols
> >> as method names) Scala code looks like Erlang.
> >
> > All good points.  And I concede that it would be difficult to achieve the level of concurrency used in Erlang applications in an imperative language like D.  But I do believe that the basic style of programming could be used with reasonable results.
> 
> It's true. I have used at least last five years -- we have developed our own agent-oriented framework in C++ and have used it in several projects. Agents interoperate each to another only by messages. Agents handle messages by events (special object methods) and special entity, dispatcher, dispatches agent events to one of him worker threads. Some agents can share single worker thread, some agents can own their own thread (active agents).
> 
> But as a consequence of C++ usage our code much more verbose than Erlang :(
> 
> That approach changes way of thinking completely. So now I'm a message-passing addicted man :))
> 
> But because message-passing in C++ more expensive than in Erlang, then it is necessary to divide application into rather big parts (agents). And all communication inside those parts (agent) make via ordinal synchorized calls, but there is almost no traditional multithreading programming in agent implementation. For example, our biggest project, which has been delevoped using that framework, now consists near two hundred agents and more than 90 threads.
> 
> -- 
> Regards,
> Yauheni Akhotnikau

On Fri, 20 Jul 2007 08:29:40 +0400, Robert Fraser <fraserofthenight@gmail.com> wrote:

> Heh, guess I've been using mesage-based concurrency for a while without knowing there was anything special about it. But, if I'm understanding this right, in an iterative language, if there _is_ any state shared between actors, you still need explicit locking, neh?

In our framework explicit locking needed only if agents work on different dispatcher threads (for example, if two active agents share some data). But in majority cases cooperative agents work on the same dispatcher thread. Therefore they cannot work in parallel and do not need any locking at all.

>
> eao197 Wrote:
>
>> On Thu, 19 Jul 2007 19:39:59 +0400, Sean Kelly <sean@f4.ca> wrote:
>>
>> > eao197 wrote:
>> >> On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean@f4.ca> wrote:
>> >>> Now that I'm learning about Erlang I'm discovering that it seems to
>> >>> work a lot like how I wanted to approach concurrency in D, so I'm
>> >>> definitely going to try and find some time to play with it.
>> >>  The Scala developers have tried to implement something similar to
>> >> Erlang as a Scala's library 'Actors' [1].
>> >> Because of some Scala features (especially pattern matching and  
>> symbols
>> >> as method names) Scala code looks like Erlang.
>> >
>> > All good points.  And I concede that it would be difficult to achieve
>> > the level of concurrency used in Erlang applications in an imperative
>> > language like D.  But I do believe that the basic style of programming
>> > could be used with reasonable results.
>>
>> It's true. I have used at least last five years -- we have developed our
>> own agent-oriented framework in C++ and have used it in several projects.
>> Agents interoperate each to another only by messages. Agents handle
>> messages by events (special object methods) and special entity,
>> dispatcher, dispatches agent events to one of him worker threads. Some
>> agents can share single worker thread, some agents can own their own
>> thread (active agents).
>>
>> But as a consequence of C++ usage our code much more verbose than Erlang :(
>>
>> That approach changes way of thinking completely. So now I'm a
>> message-passing addicted man :))
>>
>> But because message-passing in C++ more expensive than in Erlang, then it
>> is necessary to divide application into rather big parts (agents). And all
>> communication inside those parts (agent) make via ordinal synchorized
>> calls, but there is almost no traditional multithreading programming in
>> agent implementation. For example, our biggest project, which has been
>> delevoped using that framework, now consists near two hundred agents and
>> more than 90 threads.
>>
>> --
>> Regards,
>> Yauheni Akhotnikau
>



-- 
Regards,
Yauheni Akhotnikau

Sean Kelly a écrit :
> Sean Cavanaugh wrote:
>> Reposting, as I didn't have my name show up properly due to outlook express configuration fun, and any threaded readers are going to camoflauge my response to a nearly year old post :)
>>
>>
>> "Marcio" <mqmnews123@sglebs.com> wrote in message
>> news:ecipfc$15v4$1@digitaldaemon.com...
>>> http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
>>
>>
>> I'm new here but this somewhat old thread starting with this .ppt is very
>> interesting to me since I work with the UE3 engine as a middleware.  Its
>> pretty much dead on, as far as what the future is going to be, and that is
>> in a massively parallel/threaded environment.  Those that do not make the
>> transition are going to have very noticably 'rigid' game simulations that
>> are far less capable.  Only the problem from my point of view is there isn't
>> a single good language make the leap with.  Sure you can have a truely
>> expert programmer get your threading right with the current tools available,
>> but the reality is the current tools and languages available to make
>> threaded programs are pretty bad.  In addition you end up with only 'one
>> guy' who is responsible for far too much code since he has to wrangle
>> everyone elses broken stuff into shape, and always on a rather riduclous
>> timeline.
>>
>> So how do games, threading, and D all tie into this?
>>
>> Ok so I've been following D as a lurker off and on.  From the outside as a
>> C++ programmer, D looks great to me.  I literally get more angry working
>> with C++ every day.  And its all because doing anything 'cool' in C++,
>> particularly templates, requires jumping through hoops.  Jumping through
>> hoops is really the reality of having to deal with language deficiencies.
>> So looking at D the initial impression is 'sweet' I want to write something
>> in that.  Except from my world there are several huge problems:
>>
>> Problem A : Garbage Collection is a dealbreaker.  But not because it exists
>> or even that is is forced or a default.  We definitely want garbage
>> collection.  It is a dealbreaker because of how it behaves.  There are
>> several behaviors that make it such a strong negative as to be a
>> dealbreaker, primarily the unknown frequency of collections, duration of
>> collections, and the fact all our threads get suspended.  The more hardcore
>> games run at a required 60 fps (gran turismo, god of war, etc).  This means
>> all threads are executing a full cycle in 16.6 ms.  How much time do we want
>> the GC to spend?  The answer is 0 ms.  Even spending 1ms for any kind of
>> function in any game is pretty damn slow in a game engine.  If it starts
>> pushing 5 or 10ms it starts impacting response of input, and noticebly
>> hitches the rendering, since this hitch generally isn't every single frame.
>> Consistency of the frame rate matters a lot.   In fact consistency matters
>> so much that collecting could take 2ms of every 15 and we would be ok with
>> it as long at was predictable so we can budget the game around it.  Even if
>> it would only really need 10ms every 5 minutes, that is unacceptable,
>> because a collector taking 10ms is a dealbreaker.
> 
> I think this is one area where D will improve quite a bit over time. Personally, the GC I am most interested in is IBM's Metronome (a Java GC), and I'm hoping that a similar approach will be possible with D.

I was going to point out this GC: at first GCs for Java were not very real-time compatible either, but IBM has made one which seems quite good (I don't know if Sun has a RT GC also).

So it's not really a language issue but a language implementation issue.

Of course, to really use those multicore computers for games, not only the GC should be real-time compatible (which is already a tough nut to crack) but it should also be distributed..

So it could take many years before the D runtime is up to the task, but as this issue is common to any language using a GC (even Monotone is not SMP friendly if I read correctly 'between the lines' of IBM's articles), in the meantime the only solution is to disable the GC in the real-time part of your program, it's still better than using C++..

Regards,
renoX