caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alex Baretta <alex@barettadeit.com>
To: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Impact of GC on memoized algorithm
Date: Wed, 30 Mar 2005 17:03:10 +0200	[thread overview]
Message-ID: <424ABFAE.7080309@barettadeit.com> (raw)
In-Reply-To: <874qetdypa.fsf@qrnik.zagroda>

Joh Harrop wrote:

>>> This is rather unlikely. The key to the hashtable is a unique integer...
> 
> So not a [0|1] list like the /. troll then?  ;-) 

No, definitely not. Actually, I am trying to use as much of the bonuses 
of functional programming to further speed up a fairly fast (but, alas, 
worst-case exponential) cutting stock algorithm. The present one works 
as a bytecode library to our AS/Xcaml application server, and provides 
performance comparable to that of the most widely available commercial 
implementations. Yet, it is necessary to do better to win the market 
over, and it it takes a little more effort than switching from ocamlc to 
ocamlopt ;)

>>> Rather, what happens, time-wise, if I create a hashtable with 4096 slots
>>> and end up filling it with several million key-value pairs?
> 
> 
> The hashtable will dynamically double its size each time it feels full. This 
> incurs an O(n) cost at exact solutions of n = 2^p - 1 for integer p>0, IIRC. 
> This will cause the program to stutter but should not adversely impact 
> overall performance. This would be a problem for real-time applications.

Marcin 'Qrczak' Kowalczyk wrote:
> "Alexander S. Usov" <A.S.Usov@KVI.nl> writes:
> 
> No, OCaml's hash tables are resized automatically.

Ok. So, just as I expected, I am guaranteed that I have no hash 
conflicts desperately degrading the performance of my algorithm. But 
what is the amortized complexity of an insertion into a resizable 
hashtable? Am I right in stating that it is O(log n)? Or is it maybe 
O(n) due to saturation of number of buckets available to the hashtable? 
Then, in this case, I would need to expand the number of buckets by 
allocating a super-hashtable implemented as a hashtable of hashtables 
(as someone already suggested) or an array of hashtables.

And, then again, how does the Gc.full_major scale as the "cache" for the 
algorithm fills up with millions of key-value pairs? Is the GC linear on 
the number of *reclaimed* blocks, or is it linear in the *total* number 
of allocated blocks?


Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>


  reply	other threads:[~2005-03-30 15:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30  8:39 Alex Baretta
2005-03-30 12:03 ` [Caml-list] " Jon Harrop
2005-03-30 12:34   ` Alex Baretta
2005-03-30 13:09     ` Alexander S. Usov
2005-03-30 13:56       ` Marcin 'Qrczak' Kowalczyk
2005-03-30 15:03         ` Alex Baretta [this message]
2005-03-31 14:41           ` Jean-Christophe Filliatre
2005-04-11 14:22           ` Damien Doligez
2005-04-11 15:48             ` Alex Baretta
2005-04-14  9:52               ` Damien Doligez
2005-04-14 10:27                 ` Jan Kybic

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=424ABFAE.7080309@barettadeit.com \
    --to=alex@barettadeit.com \
    --cc=caml-list@inria.fr \
    --cc=qrczak@knm.org.pl \
    /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).