i know the argument for developing first, optimizing later.  i also know
the arguments for not caring about fine-grain performance and to look
at the big picture.  i've argued both and seen where these arguments fail.

consider compressed data as a bit stream from disk.
say it has simple encoding:
 phrase :=
  byte:<number-of-bits>, byte:<number-of-values>, int[]:<bit-stream>
eg:
  0x03 0x0a 0b1110 0011 1001 0100   1110 0101 1101 1100
  |    |    +<bit-stream>
  |    +number-of-values
  +number-of-bits

represents the sequence of 10 3-bit numbers:

 111,000,111,001,010,011,100,101,110,111

now consider a sentence as
  sentence := <empty> | phrase, sentence

without an enhanced FFI, ocaml will be considerably slower than C for
uncompressing (and compressing).

in my previous post, i suggest that some language primitives similar to
%bigarray_ref_1 could be introduced to make ocaml comparable to C.  i
have investigated this possibility, and my suggestion is that
%bigarray_ref is replaced by a primitive %ffi_ref and made public.
then bigarray can be built on the more general %ffi_ref and developers
have a fast means of accessing C arrays like mmap regions.

if i spend time implementing %ffi_ref/set, is there any chance of it being
incorporated into ocaml?

thanks,



jack


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners