[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Apr 24 01:01:49 PDT 2007
Hello,
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
========================================================================
1) Offre d'emploi pour jeune ingenieur
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
fc33630cc2e650ab/0386429a7995a6d8#0386429a7995a6d8>
------------------------------------------------------------------------
** 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
<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.
========================================================================
2) The F#.NET Journal
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
f02cade14ef68e1d/ea91ff24396696a0#ea91ff24396696a0>
------------------------------------------------------------------------
** 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:
<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.
========================================================================
3) Internship at National ICT Australia, Sydney
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
ce9906615547965d/1e04bf12d95215d8#1e04bf12d95215d8>
------------------------------------------------------------------------
** 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.
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 at nicta.com.au
========================================================================
4) Saving the OCaml interpreter state
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
b326040c9c8663bd/c635e9fd3dc30fbe#c635e9fd3dc30fbe>
------------------------------------------------------------------------
** 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
programs.
========================================================================
5) Functor Performance Question
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
b56223554f1f9750/76d4e1ebd14db9f8#76d4e1ebd14db9f8>
------------------------------------------------------------------------
** 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.
========================================================================
6) backtrace output: feature request
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
b3e74154287ee6ed/27eca0be048ceabc#27eca0be048ceabc>
------------------------------------------------------------------------
** 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.
========================================================================
7) Slow allocations with 64bit code?
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
8a56e09a3e264637/6a8123eb6fe1fa6f#6a8123eb6fe1fa6f>
------------------------------------------------------------------------
** 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.
========================================================================
8) Ocaml-plplot binding
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.
========================================================================
9) Multiprocessor support in OCaml
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
67fbd5f9c58ea2b2/c675544ce4230c7a#c675544ce4230c7a>
------------------------------------------------------------------------
** 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.
<http://caml.inria.fr/pub/ml-archives/caml-list/
2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html>
** Erik 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.
========================================================================
10) Format.printf
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
06a69d1f0ae95080/8207aee9175dc89c#8207aee9175dc89c>
------------------------------------------------------------------------
** 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:
<http://caml.inria.fr/pub/docs/manual-ocaml/libref/Printf.html>
========================================================================
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
zM
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
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take
a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
========================================================================
--
Alan Schmitt <http://alan.petitepomme.net/>
The hacker: someone who figured things out and made something cool
happen.
.O.
..O
OOO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: =?ISO-8859-1?Q?Questa_=E8_un_messaggio_firmato_elettronicamente?=
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20070424/2361b71e/attachment.pgp
More information about the caml-news-weekly
mailing list