Except that ocaml is hardly a slow scripting language, on many levels it's directly comparable to C++ code. In my opinion, ocaml should be usable all the way down to the kernel code. For many complex algorithms and data structures, using C++ with all the zero-overhead level-headed template-bloated pages-long low-level intricate imperative code you'll get a very small constant factor improvement. For an actual non-trivial search code I got only twice the speed of the ocaml code, even though I used vectors instead of lists throughout. Not worth the effort at all. I wouldn't even attempt it if I hadn't had to port the code to C++. Thanks for the references by the way, I am actually interested in this. I'm thinking of its extensions (i.e. distributed memory architectures, shared memory cannot scale anyway). Best, On Sat, Jan 15, 2011 at 2:41 PM, bluestorm wrote: > I don't think it is easily possible inside Caml, as the data representation > is tightly bound to the runtime system, and it would be very delicate to > change it. > > If you are interested in the relevant litterature, you may want to see for > example the bibliography on "Unboxing data representations" of > http://pauillac.inria.fr/~xleroy/talks/references-pldi98.html > In particular, you may be interested in the Peyton-Jones and Launchbury > paper, as they implemented their ideas into the GHC Haskell compiler which > support some unboxed types. > > If you want to optimize the kernel of an existing OCaml program with > unboxed manipulations, I think your best bet would be to switch to a > lower-level language for your kernel. This is very common in scripting > languages where you generally implement the -- hopefully tiny -- > performance-sensitive parts of your program in C. You still reap the > benefits of OCaml abstractions for the larger, less performance-sensitive > part of your program. > > > On Sat, Jan 15, 2011 at 1:02 PM, Eray Ozkural wrote: > >> It's obvious that avoiding pointer chasing, improving locality and >> reducing storage will in some cases improve performance considerably. I've >> found many discussions about unboxing, but I haven't seen any solutions that >> would satisfy high-performance-computing programmers, who would probably >> like to have better (i.e. fine-grained) control over memory layout (unboxing >> double arrays isn't enough). In C++ this is trivial, because C++ is just an >> abstraction of assembly code. To cut it short, could not we have basically >> the same affordances of C++ in ocaml by annotating type definitions to >> indicate where unboxing would be forced? Such annotations aren't a new idea >> in programming languages, specifically HPF was based largely on parallel >> storage annotations. >> >> Regards, >> >> -- >> Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara >> >> >> > -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct