BOUNCE ll1-discuss@ai.mit.edu: Non-member submission from [Lauri Alanko <la@iki.fi>]

[address@hidden]

>From gregs@ai.mit.edu  Mon Dec  3 14:33:26 2001
Received: from no-spam.it.helsinki.fi (NO-SPAM.it.helsinki.fi [128.214.205.34])
	by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with ESMTP id OAA12132
	for <ll1-discuss@ai.mit.edu>; Mon, 3 Dec 2001 14:33:24 -0500 (EST)
Received: from la.pp.htv.fi (root@kruuna.helsinki.fi [128.214.205.14])
	by no-spam.it.helsinki.fi (8.11.4/8.11.4-SPAMmers-sod-off) with ESMTP id fB3JXNT29187
	for <ll1-discuss@ai.mit.edu>; Mon, 3 Dec 2001 21:33:23 +0200 (EET)
Received: from la by la.pp.htv.fi with local (Exim 3.33 #1 (Debian))
	id 16Ayq6-0000Tv-00
	for <ll1-discuss@ai.mit.edu>; Mon, 03 Dec 2001 21:33:18 +0200
Date: Mon, 3 Dec 2001 21:33:16 +0200
From: Lauri Alanko <la@iki.fi>
To: ll1-discuss@ai.mit.edu
Subject: Re: Diversity - existence, value, and pursuit.
Message-ID: <20011203193316.GA614@la.iki.fi>
References: <200112021803.NAA17313@bosch.cs.brown.edu> <20011201162719.A5412@panix.com> <0054FD2F-E6B7-11D5-B0DC-003065C2A10C@mac.com> <20011202000659.A1291@netthink.co.uk> <200112020542.AAA15460@bosch.cs.brown.edu> <20011202122201.B16222@netthink.co.uk> <200112021803.NAA17313@bosch.cs.brown.edu> <5.0.2.1.0.20011203135748.00a07540@pop.hotdispatch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.0.2.1.0.20011203135748.00a07540@pop.hotdispatch.com>
User-Agent: Mutt/1.3.24i
Sender: Lauri Alanko <la@la.pp.htv.fi>

On Mon, Dec 03, 2001 at 02:08:30PM -0500, Scott McKay wrote:
> At 01:45 PM 12/2/01, Simon Cozens wrote:
> >On Sun, Dec 02, 2001 at 01:03:43PM -0500, Shriram Krishnamurthi wrote:
> >
> >But on
> >other hand, it's obvious that you can't get code running on a VM to run
> >as fast as C.
> 
> Actually, it is no longer obvious to me that a VM is necessarily slower than
> natively compiled code, except under certain circumstances (*).

An additional argument in favor of VM:s is that when the final compilation
phase is deferred until run-time, a JIT compiler has knowledge of the
run-time execution profile and can optimize crititical portions of the code
more accurately.

A CPU's branch prediction mechanism is adaptive, but it cannot be very
complex or high-level. On the other hand, even if a C compiler can be fed
profiling information to fine-tune the optimizations (and the algorithm to
use this profiling data can be very sophisticated), it is still just an
approximation of the _average_ run-time behavior, and thus probably
non-optimal for a particular run. A JIT lies somewhere between these two
extremes, and combines the best of both worlds.

At least, that's the impression I get from Java blurbs. But I don't know
anything. :)


Lauri Alanko
la@iki.fi