tcl on multicore, what is the plan
gavino
What will tcl do as more apps run on 16 core box?
Alexandre Ferrieux
>
> erlang and haskell seems to have multicore capability.
> What will tcl do as more apps run on 16 core box?
Carry on while dozens of trolls explode in the skies, with beautiful
colours.
-Alex
tom.rmadilo
> erlang and haskell seems to have multicore capability.
>
> What will tcl do as more apps run on 16 core box?
You first need to write an application which can keep 16 cores busy.
After you write, or have funding for such an app: no problems.
The phrasing of your question implies that using multiple cores (using
threads) is something which is automatic and doesn't require any
programming effort. This is why I suggest you write an application
which can take advantage of threads, because it isn't a "no brainer".
With threads, you get what you pay for in programming effort. No
effort: no benefit.
Since Tcl supports threads, the ball is totally in your court.
Tcl Bliss
>
> What will tcl do as more apps run on 16 core box?
Did you miss the train again? ;)
Kevin Kenny
> erlang and haskell seems to have multicore capability.
>
> What will tcl do as more apps run on 16 core box?
Use thread::create fifteen times?
Donal K. Fellows
> gavino wrote:
> > What will tcl do as more apps run on 16 core box?
> Use thread::create fifteen times?
I'd probably use a thread pool (appropriately scaled) instead.
Donal.
pmarin
>
> What will tcl do as more apps run on 16 core box?
tcl does not use green threads like others ;)
tom.rmadilo
Thank goodness: No!
Since Tcl has a C API, it is easy to follow the typical pattern for
cross platform multi-threaded application development.
But developers who just use tcl scripting can remain blissfully
unaware of the gory details, just like they can ignore other platform
differences.
There are only a few main reasons to use threads: to allow blocking
channel i/o (usually easier to program), to take advantage of
additional processors, or to conserve/share memory (or other)
resources. In larger applications the advantage is the use of
different pools of specialized threads.
But if you read over the previous paragraph you might notice that the
burden falls on the developer of an application. The programming
language does not "figure out" how to distribute your code across the
available hardware. One of the problems with green threads is the
attempt to make this easy. The result is the need to create serialized
classes or methods which amounts to creating a "critical section" ...
the most expensive form of synchronization. Apparently you can't use
green threads to handle blocking i/o.
Green threads seem to be the product of hostility to an existing
solution and defects in the execution model of the language. Since
each Tcl interp is confined to a single native thread, no work is
expended trying to outsmart the developer. The Tcl execution model is
confined to a single interp, identical to the execution model of
native threads.
David Gravereaux
Konstantin Khomoutov
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.
And Erlang does not do this for sure (at least now)--it only allows
several its lightweight processes to run in parallel (Tcl also doesn't
have anything like this).
As to Haskell, I'm just not familiar with the details.
Donal K. Fellows
> 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.
Konstantin Khomoutov
<donal.k.fell...@manchester.ac.uk> 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.
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.
Donal K. Fellows
> 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.
tom.rmadilo
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.
Konstantin Khomoutov
[...]
>> 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.
tom.rmadilo
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.
Donal K. Fellows
> 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.
tom.rmadilo
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.
Donal K. Fellows
> 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.
tom.rmadilo
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.
Donal K. Fellows
> Very nice, but not magic.
Of course. "There is no magic." (Or is it just that we're the conjurers?)
Donal.
Uwe Klein
Clarke: any sufficiently advanced tech is indistinguishable from magic.
uwe
Andreas Kupries
> 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. :-)
coronet is also part of Tcllib (v 1.12+), and available through the
TEApot.
% teacup list coro
entity name version platform
------- --------------- ------- --------
package coroutine 1 tcl
package coroutine::auto 1 tcl
------- --------------- ------- --------
2 entities found
Note: This requires Tcl 8.6+.
> You need native threads (or multiple processors) to use a multi-core
> system properly. There's no way to poodle-fake that.
>
> Donal.
--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------