Prev: regsub (and regular expressions in general) trouble.
Next: How to call a tcl script (proc) from a vb.net.
From: tom.rmadilo on 24 Dec 2009 16:40
On Dec 24, 10:20 am, Konstantin Khomoutov <khomou...(a)gmail.com> wrote:
> 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.

Are you saying that Erlang provides no choice (totally implicit),
defaults with the potential for overrides (configuration), or extra
language syntax. The best answer is configuration with defaults, since
application behavior can be adjusted without code changes. The other
two choices are horrible. (But the last can be converted into the
middle option.) The middle answer is also typical of an application
server, such as AOLserver (or even tcl's thread API) which has the
qualities you describe...except that threads are directly mapped. With
Tcl you can have multiple interps per thread as well, and each interp
can have an event loop.

The one thing Erlang, Tcl and all of these systems have in common is a
layered controller API. If you eliminate or reduce access to this
layered API, you eliminate or reduce functionality. The other option
is you reflect the functionality upward and combine it into fewer
layers.

Personally I think it is useful to become familiar with the many ways
to express the same idea, but for instance, base 10 requires ten
different symbols, or an equivalent number of symbols and rules. I'm
not sure why anyone things computer programming languages would be any
different.

From: Donal K. Fellows on 24 Dec 2009 17:14
On 24 Dec, 21:40, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
> Are you saying that Erlang provides no choice (totally implicit),
> defaults with the potential for overrides (configuration), or extra
> language syntax.

I think it's no choice at the language level, and configuration at the
runtime level. That would fit with the model of where it came from
(telecoms). I don't know if it allows you to tune up or down the
number of OS threads used at runtime.

Donal.
From: tom.rmadilo on 26 Dec 2009 12:31
On Dec 24, 2:14 pm, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:
> On 24 Dec, 21:40, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote:
>
> > Are you saying that Erlang provides no choice (totally implicit),
> > defaults with the potential for overrides (configuration), or extra
> > language syntax.
>
> I think it's no choice at the language level, and configuration at the
> runtime level. That would fit with the model of where it came from
> (telecoms). I don't know if it allows you to tune up or down the
> number of OS threads used at runtime.

This is actually a pretty interesting language, not unlike Tcl in a
number of ways: close ties to C for stuff that has to be very fast,
actually supporting a shell, nothing precompiled, ability to replace
code in a running system, great error reporting. It is obviously
optimized for applications which manage many independent, relatively
simple processes. Of course, that is a very good way to write an
application: break it down into independent chunks.

But one mystery was how automatic this runtime constructed itself. The
FAQ helps out a little. Apparently Erlang has several high level
concepts: systems and nodes. Seems like a node is the smallest
controller unit. You can run one node per processor to take advantage
of extra hardware. Beyond that the node processes can communicate with
each other and other nodes' processes via the same mechanism of
message passing. Nodes in a system can be distributed across different
machines transparently...I assume to transparently to the nodes/
processes.

Also, the language has at least one primitive for dividing work into
independent units: spawn. Erlang seems like a specialized operating
system with a generic form of IPC and several layers of job control.
From: Donal K. Fellows on 29 Dec 2009 06:33
On 24/12/2009 14:27, Konstantin Khomoutov wrote:
> So, to sum it up:
> 1) Tcl is ready for SMP/multicore setups in that has support for OS
> threads.

It's a build-time option. On some platforms it's on by default. On
others, it's not (for historic reasons).

> 2) But this requires explicit coding approaches because Tcl has no
> concepts which make using of threads implicit.

If you can describe your tasks as self-contained work-units, you can use
a thread pool, which is supported by the Thread package. That makes it
easy to separate the management (pool scaling, communications, etc.)
from the work itself. However there's no totally automatic mechanism
because that requires a different memory model (with other penalties).

Donal.
From: tom.rmadilo on 29 Dec 2009 15:52
On Dec 29, 3:33 am, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:
> On 24/12/2009 14:27, Konstantin Khomoutov wrote:
>
> > So, to sum it up:
> > 1) Tcl is ready for SMP/multicore setups in that has support for OS
> > threads.
>
> It's a build-time option. On some platforms it's on by default. On
> others, it's not (for historic reasons).
>
> > 2) But this requires explicit coding approaches because Tcl has no
> > concepts which make using of threads implicit.
>
> If you can describe your tasks as self-contained work-units, you can use
> a thread pool, which is supported by the Thread package. That makes it
> easy to separate the management (pool scaling, communications, etc.)
> from the work itself. However there's no totally automatic mechanism
> because that requires a different memory model (with other penalties).

I have to admit that Erlang is a very promising language. But it
doesn't have support for widely available databases, so it isn't
useful to me as a general purpose tool. Maybe it could be used as a
caching component for reuse of expensive data objects. AOL had several
high performance backends: one called SOB: small object and another
called NV: network variable.

But on further reading of the best practices for Erlang, it is very
clear to me that processes are explicitly created (or at least
assigned), and they are usually associated with modules (the process
is named after the module). This somehow aids message passing. Another
best practice is to separate "pure functions" from those with side
effects. Guess what is included in side effects: creating a process.

Anyway, the bottom line is that the implicit process creation idea
(implicitly dividing code into independent parts) isn't true, and this
is a good thing. It isn't necessary, and it may be impossible. Using
extra hardware (cpu cores) is also a choice.

Erlang is a very well structured programming environment which makes
distribution of your application across multiple cpus or physical
machines easy. But it isn't yet clear to me if this is a feature of
the language or the library code (standard library modules). I'm
guessing the latter. In the case of Erlang, the standard library
includes a high level application server. Very nice, but not magic.
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.