caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@maxtal.com.au>
To: William Chesters <williamc@dai.ed.ac.uk>
Cc: caml-list@inria.fr
Subject: Re: Stdlib regularity
Date: Mon, 11 Oct 1999 10:36:25 +1000	[thread overview]
Message-ID: <38013109.87898DA@maxtal.com.au> (raw)
In-Reply-To: <24938.199910102044@buckie>

William Chesters wrote:
> 
> skaller writes:
>  >      No. This isn't necesarily the case. There are other
>  > solutions. In C++, the philosophy is to provide as much protection
>  > as possible, without costing at run time, and with protection
>  > that does cost at run time being optional.
> 
> Are you sure that initialising arrays etc. carries enough cost to be
> worth avoiding?  

	No, I'm not. 

> After all, one of the two problems, namely the
> requirement to keep legal values in slots at all times, is quite easy
> to work around when you have to---my basic Vector is about 100 lines,
> generously spaced---while the other, performance, worry seems a priori
> likely to be misplaced, because if you are constructing an array then
> your time complexity is presumably at least k×n for some nontrivial k,
> so that the extra few instructions × n are unlikely to make a big
> difference to the overall program, however annoying they look "in the
> small".
> 
> ocaml already goes some way beyond what C++ considers acceptible
> inefficiency.  That's fine for a vast number of applications on modern
> desktop hardware.

Unfortunately, when writing an interpreter such as one for Python,
reasonable efficieny plus some other advantages seem neccessary
to get any users at all. JPython (Java implementation), 
for example, is 3 times slower than CPython (C implementation),
and that was enough for me to discount it.

In fact, I am writing a python interpreter because CPython
is vastly (several THOUSAND times) too slow for what I need:
extremely fast string operations are required to support
Interscript, my literate programming tool. Example: Interscript
includes documentation for ISO10646 (unicode) characters,
the complete build of interscript itself, which is written
in interscript, takes several HOURS on my 120Mhz pentium:
the generated documentation is around 5Meg, mainly consisting
of the character code tables.

This is mainly because I have to do things like convert 
a string or plain text to HTML, which requires replacing
characters '<' with '&lt;'; that is, scan each individual
character .. in an interpretive loop.

It may seem strange to believe I can actually achieve this
performance in ocaml! But I do! Because of the 'higher level
algorithms are easier to write in ocaml than C' factor,
optimisations using techniques such as type inference, 
special pattern recognition, etc,
and generation of fast C or assembler, are possible.

FYI the design is to use the interpreter only to load
the modules required for a main program, then do
whole program analysis to generate a single executable.
But because Python also has dynamic features like 'exec string'
it is necessary to make the interpreter available at run time,
even in the compiled code. So it needs to be reasonably efficient.

-- 
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller




  parent reply	other threads:[~1999-10-11 17:28 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-06 13:25 Ohad Rodeh
1999-10-06 16:18 ` Markus Mottl
1999-10-08 14:06   ` Matías Giovannini
1999-10-10 20:09     ` Pierre Weis
1999-10-10 20:12       ` Matías Giovannini
1999-10-08 14:10   ` skaller
1999-10-08 19:21     ` Markus Mottl
1999-10-09 21:14     ` Dave Mason
1999-10-06 18:50 ` John Prevost
1999-10-07  7:33 ` skaller
1999-10-07  9:18 ` Francisco Valverde Albacete
1999-10-08 14:56   ` skaller
1999-10-09 22:26     ` Francois Rouaix
1999-10-10  5:38       ` skaller
1999-10-10 20:44         ` William Chesters
1999-10-10 21:43           ` Hongwei Xi
1999-10-11  0:36           ` skaller [this message]
1999-10-12  7:20             ` David Mentr{'e}
1999-10-08 16:38   ` Proposal for study: Add a categorical Initial type to ocaml skaller
1999-10-09 22:43     ` John Prevost
1999-10-10  3:18       ` chet
1999-10-10  6:14       ` skaller
1999-10-10 21:05         ` William Chesters
1999-10-10 22:36           ` chet
1999-10-10 22:38           ` chet
1999-10-11 19:30             ` John Prevost
1999-10-12  8:34             ` Option types and O'Labl merger Jacques Garrigue
1999-10-12 14:38               ` William Chesters
1999-10-13  5:35                 ` Frank A. Christoph
1999-10-13  8:48                   ` Jacques Garrigue
1999-10-11  0:51           ` Proposal for study: Add a categorical Initial type to ocaml skaller
1999-10-11 12:40         ` John Prevost
1999-10-12 19:20           ` skaller
1999-10-12 11:33         ` Jean-Francois Monin
1999-10-10 16:10       ` chet
1999-10-09 16:58 Stdlib regularity William Chesters
1999-10-10  0:11 ` Matías Giovannini
1999-10-12 16:21 Damien Doligez
1999-10-13 12:18 ` Matías Giovannini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38013109.87898DA@maxtal.com.au \
    --to=skaller@maxtal.com.au \
    --cc=caml-list@inria.fr \
    --cc=williamc@dai.ed.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).