Tcl on Multi-Processor Server
KevinO
Several years ago I wrote a paging application: it runs as a server
which receives requests from other monitoring applications to page
system admins. When such a request is accepted, it connects to paging
vendors (SkyTel, Archwireless, etc.) using SNPP/WCTP. The program is
simple, single-threaded, event based, running on a single-processor
PC.
This application has been migrated recently to a 4-processor Wintel
server, Tcl/Tk 8.4.19. It is working as expected. Questions
(hypothetical?):
1. Is there anything that can be added to the program to take
advantage of the new platform?
2. Assuming extremely high load, will more than one processor be
engaged?
3. Is there anything that can be programmed to force Q #2 to be Yes
even in low loads?
Many thanks
KO
Donal K. Fellows
> 1. Is there anything that can be added to the program to take
> advantage of the new platform? 2. Assuming extremely high load, will
> more than one processor be engaged? 3. Is there anything that can be
> programmed to force Q #2 to be Yes even in low loads?
Excellent questions.
1. Yes.
2. If you write the code right.
3. Who cares?
To expand...
Tcl binds each interpreter to a single OS thread, though a thread can
have any number of interpreters. Thus, to take advantage of a multi-core
system you need multiple explicit threads of execution. You can do this
by either using processes or threads; in the latter case, we recommend
the use of the Thread extension (in a thread-enabled build of Tcl, of
course). The easiest way to use the thread extension might be to think
in terms of spawning worker threads or managing a thread pool.
BTW, the binding of threads and interpreters like that is a pretty neat
thing, since it means that Tcl hardly needs any locks at all; your code
really will use that multi-core system to the full if needed. OTOH, it
also means that doing shared data structures can be tricky (despite the
tools provided by the Thread package); message passing (rather like Tk's
events or [send]) works much more naturally.
Once you've spawned the threads, they'll spread across the multiple
processors naturally (unless the OS decides otherwise, of course),
especially at high loads. At low loads it hardly matters; all cores will
spend the majority of their time idling anyway. :-)
Donal.
KevinO
Donal
Thank you very much for the quick response and insight.
There is a lot of homework here for me...
KO
google...@rocketship1.biz
You mentioned this is for a Wintel system. If this means windows
2000 on up, I would recommend you look at sysinternals.com and
find procexp.exe a very nice process/thread monitoring tool.
One item of particular use would be the option to right click on
a process name and select the "processor affinity" option. This
brings up a set of checkboxes where you can specify just which
processor(s) (in a dual or quad core system) you want to permit
the process to use. With this, you can force a process to use
some lesser set of cpu cores than you have available. This would
let you see, for example, if multiple cores makes the application
run faster (clock time).
Alexandre Ferrieux
While there's nothing to add to Donal's description of course, may I
ask whether it makes sense to make the metal scream for this specific
application ? I mean, does a paging gateway really _want_ to send
thousands of messages per second continuously ? Otherwise, assuming
"bursts", and considering the intrinsic latencies of cellular
networks, are you really after microseconds ? Doesn't a single 500Mhz
486 suffice for the job ?
-Alex
KevinO
wrote:
To googlegro...:
I have not looked into your suggestion yet, but if it works (for me),
it will allow me to take advantage of the multi-CPU system until I get
the hang of using Tcl Threads as Donal suggested above.
To Alexandre:
You are absolutely right. The paging system has been running
flawlessly on a ~600MHz for almost 5 years. The move to a multi-CPU
system was not made by me, it was based on the age of the current
server (7 years), and the server of choice is an old one anyway.
My posted question was more for educational purposes than technical.
Having said that, I hope that this will be an impetus to study Tcl
Threads, just in case...
Many thanks to you all!
KO
Cameron Laird
KevinO <kevi...@yahoo.com> wrote:
.
.
.
>flawlessly on a ~600MHz for almost 5 years. The move to a multi-CPU
>system was not made by me, it was based on the age of the current
>server (7 years), and the server of choice is an old one anyway.
.
.
Aieee! You just got it burned in, and now you're scrapping a key
component that has been verified?!
I know, it's not you personally. The real content of this follow-
up is to observe that different domains have different attitudes
about depreciation. Some people sincerely believe that a computer
over a year old is aging. Some sincerely regard any system that
hasn't been in production continuously for at least five years as
unproven. 'Guess I'm glad there's room for us all.
Alexandre Ferrieux
>
> You are absolutely right. The paging system has been running
> flawlessly on a ~600MHz for almost 5 years. The move to a multi-CPU
> system was not made by me, it was based on the age of the current
> server (7 years), and the server of choice is an old one anyway.
> My posted question was more for educational purposes than technical.
That't a bit strange. Normally optimization tries to cure insufficient
CPU muscle, not the other way around. Your old code must be _flying_
on the new hardware...
> Having said that, I hope that this will be an impetus to study Tcl
> Threads, just in case...
Wrong method. If you learn threads on a case that is a perfect target
of event-driven programming, you'll (1) likely acquire dangerous
habits and (2) increase by several orders of magnitude the risks of
getting it wrong. Someday you'll load a random DB extension which is
not thread-safe and then just wish you hadn't made that move...
-Alex
Donal K. Fellows
> You are absolutely right. The paging system has been running
> flawlessly on a ~600MHz for almost 5 years. The move to a multi-CPU
> system was not made by me, it was based on the age of the current
> server (7 years), and the server of choice is an old one anyway.
> My posted question was more for educational purposes than technical.
> Having said that, I hope that this will be an impetus to study Tcl
> Threads, just in case...
Well, for your own education feel free. But for the actual business of
using that new harder, consider using virtualization so that you can
have multiple virtual servers running on it. Many of our key production
systems (and those of lots of other companies that I know of) are highly
virtualized. But such things are really outside the domain of Tcl, which
is focussed mainly in the application space. (OK, you can argue about
the degree to which Tcl virtualizes itself, but that's a discussion for
another thread...)
Donal.
Donal K. Fellows
> using that new harder,
The missing word is 'server'. D'oh!
Donal.