Re: C++ Speed Vs. Java
Jerry Coffin wrote:
In article <1pwCUv1tiywFFwLg@robinton.demon.co.uk>,
francis@robinton.demon.co.uk says...
[ ... ]
Well there is another option, which is that the code produced by the JIT
compiler is cached for later reuse. People often write as if the
options are static compilation separated from execution and JIT
compilation. In reality these are just two ends of a spectrum.
While you're certainly right, the intermediate possibilities are a lot
less common than the two extremes.
I don't think that caching the compiled code is that rare.
Pretty much every web server does it, I think; otherwise, I
don't think JSP would be viable.
IN days long gone by it was common to use two compilers, one for
development which would be aimed at good diagnostics and fast code
production and the second being an optimising compiler whose task was to
try to produce fast compact code from clean sources. (All my early
programming in Fortran was with such a pair of compilers)
These days we tend to think we have one compiler and change its
behaviour with compiler switches. But we might be better thinking of
these as separate compilers and feel happy if the optimising compiler
takes considerable time.
I suspect in some cases, they really are still fairly separated to some
degree internally. There's probably not a good reason to use separate
parsers (for example), but separate code generators would be perfectly
reasonable.
The typical approach, today, is to add two extra passes for
optimization: one which rewrites the intermediate representation
(doing things like common subexpression merging and loop
invariant motion), and another which rewrites the generated code
(remapping registers, interleaving memory accesses, etc.---this
is the phase which will typically replace the no-op after a
branch with something more useful). In most cases, all of the
above constitute a back-end, which is addressed by the
front-ends for many different languages. Whereas back in the
good old days, IBM really did have two distinct Fortran
compilers.
[ ... ]
Now, I have never seen this done, but there is no technical reason why
dynamic libraries should not be delivered in a form similar to some form
of semi-compiled object code (with the meta-data) which is then fully
compiled as part of the process of loading/linking.
Back in the late '80s the OSF had a roughly similar idea. The
Architecture Neutral Distribution Format (ANDF) was supposed to allow
executables to be used on a variety of different machines. The developer
would produce an ANDF file, and then something (compiler, linker,
loader, or whatever you prefer to call it) on the user's machine would
use it to produce the actual machine instructions that got executed.
I believe there have even been a few compilers that could produce ANDF
output, but it never seems to have become particularly popular.
The goal here was simple: compete with MS-DOS. An MS-DOS
executable would run on all MS-DOS machines. The goal was to
have a distribution format which would run on all Unix machines.
FWIW: ANDF was pretty close to JVM in concept. And possibly
(but I'm just guessing) one of the reasons it didn't catch on is
that it did need a compiler, or at least a compiler back-end, to
install, and about the time it really became stable, Unix
vendors had started unbundling the compiler.
Of course, ANDF wasn't the first to take this path, by any
means. There was UCSD Pascal, with it's p-code, for example.
And I believe that most implementations of Forth also worked
more or less like this. (Of course, the latter two generally
really did interpret the byte code, rather than any form of JIT
or installation time compilation.)
I wonder if installation time compilation wouldn't be a good
solution for C++. We're used to installations locking up our
machine for a long time anyway:-).
[...]
While I think this is a good idea, I also think it's being oversold. It
may do a lot more to reduce the difficulty in the mechanics of
assembling large programs, but the real difficulty isn't in the
mechanics -- it's in the analysis and design. Giving people larger, well
thought-out building blocks to work with _may_ help in that respect as
well, but I'm not convinced it's going to be quite the panacea many
people want to believe (then again, few things are...)
There's no silver bullet. The problem is that when things are
presented as silver bullets, and then turn out not to be, they
get a bad name.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]