[geeks] forking stupid interpreters
David Cantrell
david at cantrell.org.uk
Mon Mar 25 05:14:40 CST 2002
On Sun, Mar 24, 2002 at 06:45:46PM -0500, Greg A. Woods wrote:
> [ On Sunday, March 24, 2002 at 23:22:23 (+0000), Mike Meredith wrote: ]
> > Subject: Re: [geeks] forking stupid interpreters
> >
> > You've totally missed my point ... an interpreter isn't a problem if it
> > is embedded, or running as a daemon process. As my example of running a
> > Perl-based adzapper on a web cache illustrated.
>
> No, I didn't miss any point -- I saw right through it (far deeper than
> you might imagine! :-)
>
> If a compiled-to-machine-code program can do in a million cycles what
> your perl script requires a billion cycles to do, which is better?
who cares when both take so little time.
> Do you really want to run something that can be 2-3 orders of magnitude
> slower (even un-forked) when throughput is your issue?
To say that perl is two to three orders of magnitude slower than compiled
C is simply not true. One order of magnitude maybe, in pathological cases.
> If you don't want spam then don't accept mail from known spammers and
> open relays -- i.e. don't let it in the door in the first place.
This is over-simplistic. The vast majority of spam I get is neither from
known spammers nor from open relays. So tell me, how am I to kill those
without having to do it manually? The only way I can see is by applying
heuristics to the mail, which is going to be computationally expensive. If,
of course, you in your infinite wisdom have a better way, I trust you will
enlighten us poor lost souls.
> If you don't want virii and worms to run wild on your network then don't
> run vulnerable software (and fix bugs when you hear rumours about them,
> not once they've been exploited! ;-)
If you expect this good advice to be followed rigourously, then I can only
assume that you have never worked in the IT group at any large company.
Good practice is to have several lines of defence. Yes, keep your software
up to date; yes, avoid using vulnerable software unnecessarily; but it is a
fool who thinks that doing so avoids the need for blocking and de-fanging
suspicious-looking mail.
> Then you'll have lots of cycles left over to fork umpteen thousand
> perl/java/whatever scripts to filter and sort and manage your legit email.
As he said, you miss the point. He said he's running it as a daemon with
no forking. True, the startup cost of languages like perl is high, as it
has to load a large compiler/interpreter, and compile the program before
it starts to run, but once it is running it is FAST. Running as a daemon
means that the startup time is irrelevant.
You would do well to read the study at:
http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
There you will see evidence that compiled languages are not all that they
are cracked up to be. Looking at perl in particular, it seems to produce
runtimes of the SAME order of magnitude as C, consume the same amount of
memory, require less code, and require less programmer time.
In particular, the author says:
" the so-called 'scripting' languages Perl, Python, Rexx and Tcl can be
reasonable alternatives to 'conventional' languages such as C or C++
even for tasks that need to handle fair amounts of computation and
data. Their relative runtime and memory consumption overhead will often
be acceptable and they may offer significant advantages with respect to
programmer productivity. "
and
" interpersonal variability, that is the capability and behaviour differences
between programmers using the same language, tends to account for more
differences between programs than a change of the programming language. "
although he also says that the results may not be generalisable to
different applications from that which he was testing with.
--
Grand Inquisitor Reverend David Cantrell | http://www.cantrell.org.uk/david
o/~ I want my SMTP o/~
More information about the geeks
mailing list