* Re: Ocaml for Scientific computing
@ 2007-09-25 17:27 Mike Lin
2007-09-25 18:46 ` [Caml-list] " skaller
0 siblings, 1 reply; 8+ messages in thread
From: Mike Lin @ 2007-09-25 17:27 UTC (permalink / raw)
To: caml-list
On Sep 25, 7:11 am, Alex Mikhalev <a.mikha...@cranfield.ac.uk> wrote:
> Dear all,
> I am wondering is anyone using Ocaml for scientific computing? I didn't
> mean parsing, but for number crunching applications, like signal/image
> analysis. Is it suitable for this kind of tasks in general? I would like
> to hear from someone practically using it, not just theoretical
> possibility.
I use it for a lot of genome sequence processing, comparative genomics
and phylogenetic modeling. Algorithmically this involves conditional
random fields (for which I have my own library) and some linear
algebra and numerical optimization (for which I use Lacaml and
ocamlgsl). I had a lot of frustrations at first, but it's been better
since we got exception stack traces and ocaml+twt.
For numerical computing, I wish ocamlopt would do at least basic loop
optimizations, like hoisting invariant values -- this type of stuff is
easily done manually, but often at the expense of code readability. I
can see how this may be a bottomless pit for the dev team though,
since I would probably always feel like we are one crucial
optimization short of not having to rewrite that tight loop in C.
In any case though, I work in a group where everyone else uses Python,
so I'm already beating their pants off :o)
Mike
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Re: Ocaml for Scientific computing
2007-09-25 17:27 Ocaml for Scientific computing Mike Lin
@ 2007-09-25 18:46 ` skaller
2007-09-25 20:38 ` Jon Harrop
0 siblings, 1 reply; 8+ messages in thread
From: skaller @ 2007-09-25 18:46 UTC (permalink / raw)
To: Mike Lin; +Cc: caml-list
On Tue, 2007-09-25 at 13:27 -0400, Mike Lin wrote:
> On Sep 25, 7:11 am, Alex Mikhalev <a.mikha...@cranfield.ac.uk> wrote:
> For numerical computing, I wish ocamlopt would do at least basic loop
> optimizations, like hoisting invariant values -- this type of stuff is
> easily done manually, but often at the expense of code readability.
Gcc does this quite well I think. However in a higher level
procedural language (like Ocaml and Felix) it is very hard
to get right and potentially very expensive.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Re: Ocaml for Scientific computing
2007-09-25 18:46 ` [Caml-list] " skaller
@ 2007-09-25 20:38 ` Jon Harrop
2007-09-25 21:01 ` skaller
0 siblings, 1 reply; 8+ messages in thread
From: Jon Harrop @ 2007-09-25 20:38 UTC (permalink / raw)
To: caml-list
On Tuesday 25 September 2007 19:46:34 skaller wrote:
> On Tue, 2007-09-25 at 13:27 -0400, Mike Lin wrote:
> > On Sep 25, 7:11 am, Alex Mikhalev <a.mikha...@cranfield.ac.uk> wrote:
> >
> > For numerical computing, I wish ocamlopt would do at least basic loop
> > optimizations, like hoisting invariant values -- this type of stuff is
> > easily done manually, but often at the expense of code readability.
>
> Gcc does this quite well I think. However in a higher level
> procedural language (like Ocaml and Felix) it is very hard
> to get right and potentially very expensive.
I'm not sure that it is conceptually more difficult to do similar things for
OCaml but my vote goes to hoisting bounds checks. I don't like having to
write unsafe code by hand in OCaml and F# does a great job of improving
performance by hoisting bounds checks.
I discussed some of the benchmarks where F# is faster than OCaml recently on
one of our blogs:
http://ocamlnews.blogspot.com/2007/09/spectral-norm.html
For some reason, the current implementation of spectral-norm on the shootout
leaves out some important optimizations in OCaml. F# doesn't require these
optimizations to be done by hand.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Re: Ocaml for Scientific computing
2007-09-25 20:38 ` Jon Harrop
@ 2007-09-25 21:01 ` skaller
2007-09-26 8:27 ` Florian Hars
0 siblings, 1 reply; 8+ messages in thread
From: skaller @ 2007-09-25 21:01 UTC (permalink / raw)
To: Jon Harrop; +Cc: caml-list
On Tue, 2007-09-25 at 21:38 +0100, Jon Harrop wrote:
> I'm not sure that it is conceptually more difficult to do similar things for
> OCaml but my vote goes to hoisting bounds checks. I don't like having to
> write unsafe code by hand in OCaml and F# does a great job of improving
> performance by hoisting bounds checks.
I guess that this is easier. How much speed is gained eliding
bounds checks?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Re: Ocaml for Scientific computing
2007-09-25 21:01 ` skaller
@ 2007-09-26 8:27 ` Florian Hars
2007-09-26 8:53 ` skaller
0 siblings, 1 reply; 8+ messages in thread
From: Florian Hars @ 2007-09-26 8:27 UTC (permalink / raw)
To: skaller; +Cc: Jon Harrop, caml-list
skaller schrieb:
> I guess that this is easier. How much speed is gained eliding
> bounds checks?
It may even make the code slower:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/679987f7b8b70e4cd9f088ac4e6c8097.en.html
Yours, Florian.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Re: Ocaml for Scientific computing
2007-09-26 8:27 ` Florian Hars
@ 2007-09-26 8:53 ` skaller
0 siblings, 0 replies; 8+ messages in thread
From: skaller @ 2007-09-26 8:53 UTC (permalink / raw)
To: Florian Hars; +Cc: caml-list
On Wed, 2007-09-26 at 10:27 +0200, Florian Hars wrote:
> skaller schrieb:
> > I guess that this is easier. How much speed is gained eliding
> > bounds checks?
>
> It may even make the code slower:
>
> http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/679987f7b8b70e4cd9f088ac4e6c8097.en.html
Yes, I tend to agree with Xavier's analysis.
This may also explain why C code generated by Felix is
often faster than hand written C code: on AMD64 Felix
generated C code for Ackermann's function is almost the same
as the hand written C, but runs 2x faster, and 2.5x faster
than Ocamlopt generated code.
At this point with gcc as the compiler and using stack
programming (no heap), I'm now expecting Felix to beat
C on all programs (and if it doesn't it's a bug
in the compiler that needs fixing).
I am guessing this is because GCC has good SSA analysis,
and it works a lot better on goto spaghetti with a fixed
stack frame of the kind Felix tends to generate, than
block structured C code using for loops, etc.
So I'd add to Xaviers comments on processor behaviour
that small differences in source code structure can make
a big difference to compiler technology.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Ocaml for Scientific computing
2007-09-25 11:01 Alex Mikhalev
@ 2007-09-26 3:06 ` Jan Kybic
0 siblings, 0 replies; 8+ messages in thread
From: Jan Kybic @ 2007-09-26 3:06 UTC (permalink / raw)
To: Alex Mikhalev; +Cc: caml-list
> I am wondering is anyone using Ocaml for scientific computing? I didn't
> mean parsing, but for number crunching applications, like signal/image
> analysis. Is it suitable for this kind of tasks in general? I would like
> to hear from someone practically using it, not just theoretical
> possibility.
I have used Ocaml for several projects involving numerical
calculations, including image processing, boundary element methods and
optimization. I use Lacaml, fftw, MPI and Gsl libraries, the
installation was not difficult. Ocaml has performed very well for me
so far, it is faster than Python or Matlab and more "friendly" than
C/C++. Some minor issues:
- There is too many different representations of vectors and matrices:
float arrays, plain big arrays, Lacaml Fortran style big arrays,
several kinds of Gsl vectors with yet separate styles. I found I
often had to convert vectors or matrices from one format to another
because the function I wanted to use was available for a different
interface.
- Limited interactivity - it would help if you could call native compiled
modules from the toplevel.
- Limited debugging - it is not possible to debug compiled modules.
I would like to see an interface to gdb (I work on Linux), or a
possibility for the byte compiled code being debugged to call
natively compiled modules.
- I still find Ocaml object system less natural for me and more
limiting than for example Python's. Also, often you can do the same
thing with the objects as with the module system, so the choice of the
best design pattern is sometimes not obvious at the first sight and
requires a lot of foresight. But I assume this is just a matter of
practice.
Good luck,
Jan
--
-------------------------------------------------------------------------
Jan Kybic <kybic@fel.cvut.cz> tel. +420 2 2435 5721
http://cmp.felk.cvut.cz/~kybic ICQ 200569450
^ permalink raw reply [flat|nested] 8+ messages in thread
* Ocaml for Scientific computing
@ 2007-09-25 11:01 Alex Mikhalev
2007-09-26 3:06 ` Jan Kybic
0 siblings, 1 reply; 8+ messages in thread
From: Alex Mikhalev @ 2007-09-25 11:01 UTC (permalink / raw)
To: caml-list
Dear all,
I am wondering is anyone using Ocaml for scientific computing? I didn't
mean parsing, but for number crunching applications, like signal/image
analysis. Is it suitable for this kind of tasks in general? I would like
to hear from someone practically using it, not just theoretical
possibility.
I have read "Ocaml for Scientists" and although it gave me some very
good ideas, I didn't manage to repeat a number of examples with modules
from this book. I had a problem compiling or using scientific modules
(lacaml, fftw, some others) on linux and macosx and since some of these
modules look like someones graduate project, I would like to hear from
people practically using ocaml for mathematical simulations or analysis.
Preferable with OS, modules, problems encountered.
Regards,
Alex
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-09-26 8:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-25 17:27 Ocaml for Scientific computing Mike Lin
2007-09-25 18:46 ` [Caml-list] " skaller
2007-09-25 20:38 ` Jon Harrop
2007-09-25 21:01 ` skaller
2007-09-26 8:27 ` Florian Hars
2007-09-26 8:53 ` skaller
-- strict thread matches above, loose matches on Subject: below --
2007-09-25 11:01 Alex Mikhalev
2007-09-26 3:06 ` Jan Kybic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox