How fast is the Python interpreter?
Paul Pedriana
I want to embed the Python Interpreter in an app. While
speed is not my most primary concern, I would like to
know how Python fits relative to other interpreted
languages.
Here are some alternatives I'm considering. How would
they rank in terms of runtime speed? I've already taken
a fairly ignorant stab at a relative order below, from
fastest to slowest, but I could be way off, since I'm
not language expert by any means.
Prolog
Lisp
Scheme
Lua
Basic
Python
Interpreted C
Java
It is partly of concern because it would be embedded
into a game. OTOH, if I wanted a lot of speed, I'd
possibly invent some dumb language like that old INF
format or something....
Thanks
Paul Pedriana
pped...@maxis.com
pa...@ccnet.com
Mike Pelletier
On Sat, 3 May 1997, Paul Pedriana wrote:
> if I wanted a lot of speed, I'd
> possibly invent some dumb language like that old INF
> format or something....
I hope you're not refering to Inform; it's a thriving, powerful, and
surprisingly elegant language!
Mike.
Aaron Watters
pa...@ccnet.com (Paul Pedriana) wants to know
the relative speed of:
> Prolog
> Lisp
> Scheme
> Lua
> Basic
> Python
> Interpreted C
> Java
external code.
This depends entirely on what conclusion
you want to come to. You can probably
argue that any one of them is faster than
the others if you really want.
Which one do you want to win? I'll come
up with an argument to match your prejudice.
On the other hand what do you want to do
and how much effort do you wish to apply
to obtain reasonable speed? I'd argue that
you'll get it running sooner using Python, and
you can spend all that extra time tuning the
hot spots for greater performance using one
trick or another.
Of course, everything can always be faster,
and the grass is always greener... -- Aaron Watters
===
I wanna be Madonna but the price is too high.
-- Sheryl Crow
Guido van Rossum
> pa...@ccnet.com (Paul Pedriana) wants to know
> the relative speed of:
> > Prolog
> > Lisp
> > Scheme
> > Lua
> > Basic
> > Python
> > Interpreted C
> > Java
> particularly in environments with embedded
> external code.
Hmm, this question seems to make about as much sense as the question
which car gets you to work faster:
Pick-up truck
Minivan
Porsche
Ford Contour
Geo metro
(And I don't even mention the Ferrari F1, the delivery van, and the
18-wheeler truck combination, just as you wisely left off C, C++ and
Ada -- all the cars in my list could get me to work.)
In other words, the choice between those languages depends on the
problem you have at hand, not so much on which one is faster. The
choice also depends (to some extent) on your budget, compatibility
requirements, what's available for your platform, what you're familiar
with, and a few other random things like support and perceived
reliability. Speed comes in last, just like my commute wouldn't be
any faster or slower with any of those vehicles -- it happens to be
bound by other traffic and stop lights.
(And as they say, your mileage may vary. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
Paul Pedriana
Well, I knew I was going to get an answer like
this. But at the same time, I still believe that
for simple token parsing and execution of a
typical mix of logic and math, there is probably
a decent generic order that could be given.
The automobies you give below are all very close
to each other in performance on the open road,
whereas you could have picked a much wider range,
like this:
rollerblades
bicycle
Pinto
bus
Ferrari
garbage truck
In this case, I believe I could construct a pretty
reasonable order of time it would take for you to
get to work, and there's a pretty good chance that
the Ferrari would get you there first and the blades
would get you there last.
If you are saying that these embeddable interpreters
are in fact very similar, then the complex answer
("it depends on a million things") is much more
significant.
I'm sorry, but for my situation, speed is critically
important. If one is three times as fast as the other
at executing simple logic, that is a truly massive
difference in my application. Each of the languages
in my list work within the parameters you mentioned,
(budget, compatability, platform availability)
and one of the things that's left is execution speed.
If the app was driving on city streets and not the
racetrack, I wouldn't even have posted the question.
The app is in fact on the racetrack.
Games are programmed in assembler and C because they
need to be fast above all. Neither assembler nor C
are very portable, but that isn't important to us.
Please don't try to tell me that C is very portable.
Paul
pa...@ccnet.com
----------
From: Guido van Rossum[SMTP:gu...@cnri.reston.va.us]
Sent: Monday, May 05, 1997 8:16 AM
To: Aaron Watters
Cc: pytho...@cwi.nl; pa...@ccnet.com
Subject: Re: How fast is the Python interpreter?
E. Young
pa...@ccnet.com (Paul Pedriana) writes:
> I want to embed the Python Interpreter in an app. While
> speed is not my most primary concern, I would like to
> know how Python fits relative to other interpreted
> languages.
>
> Here are some alternatives I'm considering. How would
> they rank in terms of runtime speed? I've already taken
> a fairly ignorant stab at a relative order below, from
> fastest to slowest, but I could be way off, since I'm
> not language expert by any means.
> Lisp
> Scheme
> Lua
> Basic
> Python
> Interpreted C
> Java
>
> format or something....
The answer is a resounding "it depends", but you apparently don't
want to hear that, so here are a few suggestions. Bear in mind that
I haven't done any serious comparative benchmarking.
The first thing to note is that I'm not aware of embeddable
implementations for any of these languages other than Lua and Python.
I know Lisp can be embedded (after all, emacs does it), but I
don't know how easy it is. I've never seen a C interpreter in the
wild, so I haven't any idea about that either. If anyone's tried
embedding any of the other candidates on your list, I'd be interested
to hear about it. It's all very well to say "Language X is really
fast", but if it won't do what you want that's irrelevant.
Second, don't you mean "from slowest to fastest"? Prolog is a great
language, but speed isn't exactly one of its strong points. (That
should bring up some flames ;) Theoretically, Java and BASIC ought
to do quite well on the speed front due to static typing, but it's
only a theory. You also need to consider a few more things:
1) Controllable garbage collection. You need to make sure you can
tell your language when to garbage collect and make sure it does so
in small chunks, or your game could freeze at random points.
2) User-friendly syntax. If you want gamers to write stuff in this
language, it had better be completely obvious how to do it.
3) The most important factor determining speed here is the level
of detail at which the interpreter calls your C code. If you call
a routine a few times per frame, you'll be fine. If you call it
for every polygon (or whatever) you'll drown, whatever the language.
Out of the two languages I've actually tried embedding, (Lua and
Python), I'd suggest Lua in your case. Execution speed is roughly
comparable between the two, but lua is much smaller; it'll only
add about 50K to your executable size. I much prefer python for
writing my own scripts, but it could be a bit heavyweight for
your purposes.
HTH,
-Edwin
Fredrik Lundh
> Each of the languages in my list work within the parameters you
> mentioned, (budget, compatability, platform availability) and one of
> the things that's left is execution speed.
Since Python is very dynamic, it is pretty slow compared to the other
contenders. So if you're going to implement most of the game logic in
it, it's probably too slow. If you're going to control the graphics
(on a medium to low level), you're definitely out of luck. But if
you're only going to control the game engine, its probably fast
enough.
(for example, we're using Python in time-constrained image processing
systems, as well as in video capture/display systems, but in these
cases, the actual image processing is done by C/C++ libraries. Python
provides the glue and the application framework)
For your application, I'd guess Java with a JIT compiler would give
the fastest code. Without a JIT, it's harder to tell, but statically
typed/bound languages (Java, Lua?) should be faster than dynamically
typed ones (Scheme, Lisp, Python). There's probably fast Scheme stuff
available, but don't ask me where to look; the Lisp/Scheme folks
doesn't seem to like focussing on a single free implementaion like
most other language crowds do...
But to be really sure, you'll probably have to benchmark a few typical
cases. And if you come up with such stuff, we can surely tell you how
to make it run as fast as possible in Python!
> Please don't try to tell me that C is very portable.
Well, as long as you have a compiler, ANSI C is surely portable enough
for most people (tried C++ or JavaScript lately? ;-)
Cheers /F
Aaron Watters
> Games are programmed in assembler and C because they
> need to be fast above all. Neither assembler nor C
> are very portable, but that isn't important to us.
Still, the question remains, what are you doing, more precisely?
If you really have to do zillions of ad hoc floating point calculations
Python, without a lot of special purpose C support, is frankly
not recommended. On the other hand if you are doing raster
sprites or even 3D geometry (which has a well defined and
uniform underlying operations) then Python with a little bit
of C support may be about as fast as anything (since you'd spend
most of your time in standard aggregate subroutines in any
implementation). I can't say for certain, but much of the C
support may already be available (from, eg, Numeric and PIL and
elsewhere). Bare core Python, clearly, would not be
appropriate for what you want, but other languages with
less useful C API interfaces may be a worse mistake if
you need to rely on C-level efficiency in any case.
Understand that the Python interpreter does a lot of work
for you, at some cost, but if you can modularize your app
so that the critical calculations are performed in the
aggregate in C implementations, Python will be very nice.
If you can't, Python may be a mistake, since speed is
such a critical concern for your app. There is a reverse
effect, IMO, where you start doing a lot of work that
Python might have made easy and efficient using
gargantuan amounts of inefficient ad hoc code in languages that
make, say, marshalling and archiving difficult.
It's unclear to me exactly where the dividing line is.
Maybe one of the Numerics fans can comment. If I
have an App which mainly manipulates 3d vectors
using standard operations (mainly individually) , is the
interpreter overhead unduly cumbersome?
Wish I could give a simple "yes" or "no". Sorry.
-- Aaron Watters
===
Sara had 9 spiders. She wanted to put an equal
amount of spiders in 3 friends' lunchboxes. How
many spiders did she put in each lunchbox?
[been helping my kid with homework again.]
Guido van Rossum
> The automobies you give below are all very close
> to each other in performance on the open road,
That was exactly my point.
> whereas you could have picked a much wider range,
> like this:
> rollerblades
> bicycle
> Pinto
> bus
> Ferrari
> garbage truck
>
> In this case, I believe I could construct a pretty
> reasonable order of time it would take for you to
> get to work, and there's a pretty good chance that
> the Ferrari would get you there first and the blades
> would get you there last.
You don't know my commute :-) The Ferrari would have to take a much
longer route than the blades or the bike, and the Ferrari would
probably make it in the same time as the Pinto.
> If you are saying that these embeddable interpreters
> are in fact very similar, then the complex answer
> ("it depends on a million things") is much more
> significant.
Yes (with the exception of Prolog, which seemed to be the "which one
doesn't belong in this list" exception).
> I'm sorry, but for my situation, speed is critically
> important. If one is three times as fast as the other
> at executing simple logic, that is a truly massive
> difference in my application. Each of the languages
> in my list work within the parameters you mentioned,
> (budget, compatability, platform availability)
> and one of the things that's left is execution speed.
> If the app was driving on city streets and not the
> racetrack, I wouldn't even have posted the question.
> The app is in fact on the racetrack.
Then your only recourse it to write a small game in each language and
see how fast you can get it. Here's one reason why it's hard to
compare speed: if you happen to need a fast hash table mapping lots of
strings (or more complex values) to some other data type, the fact
that Python has it built in (and as far as I know, neither Lua nor
Java have an equivalent built-in type), Python wins. If on the other
hand you spend most of your time calling small functions, Python
loses.
> Games are programmed in assembler and C because they
> need to be fast above all. Neither assembler nor C
> are very portable, but that isn't important to us.
> Please don't try to tell me that C is very portable.
I'm not sure how you meant that. But never mind.
Konrad Hinsen
"Aaron Watters" <a...@dante.mh.lucent.com> writes:
> It's unclear to me exactly where the dividing line is.
> Maybe one of the Numerics fans can comment. If I
> have an App which mainly manipulates 3d vectors
> using standard operations (mainly individually) , is the
> interpreter overhead unduly cumbersome?
I guess it depends on what you call "unduly". The overhead would
certainly be noticeable, to the point where interpreter time would
exceed calculation time, although not by orders of magnitude.
My main Python application, the Molecular Modelling Toolkit, has many
operations whose execution time is dominated by 3d vector operations,
using a 3d vector class which is largely a wrapper around NumPy arrays
(it's at http://www.yi.com/home/HinsenKonrad/python.html). In most
cases this is fast enough even for interactive work, but I am
considering reimplementing the wrapper in C. However, I am not
at all considering moving higher-level operations to C.
Also note that the situation gets a lot better for performing
a single operation on a large number of 3d vectors in parallel,
since they can be put into a single array. Another Python wrapper
keeps the illusion of individual vectors. I am even doing
numerically intensive calculations that way with no performance
penalty.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
Scott Ellsworth
In article <01BC5A7A...@h96-150.ccnet.com>, Paul Pedriana <pa...@ccnet.com> wrote:
>Well, I knew I was going to get an answer like
>this. But at the same time, I still believe that
>for simple token parsing and execution of a
>typical mix of logic and math, there is probably
>a decent generic order that could be given.
I would be surprised if you could specify an order without specifying just
what your mix of logic is. If you are using matrix manipulation, for
example, the numerical extensions make Python quite fast at certain tasks.
Most of the languages you mentioned can be extended with varying amounts of
pain, so you can likely make any of them fast enough.
Perl lets you write very terse regex code. One can write similar regexes in
Python. Python lets you write fairly powerful expression over lists,
dictionaries, and tuples. I am told one can write similarly powerful
constructs in Perl, but Python will make them more maintainable. I cannot
speak about that from experience, as I do not do Perl much, but if your app
does not factor well into objects, and it does not need the kind of expressive
power Python is good at, then Python may not be the language. If you do, then
it may be.
..
>I'm sorry, but for my situation, speed is critically
>important.
Speed at doing what? If the entire application needs to be fast, then you are
going to be writing assembler, period. If, on the other hand, your
application falls in the usual 90-10 area, where the 10 percent of the code
that takes up the vast majority of the time is the real problem, then you
have a lot of options. Python can be extended fairly easily, which is a plus
point if the area in which you will need speed is fairly well contained.
Basic is not easy to extend in C in general. Therefore, if you absolutely
need to have a lot of speed in a small area of the application, and are
willing to write C or assembler to handle the truly fast bits, then your
overall implementation language should be Python over Basic.
> If one is three times as fast as the other
>at executing simple logic, that is a truly massive
>difference in my application.
Once again, what specific simple logic? This is not a facetious question - I
have found different implemetations of Python vary wildly in file IO speed,
based on the speed of the underlying C libraries at doing the basic file IO.
Specify platform and application, and it is more likely that people will be
able to talk to you intellegently.
I, for example, have used Python primarily for file munging. It competes well
in my area with Perl, and is far faster to write things in than C++, my
primary langauge. I have no fear of using Python to manipulate files up to
the size of my physical memory, and the profiler in it is good enough to tell
me what needs real optimization under Linux. The profiler has not been very
useful under PythonWin.
..
>The app is in fact on the racetrack.
Which means that part of your code is going to likely have to be hand tuned C
or assembler. With any luck, that part will be in the underlying libraries,
but if speed is as important a concern as you say, then you will be extending
your chosen language. It comes down, then, to how well the language proposed
lets you get the rest of the project together, leaving you time to optimize.
For my applications of system administration and file maninpulation, Python is
fast enough to do everythng I need without custom code, but I am usually only
working with files of up to 32 megabytes, and then usually just single passes,
not n^2 searches.
>Games are programmed in assembler and C because they
>need to be fast above all.
FWIW, I know of a chap who is doing an interactive 3D game in Python. He has
special C code to handle the screen updates, but all game mechanics are
handled by a rather intricate family of Python scripts. His comment was that
this was the only way he could keep the code straight and maintainable.
Especially because the game code is not as interesting to him as the content.
> Neither assembler nor C
>are very portable, but that isn't important to us.
>Please don't try to tell me that C is very portable.
Afraid I am going to, partly to bring out whether your needs match the Python
feature set.. C has been one of the more portable things I have used. Python
has been more portable for a larger area of problems, but if you are claiming
that C is not portable, then you and I might have different standards of
portability or of code design. I am usually willing to accept a ratio of
common to platform code of 90-10. Others I know will only accept ratios of
99-1 or better, which makes Python a better choice for the network
applications they are doing than C, despite speed concerns. Once again, your
needs will make a big difference. For example, I do not yet know of a
Macintosh Eiffel, which means that if your portability concerns include Mac
work, Eiffel is right out. Python shows up on the supported platforms fairly
quickly, which might make a strong argument for it.
Further, the Python source can be manipulated, which might be a big point for
it. Guido cannot change licenses and start charging, further, if you
disagree with the direction he starts to go with it, you can freeze
Python and have the source to play with regardless of what happens with
Python, and without having to fear derived work lawsuits.
Scott
Scott Ellsworth sc...@eviews.com
"When a great many people are unable to find work, unemployment
results" - Calvin Coolidge, (Stanley Walker, City Editor, p. 131 (1934))
"The barbarian is thwarted at the moat." - Scott Adams
James Logajan
Fredrik Lundh (Fredri...@ivab.se) wrote:
: Without a JIT, it's harder to tell, but statically
: typed/bound languages (Java, Lua?) should be faster than dynamically
: typed ones (Scheme, Lisp, Python).
Lua belongs in the dynamically typed group.
Paul Pedriana
OK, I like the answers that people have posted.
Of course the answer depends on the application, and
I was hoping that people could tell me what kind
of things cost a lot in Python and what things
don't. Many of the answers dealt with this. It
would be impossible for me to describe or even
know at this point exactly what the constraints
will be.
Most of the app is in C/C++/assembler. The only
reason why I want to embed a scripting language
is to be able to implement some high level control
after the app ships and to allow others to do the
same. The speed issue comes into play when people
ask me if the scripting language could possibly
be used as well to implement some of the high-level
AI of the app. At that point, speed of interpretation
starts to become significant.
Thanks a lot!
Paul Pedriana
Maxis
James Logajan
Paul Pedriana (pped...@maxis.com) wrote:
: Most of the app is in C/C++/assembler. The only
: is to be able to implement some high level control
: after the app ships and to allow others to do the
: same. The speed issue comes into play when people
: ask me if the scripting language could possibly
: be used as well to implement some of the high-level
: AI of the app. At that point, speed of interpretation
: starts to become significant.
Before I get flamed for suggesting anything other than Python, I should
point out that I just recommended Python for a commercial application
requiring 7x24 uptime.
If you want a simple but fast (and small!) scripting language, I would
suggest that you take a look at Lua. See:
http://www.inf.puc-rio.br/~roberto/lua.html
I recommended Python over Lua mostly because we will be using it as more
than just an extension or embedded language. The OO nature of Python will
pay off better in the long-run. (Lua can fake OO a bit, though.)
Andrew P. Mullhaupt
Aaron Watters wrote:
> Still, the question remains, what are you doing, more precisely?
> If you really have to do zillions of ad hoc floating point calculations
> Python, without a lot of special purpose C support, is frankly
> not recommended.
Actually, with the numerics extesions and proper linking in a good
LAPACK/FFTPACK (e.g. the Sun Performance Library) Python will
frequently be faster than most people's C or Fortran, even using the
same fast library for a lot of traditional Scientific Computing
applications. The reason for this is that the leverage of using the
higher level language encourages the rapid development and tuning
of algorithms which cost to much to develop in the lower level language
to spend as much time and care on them. Furthermore, you can replace the
memory management in Python yourself, and this allows great advantages,
but would be too painful to do on a retail (program by program) basis
which C and Fortran more or less force on you. In this direction, Konrad
Hinsen and I have made a baby step - we replaced the malloc used for
Numerical Python array data with an anonymous memory map, and in my test
application I observe speed ups of about a factor of two. Most C and
Fortran programmers do not understand how to do this, and so, for things
which can be sped up by using lots of memory, but where malloc/free are
not up to the task (and they never really are) Python, or another easily
modified extensible interpreter, (such as R (yet another one letter
language)), will most likely win.
> It's unclear to me exactly where the dividing line is.
> Maybe one of the Numerics fans can comment. If I
> have an App which mainly manipulates 3d vectors
> using standard operations (mainly individually) , is the
> interpreter overhead unduly cumbersome?
The situation you describe 'mainly individually' _would_ be
a prohibitive bar - the overhead of the current Python implementation
will kill you. Note that adaptive JIT style 'compilation' of such a
thing will frequently give the interpreter the edge since it can make
the decisions as to how to generate code at _run time_ rather than
at compile time.
Another thing about 'mainly individually' is that usually you can
get around this by inventing a new algorithm, or even more frequently,
rediscovering an old but somewhat overlooked algorithm.
Here is a classic example - generating a Krylov matrix. The trick
used here may seem special to this case, but in fact can be used
extensively in signal processing code. This is normally a case where
people resort to a C extension. I am using the S language
since I have this lying around the house, and do not have time to
convert to Numerical Python. But the trick will do just as well.
The Krylov matrix of order n generated by a matrix A and vector b
has the columns b, Ab, A^2b, ..., A^(n-1)b. If you come from the
world of Fortran and C style programming, you will usually use the
following algorithm (given here in S):
ssirm <- function(A, b, n)
{
d <- length(b)
X <- array(B, c(d, n))
for (i in 2:n) X[,i] <- A %*% X[,i]
return(X)
}
and you will think not that much more about it. But you would be
mistaken to transliterate this into C or Fortran and be happy; you
are probably going to get appallingly short vectors/pipelines if you
have d << n but it will be fast enough that you might not notice. In
S, (or Python, or most other interpreters that do not get really
hard core about realizing that the loop should be compiled and that
there is no real doubt about unrolling the thing, either.
However, if you actually use _this_ approach you are likely to be
quite disappointed with the result, if not moved to leave the known
universe.
A much better idea is to use:
ssirm2 <- function(A, b, n)
{
X <- cbind(B, A %*% B)
dx <- 2
while (dx < n/2) {
A <- A %*% A
X <- cbind(X, A %*% X)
dx <- dx * 2
}
A <- A %*% A
return(cbind(X, A %*% X[ ,1:(n-dx)]))
}
What this does is unroll the main loop by successively larger
and larger pieces - while doing the startup for each succeeding
loop as the work of the current loop. It's not that much of a
trick, but we have essentially reduced the 'interpreter overhead'
to a negligible level, since the number of times the interpreter
makes a decision about what to do in the loop is O(log n) as opposed
to O(n). The same goes for the number of assignments. Furthermore, we
now have larger and larger matrix multiplications (the A %*% X ones)
and since these are handled by the highly optimized (and in my case
parallelized) routines this function will run essentially at full
bandwidth. It will normally beat a 'casual' C or Fortran implementation
flat, in addition to being _much_ easier to write and, when the time
comes, modify.
Here are two timings, where A is 32x32, and n = 2^14:
User Sys Real
ssirm: 102.6 0.25 103.0
ssirm2: 2.7 0.28 3.0
You can easily notice this difference.
In case this example seems contrived, this is actually a function I
use frequently in my research. The technique is not limited to the
Krylov matrix, either. One of the _banes_ of the array interpreter
languages is the application of a recursive filter to data. At first
sight, a sequence defined by the relation:
y[t] = a[1]*y[t-1] + ... + a[d]*y[t-d] + x[t]
for t=d, d+1, etc. appears to have a computational dependency which
prevents unrolling - and I have not found a compiler that can do the
trick. However, the trick I have outlined above is applicable here, too.
Now this is one case of 'mainly individually' which turns out to be 'not
individually at all'. This _usually_ happens in scientific computation.
And it is indeed worth some effort if you depend heavily on some
particular piece of code for performance - and the great advantage of
high level languages is that they make it easy to develop clever
approaches to the nasty bits and even easier to get the noncritical bits
out of the way.
Later,
Andrew Mullhaupt
Andrew P. Mullhaupt
Andrew P. Mullhaupt wrote:
There is a typo in my code sample.
> ssirm <- function(A, b, n)
> {
> d <- length(b)
> X <- array(B, c(d, n))
The following line:
> for (i in 2:n) X[,i] <- A %*% X[,i]
should instead read:
> for (i in 2:n) X[,i] <- A %*% X[,i-1]
> return(X)
> }
>
The code used in my timings was correct.
Sorry for any confusion this may have caused.
Later,
Andrew Mullhaupt
Andrew P. Mullhaupt
Manfred Bartz wrote:
>
> "Andrew P. Mullhaupt" <amul...@ix.netcom.com> writes:
>
> > .......................... Python, or another easily
> > modified extensible interpreter, (such as R (yet another one letter
> |
> Where do I find more info about "R"? -----'
One place is the page:
http://www.stat.auckland.ac.nz/rproj.html
Note that R is a very weird kind of project in that they are
implementing a language that looks essentially the same as the
S language, but with completely different scoping borrowed from
Scheme. In other words, it _looks_ just like S but can work
_very_ differently. You might say the same thing about S as compared
to R, but historically, S is much older.
Also, they have cut down some of the more inexplicable interpreter
overhead associated with S. (There is a lot of that.)
Later,
Andrew Mullhaupt
Manfred Bartz
"Andrew P. Mullhaupt" <amul...@ix.netcom.com> writes:
> .......................... Python, or another easily
> modified extensible interpreter, (such as R (yet another one letter
> language)) .................. ^
|
Where do I find more info about "R"? -----'
Thanks,
--
Manfred Bartz <mba...@werple.net.au>
------------------------------------------------------------------------
This is Linux country - where other operating systems just get emulated.