Prev: regsub (and regular expressions in general) trouble.
Next: How to call a tcl script (proc) from a vb.net.
From: Donal K. Fellows on 23 Dec 2009 05:25
On 23 Dec, 01:10, Konstantin Khomoutov <khomou...(a)gmail.com> wrote:
> While the OP is obviously trolling, he does have a point: pure
> functional languages allow their runtime to transparently execute
> several bits of code in parallel. But as this requires controllable
> absence of side effects, it will never be implemented in Tcl.

You get very close by thinking in terms of using processes that
communicate by sending code snippets to each other; that model
translates easily to Tcl's threading model. What Tcl doesn't do is let
multiple threads access the same interpreter at once. While this does
mean that "automatic parallelization" of the type you allude to is
impossible, it also means that we can go a lot faster because almost
no code has to hold locks (we use thread-local variables a lot in the
implementation for those situations where we can't use interpreter-
local storage). It's also easy to scale up (the shared-memory model is
just nasty to scale, yet it is the one that a lot of programmers -
erroneously - believe that threads inherently imply).

Donal.
From: Konstantin Khomoutov on 24 Dec 2009 09:27
On Dec 23, 1:25 pm, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:

>> While the OP is obviously trolling, he does have a point: pure
>> functional languages allow their runtime to transparently execute
>> several bits of code in parallel. But as this requires controllable
>> absence of side effects, it will never be implemented in Tcl.
> You get very close by thinking in terms of using processes that
> communicate by sending code snippets to each other; that model
> translates easily to Tcl's threading model. What Tcl doesn't do is let
> multiple threads access the same interpreter at once. While this does
> mean that "automatic parallelization" of the type you allude to is
> impossible, it also means that we can go a lot faster because almost
> no code has to hold locks (we use thread-local variables a lot in the
> implementation for those situations where we can't use interpreter-
> local storage). It's also easy to scale up (the shared-memory model is
> just nasty to scale, yet it is the one that a lot of programmers -
> erroneously - believe that threads inherently imply).

My claim was more about transparency in such support: Tcl's thread
model is indeed done right, but I think if one asks whether platform X
is ready for SMP/multicore setups, their question is actually about
some kind of transparent support. Say, ejabberd XMPP server written in
Erlang normally uses about 300 Erlang processes (with low server load)
and up to several hundreds of thousands of them under heavy load, and
programmers are not concerned with threading models at all: the Erlang
runtime preempts all these processes regardless of how many CPUs the
underlying hardware platform has.

So, to sume it up:
1) Tcl is ready for SMP/multicore setups in that has support for OS
threads.
2) But this requires explicit coding approaches because Tcl has no
concepts which make using of threads implicit.
From: Donal K. Fellows on 24 Dec 2009 09:46
On 22/12/2009 19:50, tom.rmadilo wrote:
> Green threads seem to be the product of hostility to an existing
> solution and defects in the execution model of the language.

They're specifically introduced when the language is poor at presenting
non-blocking I/O to the user-level code. With Tcl 8.6, you can have
almost the same effect by using something like Coronet
<URL:http://wiki.tcl.tk/22231> to look after the asynchrony for you.
It's not a complete lib yet, but it points to how you can do amazing
stuff nowadays in scripts. Which is very cool. :-)

You need native threads (or multiple processors) to use a multi-core
system properly. There's no way to poodle-fake that.

Donal.
From: tom.rmadilo on 24 Dec 2009 12:17
On Dec 24, 6:27 am, Konstantin Khomoutov <khomou...(a)gmail.com> wrote:
> On Dec 23, 1:25 pm, "Donal K. Fellows"
>
>
>
> <donal.k.fell...(a)manchester.ac.uk> wrote:
> >> While the OP is obviously trolling, he does have a point: pure
> >> functional languages allow their runtime to transparently execute
> >> several bits of code in parallel. But as this requires controllable
> >> absence of side effects, it will never be implemented in Tcl.
> > You get very close by thinking in terms of using processes that
> > communicate by sending code snippets to each other; that model
> > translates easily to Tcl's threading model. What Tcl doesn't do is let
> > multiple threads access the same interpreter at once. While this does
> > mean that "automatic parallelization" of the type you allude to is
> > impossible, it also means that we can go a lot faster because almost
> > no code has to hold locks (we use thread-local variables a lot in the
> > implementation for those situations where we can't use interpreter-
> > local storage). It's also easy to scale up (the shared-memory model is
> > just nasty to scale, yet it is the one that a lot of programmers -
> > erroneously - believe that threads inherently imply).
>
> My claim was more about transparency in such support: Tcl's thread
> model is indeed done right, but I think if one asks whether platform X
> is ready for SMP/multicore setups, their question is actually about
> some kind of transparent support. Say, ejabberd XMPP server written in
> Erlang normally uses about 300 Erlang processes (with low server load)
> and up to several hundreds of thousands of them under heavy load, and
> programmers are not concerned with threading models at all: the Erlang
> runtime preempts all these processes regardless of how many CPUs the
> underlying hardware platform has.

Where to begin? Jabber is a strange protocol. Essentially the server
is a message router. But I never could understand why the original
developers chose tcp and xml and the need to maintain many long term
connections. Why not udp and a binary/string format? Otherwise it is a
nice message/event driven protocol, once you get rid of all the poor
external representation/communication choices.

If the only problem with designing an application large enough to
consume multiple cpus full time was transparent distribution of
independent operations, that would be great. Usually the problems
include resource sharing and synchronization. You can connect to
"hundreds of thousands" of external clients, but can you connect to a
local database for each connection? You might have to share a limited
pool of such connections. Eventually the application falls under the
same requirement: the developer has to make choices non-
transparently.

There is also the missing piece of the puzzle here: given that you
have 100,000 clients, you can spend about 10 microseconds per second
working for each client, or with 1 cpus, 160 us. If each database
query consumed only 1 ms, it would take eight seconds to perform one
query for each client on a 16 cpu box. Any application more
sophisticated than a router would grind to a halt.
From: Konstantin Khomoutov on 24 Dec 2009 13:20
On Dec 24, 8:17 pm, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:

[...]
>> My claim was more about transparency in such support: Tcl's thread
>> model is indeed done right, but I think if one asks whether platform X
>> is ready for SMP/multicore setups, their question is actually about
>> some kind of transparent support. Say, ejabberd XMPP server written in
>> Erlang normally uses about 300 Erlang processes (with low server load)
>> and up to several hundreds of thousands of them under heavy load, and
>> programmers are not concerned with threading models at all: the Erlang
>> runtime preempts all these processes regardless of how many CPUs the
>> underlying hardware platform has.
[...]
> If the only problem with designing an application large enough to
> consume multiple cpus full time was transparent distribution of
> independent operations, that would be great. Usually the problems
> include resource sharing and synchronization. You can connect to
> "hundreds of thousands" of external clients, but can you connect to a
> local database for each connection? You might have to share a limited
> pool of such connections. Eventually the application falls under the
> same requirement: the developer has to make choices non-
> transparently.
> There is also the missing piece of the puzzle here: given that you
> have 100,000 clients, you can spend about 10 microseconds per second
> working for each client, or with 1 cpus, 160 us. If each database
> query consumed only 1 ms, it would take eight seconds to perform one
> query for each client on a 16 cpu box. Any application more
> sophisticated than a router would grind to a halt.

Well, you have managed to disprove a point I did not state.
Of course, you're absolutely correct on these points:
1) The need to share (slow) resources severely impacts any form of
concurrency;
2) Any application may end up being in a state which requires explicit
developer's choices about its implementation.
The problem is that you missed my point about Erlang: I did not try to
show that the concurrency concepts it exercises are a silver bullet, I
just shown that they're implicit, i.e. you don't have to arrange for
starting/stopping threads or creating thread pools, and with
dispatching units of work to them etc--the runtime takes care about
this for you.
Another point about Erlang's concurrency I made is that its light-
weight processes do not map 1:1 to OS threads, and this is again
radically different from Tcl.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: regsub (and regular expressions in general) trouble.
Next: How to call a tcl script (proc) from a vb.net.