Hello
Here is the latest Caml Weekly News, for the week of April 17 to 24, 2007.
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 http://www-c.inria.fr/Internet/emploi-et-formation/offres-d-ingenieurs-jeunes-diplomes/offres-d-ingenieurs-jeunes-diplomes/view?set_language=fr La page ci-dessus conduit à une procédure de candidature en ligne, mais j'apprécierais que les candidats intéressés me contactent.
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: http://www.ffconsultancy.com/products/fsharp_journal/?ob 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 pipettes. Just my two cents.
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. Cheers, Ralf 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: http://www.ertos.nicta.com.au/research/goanna/ and the Embedded, Real-Time and Operating of System group: http://www.ertos.nicta.com.au/ 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: ralf.huuck@nicta.com.au
> 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 programs.
> 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.
> 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.
> 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.
Archive: http://groups.google.com/group/ocaml-developer/browse_frm/thread/d11c218376ebb838
Vityok asked:I would like to ask if anybody has interest in taking part in developing OCaml bindings to the plplot plotting library. http://vityok.org.ua/cgi-bin/odd.cgi/Ocaml-plplot 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 (http://psilab.sf.net). 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 success. 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.
> 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. http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.htmlErik de Castro Lopo suggested:
For real multi-procesor parallelism, have a look at this:
http://www.pps.jussieu.fr/~dicosmo/ocamlp3l/
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). Regards, Don 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 (http://merjis.com/developers/ancient) which will allow you to share data read-only between unrelated processes, backed by a file.
> 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: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Printf.html
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
zM
If you know of a better way, please let me know.
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.