From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Jocelyn.Serot@lasmea.univ-bpclermont.fr (Jocelyn Serot)
Cc: caml-list@margaux.inria.fr
Subject: Re: string vs vect + GC question
Date: Mon, 19 Feb 1996 11:06:31 +0100 (MET) [thread overview]
Message-ID: <199602191006.LAA04914@pauillac.inria.fr> (raw)
In-Reply-To: <199602161428.PAA10575@concorde.inria.fr> from "Jocelyn Serot" at Feb 16, 96 03:27:09 pm
Concerning your performance comparison between arrays and strings:
> let s = make_string 65536 `a`;;
> let f n =
> for i = 0 to n do for j = 0 to n do s.[i*256+j] <- s.[i*256+j] done done;;
> let v = make_matrix 256 256 `a`;;
> let g n =
> for i = 0 to n do for j = 0 to n do v.(i).(j) <- v.(i).(j) done done;;
> COMMENT: For 2D arrays, strings win the game. This is quite surprising
> since Caml Light is not supposed to be very good in doing the
> explicit arithmetic involved in the index computation. Vects seem
> to be penalized by the double indirection.
The main reason why arrays of arrays are less efficient is that each
access performs two bound checks, instead of one for the string-based
version. With array bound checking turned off (option -O fast), both
versions run at the same speed.
Also, if you're really doing matrices of bytes, the string-based
encoding is 4 times more compact (8 times on an Alpha) than the
array-based representation, which improves greatly cache behavior and
I/O speed.
As for your memory management question:
> I have a basic question regarding the behaviour of the Caml-Light Garbage
> collector: when an object becomes hidden, because of a its name is rebound at
> the top level, is it automatically reclaimed by the gc ?...
> For example:
> #let m = make_vect 1024 0;;
> m : int vect = [|0; 0; 0; 0; 0; ... |]
> #let m = 0;;
> m : int = 0 (* <- Will the space allocated for the vector be reclaimed ?*)
No, it will not be reclaimed. That's because all toplevel definitions
are entered in a global table of values, and always referenced through
that table. Rebinding an identifier does not guarantee that its
previous value is no longer needed, e.g.:
let m = make_vect 1024 0;;
let f x = m.(x);;
let m = 0;;
"f" still accesses the previous value of m in the global table.
Note that this behavior is specific to the toplevel: locally-bound
structures will always become garbage when leaving the scope of their
definition.
- Xavier Leroy
prev parent reply other threads:[~1996-02-19 19:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-02-16 14:27 string vs vect - some results Jocelyn Serot
1996-02-19 10:06 ` Xavier Leroy [this message]
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=199602191006.LAA04914@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Jocelyn.Serot@lasmea.univ-bpclermont.fr \
--cc=caml-list@margaux.inria.fr \
/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