Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Todd Graham Lewis <tlewis@mindspring.net>, caml-list@inria.fr
Subject: Re: VLIW & caml: how?
Date: Wed, 2 Sep 1998 19:23:56 +0200	[thread overview]
Message-ID: <19980902192356.36292@pauillac.inria.fr> (raw)
In-Reply-To: <Pine.LNX.3.96.980828011145.1695L-100000@reflections.eng.mindspring.net>; from Todd Graham Lewis on Fri, Aug 28, 1998 at 01:18:34AM -0400

> I've been reading that VLIW as implemented on the IA-64/Merced will post
> problems for conventional compilers such as gcc which don't have a very
> expansive view of the code they're compiling.  How well will o'caml deal
> with optimizing for this sort of architecture?  Any thoughts?

It's hard to say anything precise until Intel releases detailed
documentation on the IA64 instruction set.

If your question is about instruction-level parallelism (ILP) in
general, it must be noted that today's superscalar architectures (ushc
as the Alpha 21264 and the PowerPC 604) already offer more parallelism
(i.e. 4 instructions issued per cycle) than can be exploited by most
compiled programs.  This is due in part to insufficient optimizations in
compilers (extracting ILP from sequential code might require
significant program transformations) and in part to the fact that many
programs simply do not contain enough parallelism by nature of the
algorithms used.  Often, the only way to exploit fully the resources
of those superscalar processors is to write carefully tuned assembly
code by hand...

Code generated by ocamlopt has characteristics similar to the
so-called "commercial workload" subset of Spec95, i.e. high number
of memory accesses, low to medium ILP, and relatively low CPI.  This
is not surprising, as hardware manufacturers generally increase ILP by
throwing more integer and floating-point ALUs, which are not useful for
most Caml applications, but don't increase the number of load-store
units, which would be good for Caml but is very hard to implement in
hardware.

However, there is some hope that the clean semantics of Caml might
allow more aggressive scheduling of memory accesses as is possible
with e.g. C programs.  In particular, the type system gives a lot of
non-aliasing properties "for free" (e.g. a load from an immutable data
structure cannot interfere with a non-initializing store).  See my
PLDI'98 tutorial for more details (http://pauillac.inria.fr/~xleroy/).
But again, this can be useful only if the hardware supports many
pending memory accesses simultaneously.

All in all, I'm not expecting much speedups from ILP.  The important
speedups we've observed on Caml programs when moving from older
architectures (e.g. the Alpha 21064) to newer ones (e.g. the Alpha
21164 or PowerPC G3) are due to better caches and faster memory
subsystems much more than to increased on-chip parallelism.

- Xavier Leroy





  parent reply	other threads:[~1998-09-03 11:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-28  5:18 Todd Graham Lewis
1998-09-01 11:33 ` Ping Hu
1998-09-02 17:23 ` Xavier Leroy [this message]
1998-09-03 19:29   ` Joel Jones
1998-08-29 17:36 Christopher Oliver

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=19980902192356.36292@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=tlewis@mindspring.net \
    /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