Previous week Up Next week


Here is the latest Caml Weekly News, for the week of April 17 to 24, 2007.

  1. Offre d'emploi pour jeune ingenieur
  2. The F#.NET Journal
  3. Internship at National ICT Australia, Sydney
  4. Saving the OCaml interpreter state
  5. Functor Performance Question
  6. backtrace output: feature request
  7. Slow allocations with 64bit code?
  8. Ocaml-plplot binding
  9. Multiprocessor support in OCaml
  10. Format.printf

Offre d'emploi pour jeune ingenieur


Luc Maranget announced:
Notre équipe Moscova propose un poste de (jeune) ingénieur autour du 
développement de JoCaml. JoCaml est une extension de OCaml pour 
la programmation concurrente et distribuée. 

Il s'agit en gros d'assurer le support (mise en place des releases, 
sit web, suivi des bugs, mailing listes etc.), mais aussi et surtout 
de participer au développement du prototype JoCaml qui sera diffusé 
dès la prochaine release de Objective Caml. 

L'offre s'addresse à un jeune ingénieur, ou universitaire, 
dans le cadre de la campagne « ingénieurs jeunes diplômés » de l'Inria. 
En bref c'est une première expérience professionnele, pour 
un salaire est de 2020 Euros (net)/mois et une durée d'un an renouvelable 
une fois. 

L'offre « JoCaml, maintenance, développement et promotion » 
est détaillée sur la page web
La page ci-dessus conduit à une procédure de candidature en ligne, mais 
j'apprécierais que les candidats intéressés me contactent.

The F#.NET Journal


Jon Harrop announced:
Flying Frog Consultancy just started the F#.NET Journal, an on-line 
publication composed of articles, example source code and tutorial videos 
aimed at beginner programmers learning the F# programming language from 
Microsoft Research: 

Given the current explosion in the adoption of functional programming 
languages, we're considering trying to mimic this success with an OCaml 
Journal. If you'd be interested in subscribing, please let us know.
Richard Jones asked and Brian Hurt answered:
> Does F# run on real operating systems?  Does it have a full open 
> source stack? 

Overall, I see F# as a good thing for Ocaml.  OK, it draws some of it's 
support from the Ocaml community (John Harrop here being an obvious 
example)- thus dilluting the pool of energy from Ocaml, at least in the 
short term.  But any F# programmer can pick up Ocaml in short order, and 
vice versa (not unlike the C#/Java communities). 
But I think were F# will really draw it's people from is outside the 
community.  It'll draw from the vast horde of C#/VB/C++ Windows 
programmers.  Draw people from outside the community to inside the 
community.  And sooner or later many of them are going to start looking 
for an F# that runs on Linux/Unix. 

Even if I'm wrong, even if F# is a net loss for Ocaml, I still can't help 
viewing F# as a good thing over all.  Anything which helps programmers 
write code that doesn't *SUCK* is an advantage to us all- and every 
programmer coding in F# is a programmer not coding in C#, VB, or, God help 
us, C++.  Making code proven free of large classes of bugs, and many other 
bugs rare indeed is a definate good.  And bluntly, most software- free 
software as well as proprietary, sucks large rocks through very small 

Just my two cents.

Internship at National ICT Australia, Sydney


Ralf Huuck announced:
We are currently offering some 6 months internship(s) for OCaml 
developers at National ICT Australia, Sydney. Those internships are 
sponsored, but competitive. For current students there is the 
possibility to extend the scope to a BSc or Master thesis. 

If you are interested please read the following and contact me directly. 


Internship at NICTA, Sydney 

As part of the Goanna  research project on automatic code analysis of 
C/C++ programs we offer the opportunity for a six months internship in 
Sydney (Australia). 

The goal of the project is to develop an efficient and precise end-user 
analysis tool for (embedded) system code which includes kernel, OS and 
driver software. We are developing a novel approach based on formal 
verification techniques which permits it to be substantially more 
flexible then existing solutions. The project team offers highly 
motivated students the opportunity to work in an exciting R&D environment. 

We are looking for candidates with the following abilities: 

  * strong programming background 
  * good knowledge of C/C++ 
  * expert knowledge in OCaml development 
  * vocational English skills 
  * team player 
  * background in model checking or static analysis is a plus 

The project team consists of international researchers and developers 
from two of NICTA's research groups: Embedded, Real-Time and Operating 
Systems (ERTOS) and Formal Methods (FM). 

NICTA is Australia's research center of excellence in computer science. 
Working in a research center might be of particular interest to students 
who are looking for a future career in research, or who like to get a 
deeper understanding of research issues. 

For further information you can have a look at the project's page: 

and the Embedded, Real-Time and Operating of System group: 

We are looking for a student who likes to join us as soon as possible, 
but we might have further opportunities later in the year and next year. 
The internship typically covers the student's basic expenses for the 6 
months period. If you are interested or like to receive more information 
feel free to contact:

Saving the OCaml interpreter state


Harrison, John asked and Xavier Leroy answered:
> In several read-eval-print loops for functional languages 
> (e.g. Poly, SML/NJ, various LISPs), it s possible to save and 
> restore the current state so you can start up again in an 
> environment with all the same objects and name bindings 
> present. OCaml does not currently allow this. How hard would it be 
> to modify OCaml to support save/restore of sessions? 

Definitely not trivial.  In addition to the general problem with 
external libraries mentioned by Gerd Stolpmann, there is a more 
Caml-specific problem: code fragments generated by the toplevel reside 
in many different blocks, which is something that the Caml marshaller 
doesn't support.  There would be a lot of non-trivial code relocation 
work to perform. 
> More specifically, I want to 
> know whether the facility to save and restore state doesn't exist 
> because 
> * None of the main OCaml developers particularly care about it 
> or 
> * There are non-trivial technical problems implementing it. 

Both :-)  There are technical problems, and you are the only user who 
expressed a strong desire for this feature.  Personally, it brings 
back bad memories of early Lisp and ML implementations where saving 
the state of the toplevel loop was the only way to build executable 

Functor Performance Question


Jim Grundy asked and Xavier Leroy answered:
> I have a functor related performance issue. 
> I have the following collection of modules and types that we are using 
> in the implementation of a SAT solver: 
> If we implement Nat_priority_queue in the "right" way as 
> module Nat_priority_queue = Make_priority_queue (Nat_map) 
> Then I pay about a 3% performance penalty over instantiating the functor 
> by hand... 
> Is there some compiler switch or future version in the works that will 
> save me from this? 

Basically, no.  There is indeed a small performance penalty associated 
with functors, owing to the fact that the functor body is compiled 
only once without knowledge of its arguments.  Late specialization of 
functors would be nice in the absolute, but would require a major 
rework of the OCaml compiler.  This said, a 3% speed penalty is not 
too bad --- to me, it's lost in the noise of performance measurement.

backtrace output: feature request


Sam Steingold asked and Xavier Leroy answered:
> it appears that starting with 3.10 stack traces for natively compiled 
> executables will be available. thanks! 
> one thing that I would love to see is being able to redirect this output: 
> so that I can log both errors and their stack traces in a file for later 
> examination, but still continue running. 

I agree it would be nice, and this feature is on my "to do" list.  It 
takes a bit of work to make the backtrace data available from Caml, though, 
so don't expect this for 3.10. 
> how do I get backtraces on exceptions in then top-level? 
> I want to see something like: 
> h called g on line 1 
> g called f on line 1 
> f raised invalid_argument on line 1 

Currently, you cannot.  Conceivably, this would be the same mechanism 
as outlined above (i.e. making backtrace data available from Caml). 
However, you'd get a backtrace in terms of file names and line 
numbers, which don't make that much sense for toplevel definitions. 
Functions names don't really exist in compiled code.

Slow allocations with 64bit code?


Markus Mottl asked and Xavier Leroy answered:
> I wonder whether others have already noticed that allocations may 
> surprisingly be slower on 64bit platforms than on 32bit ones. 

As already mentioned, on 64-bit platforms almost all Caml data 
representations are twice as large as on 32-bit platforms (exceptions: 
strings, float arrays), so the processor has twice as much data to 
move through its memory subsystem. 
However, you certainly don't get a slowdown by a factor of 2, for two 
reasons: 1- the processor doesn't spend all its time doing memory 
accesses, there are some computations here and there; 2- cache lines 
are much bigger than 32 bits, meaning that accessing 64 bits at a 
given address is much cheaper than accessing two 32-bit 
quantities at two random addresses (spatial locality). 

Moreover, x86 in 64-bit mode is much more compiler-friendly than in 
32-bit mode: twice as many registers, a sensible floating-point model 
at last.  So, OCaml in 64-bit mode generates better code than in 
32-bit mode. 

All in all, your 10% slowdown seems reasonable and in line with what 
others reported using C benchmarks. 

> This is only a difference of about 10%, but I have seen more complex 
> cases where there are timing differences in excess of 50%, which is 
> already pretty substantial. 

Be careful with timings: I've seen simple changes in code placement 
(e.g. introducing or removing dead code) cause performance differences 
in excess of 20%.  It's an unfortunate fact of today's processors that 
their performance is very hard to predict. 
> Looking at the assembly, there is really no difference in the loop 
> other than the use of the quad word instructions, which should not 
> take longer on the exact same platform (i.e. same CPU-frequency).  But 
> there is a suspicious call to "caml_alloc2", which might cause these 
> differences.  Can it be that there are alignment problems or similar 
> in the run time? 

ocamlopt compiles module initialization code in the so-called 
"compact" model, where code size is reduced by not open-coding some 
operations such as heap allocation, but instead going through 
auxiliary functions like "caml_alloc2".  This makes sense since 
initialization code is usually large but not performance-critical. 
I recommend you put performance-critical code in functions, not in the 
initialization code.

Ocaml-plplot binding


Vityok asked:
I would like to ask if anybody has interest in taking part in 
developing OCaml bindings to the plplot plotting library. 

I have made an initial version of the bindings for almost all plplot 
setter functions and some of the getters.  Callbacks are not 
implemented yet. 

Current version is not very clean or robust as it performs a lot of 
type conversions on parameters and returned values. 

I consider, that the final goal is to integrate the OCaml bindings 
into the plplot distribution.
Hezekiah Carty answered and Vityok said:
> It looks like you're using Swig, so you taking a different approach - 
> but it may be helpful to look at the plplot bindings which come in 
> PsiLAB (  They are somewhat out of date, but 
> I've been thinking about starting something similar and they look like 
> they would provide a good start. 
> I'm currently working on bindings for the HDF4 library, but once that 
> is a little further along I would be happy to help out as I'm able 
> with the plplot bindings. 

Thank you for your hint.  Before starting to work on OCaml-Plplot 
bindings, I tried to find existing implementations, but without 

The bindings in PsiLab are somewhat cleaner and make an impression as 
if they were manually written. 

In any case, it will be a good hint for possible issues I can 
encounter while working on my version.

Multiprocessor support in OCaml


Jason Ganetsky asked and Xavier Leroy answered:
> Anyway, I have recently written an OCaml thread pool implementation, on 
> top of the Thread and Event modules. I did this for the purpose of 
> exploiting an SMP system I have, and was a disappointed to read today 
> that OCaml doesn't support multiprocessor systems. 

You are correct that OCaml *threads* do not exploit multiprocessing. 
Basically, only one OCaml thread can run at a time. 
You can still get parallelism in several ways.  First, external C 
libraries called from OCaml can run in parallel with OCaml code 
provided the OCaml/C interface for these libraries makes uses of the 
"blocking section" mechanism.  Second, process-level parallelism works 
very well with programs written in message-passing style, using e.g. 
OcamlMPI or OCamlP3L. 

> I played around with it a little, and discovered that by liberally 
> calling Thread.yield, I do cajole my threads into running on multiple 
> processors. 

This is an illusion.  Thread.yield gives more opportunities to the OS 
scheduler to reschedule a Caml thread on a different processor, but 
you're not gaining parallelism this way and you might actually lose 
performance (because of cache ping-pong effects and the like).
Richard Jones also answered:
The garbage collector doesn't support concurrency, so there's a big 
global lock around all OCaml code.
Erik de Castro Lopo suggested:
For real multi-procesor parallelism, have a look at this:

Haven't tried it myself, but its on my todo list.
Don Syme also suggested:
Just to mention there is a way of getting multiple concurrently executing 
OCaml threads in a program, which I discovered a while back: you can 
statically link multiple independent copies of the OCaml runtime, each into 
its own DLL (on Windows). This allows multiple independent OCaml threads to 
run concurrently. 

I presume this technique works well enough for SMP up to 2-4 processors, 
though have never done any serious performance testing. 

The OCaml programs must not, of course, trade OCaml values, but can 
communicate in-process by other means (e.g. shared C memory or some other 
message passing technique). 


P.S. I've only used this technique on Windows.
Zheng Li also suggested:
I'm working on a process back-end of STM library. It's now supported by Google
SOC and expected to release after the summer (and maybe earlier). With it, you
will be able to do shared-memory (supposing that's the style your want)
parallel programming based on processes, which in turn gives you speedup. 

If interested, you can have a taste first through the (vm)thread back-end
currently available (check my homepage below), though it won't really speed up
your program because of the well-known global lock of OCaml threads.
Jason Ganetsky then said and Richard Jones answered:
> Well, the solution I'm going for now is to load all my data up, call 
> Gc.Compact(), and then fork off child processes. The workload that I'm 
> parallelizing is read-only... so I think this will work well with Linux 
> copy-on-write forking.

You might also want to look at the Ancient library 
( which will allow you to share 
data read-only between unrelated processes, backed by a file.



Christian Sternagel asked and Paolo Donadeo answered:
> Is there a possibility to parametrize format-strings. 
> E.g. I want to provide a function [print_string], that, 
> given an integer [i], right-aligns a string as if it was 
> of length [i]. But following code is obviously not 
> possible: 
>  let print_string i s = Format.printf "%%is\n" i s;; 
> Since "%%" is a `normal' %. But since I do not know the 
> needed length in advance I can not write something like 
>  let print_string i s = Format.printf "%10s\n" s;; 
> Any suggestions? 

let my_print i s = Printf.printf "%*s" i s 
Is this what you mean? In any case search for "*" here: 

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1

If you know of a better way, please let me know.

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt