From: John Carol Langford <jcl@gs176.sp.cs.cmu.edu>
To: caml-list@inria.fr
Subject: ocaml limitations
Date: Sun, 12 Dec 1999 23:34:02 -0500 [thread overview]
Message-ID: <199912130434.XAA12728@gs176.sp.cs.cmu.edu> (raw)
I have been encountering some fundamental limitations of the ocaml
language and compiler that are killing my performance - to the tune of
a factor of 10 off equivalent C code. This is a serious problem
because the program I'm working on is both RAM and cpu intensive.
The performance problems from two limitations. The first is in the
compiler and runtime - it's the limitation on the array size on 32 bit
machines - I only have linux PC's available to work on. It appears
that the garbage collector needs some type information to work with
arrays and enough bits are set aside for type information that not
enough bits are allowed to specify a large array size. You can get
around this large array size problem by simulating a large array with
an array of arrays, but there is a significant performance penalty.
The second problem is a language failure - there is no 'short int'
type in ocaml. Due to the combinatorics of my problem it would be
very convenient to use 16 bit integers. Using 32 bit integers instead
doubles the footprint of the program - which is unacceptable in this
case. Consequently, I simulate 16 bit integers using masking games -
which again incurs a performance penalty.
These two problems together add up to using a function considerably
more complicated then an array dereference on the inner loop:
let get_first i = i land (num_array -1)
let get_second i = i lsr (log_num_array+1)
let get_third i = (i lsr log_num_array) land 1
let get_split split i =
let first_index = get_first i
and second_index = get_second i
and third_index = get_third i in
let ret = split.(first_index).(second_index) in
let real_ret =
if third_index = 1 then ret
else ret lsr 16 in
real_ret land 65535
Naturally, the performance (relative to what the hardware is capable
of) is terrible. Consequently, I'm wondering if there are plans to
remove either (or both) of these limitations in the near future and
lacking that if there are better workarounds. Any suggestions?
-John
next reply other threads:[~1999-12-13 11:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-13 4:34 John Carol Langford [this message]
1999-12-13 12:34 ` William Chesters
1999-12-14 12:31 ` Xavier Leroy
1999-12-15 3:06 ` John Carol Langford
1999-12-13 19:18 David McClain
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=199912130434.XAA12728@gs176.sp.cs.cmu.edu \
--to=jcl@gs176.sp.cs.cmu.edu \
--cc=caml-list@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