caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* RE: [Caml-list] Interactive technical computing
@ 2007-03-08 21:26 Robert Fischer
  2007-03-09  0:04 ` skaller
                   ` (2 more replies)
  0 siblings, 3 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-08 21:26 UTC (permalink / raw)
  To: caml-list

> Putting aside the obvious cultural resistance to using a sensible
> language for this project, there is one technical hurdle: It needs to
> compile into a DLL which can be linked to other programs (in C and
> other languages).  I can't generate such code using ocamlopt, at least
> not without using unsupported out-of-tree extensions.
>
I don't think this is a real hurdle to general adoption of a language.
After all, Java and C# aren't intended to be used like that, yet they
certainly have wide-spread adoption.

I suppose there is gcj for Java, but that's not in 99+% of Java
development, and I'm not sure that will give you a lib at the end of the
day.  I don't know of an equivalent for that in C# -- in all the C#
development I've done, we've never even considered it.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Richard Jones
Sent: Thursday, March 08, 2007 3:17 PM
To: Jim Miller
Cc: caml-list@inria.fr; skaller
Subject: Re: [Caml-list] Interactive technical computing


On Wed, Mar 07, 2007 at 10:36:18PM -0500, Jim Miller wrote:
> What's I think is the interesting point about this discussion is "What
are
> the hurdles toward acceptance of any new language, scripting or not,
into a
> given community?"  Obviously OCAML and the ML languages have deeply
> penetrated some markets but haven't even dented others.  There have
been
> lots of papers, studies, and discussion written on this (
> lambda-the-ultimate.org has many of them archived) so that's probably
> something for a different thread to be read wearing flame-retardant
> underthings.

I'm currently contributing to a 45KLOC C library which I'm sure would
be about 10 times smaller if written in a reasonable language.

Putting aside the obvious cultural resistance to using a sensible
language for this project, there is one technical hurdle: It needs to
compile into a DLL which can be linked to other programs (in C and
other languages).  I can't generate such code using ocamlopt, at least
not without using unsupported out-of-tree extensions.

Rich.

-- 
Richard Jones
Red Hat

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


^ permalink raw reply	[flat|nested] 40+ messages in thread
* RE: [Caml-list] Interactive technical computing
@ 2007-03-09 17:41 Robert Fischer
  0 siblings, 0 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-09 17:41 UTC (permalink / raw)
  To: caml-list

Weird -- I thought F# was having all kinds of performance problems.  Got metrics?

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 11:26 AM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing


On Friday 09 March 2007 14:13, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

Performance of OCaml compiled to native code with ocamlopt is sometimes slower 
than F#, so yes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


^ permalink raw reply	[flat|nested] 40+ messages in thread
* RE: [Caml-list] Interactive technical computing
@ 2007-03-09 15:35 Robert Fischer
  0 siblings, 0 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-09 15:35 UTC (permalink / raw)
  To: caml-list

Performance of using F# linking into native applications is better than using OCaml bytecode and linking into native applications?  Is F# faster than OCaml bytecode these days?  Is the OCaml bytecode's link into dynamic libraries somehow slowing things down?

I'm still having trouble seeing what you're getting at -- sorry if I'm being dense.

~~ Robert.

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of skaller
Sent: Friday, March 09, 2007 9:22 AM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Fri, 2007-03-09 at 08:13 -0600, Robert Fischer wrote:
> Performance of Ocaml's bytecode is slower than F#?  Really?

I wrote:
> > As long as you play within the bounds of their VM.  This is no different than Ocaml.
> 
> Performance is different :) That's why I use Ocaml native code
> exclusively, which doesn't support dynamic loading (yet :)

I have no idea about performance of F#: I'm talking about
using a Debian based Linux operating system which uses
dynamic loading of high performance machine binaries.

I once implement a Python interpreter in Ocaml, call Vyper.
One of the reasons I gave up was that to extend it with
the equivalent of Python's C modules, I had to write the
equivalent code in Ocaml and *statically* link it into
the program.

The main reason for doing this wasn't performance, but
to provide bindings to C libraries.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


^ permalink raw reply	[flat|nested] 40+ messages in thread
* RE: [Caml-list] Interactive technical computing
@ 2007-03-09 14:21 Robert Fischer
  0 siblings, 0 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-09 14:21 UTC (permalink / raw)
  To: Jon Harrop, caml-list

> Can you dynamically load code and get native performance? Not with OCaml.
>
> I've got a killer high-performance 2D and 3D visualization library written in 
> OCaml and I'd like to sell it, but I don't want to sell the source code 
> because I value it too much. What can I do? Well, I can port it to F# and 
> sell it there. In the mean time, OCaml users are stuck with GNUPlot.
>
Do you have metrics showing that performance is better with F# than OCaml in these two cases?

>From what I understand, F# has a major performance issue resulting from the way the .Net VM handles allocation.  Is that old info?

> Can you compile to a cross-platform format and keep native performance? Not 
> with OCaml.
>
F# goes to byte code, OCaml goes to byte code.  If you want to be "cross-platform", you're pretty much headed to a VM one way or another.

> Can you write an interactive environment (top level) and keep native 
> performance? Not with OCaml.
>
The top-level is something I've been hacking on a bit, and I am a bit cranky with it right now, too.  I'll post something on it later.

> Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml 
> (I think, because you need a custom run-time).
>
What are you doing with F# where you see it as more "cross-platform" than OCaml?  I guess I don't understand the charge.

>From what I understand, your basic argument is "F# is cross-compatible with the .Net framework, and therefore better".  This is definitely something I agree with.  If I trusted the .Net framework to ever become and remain genuinely cross-platform (I expect Mono to be killed by vicious attack lawyers as soon as MS cares), I'd be a lot more inclined to use it.

~~ Robert.


-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 7:49 AM
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing


On Friday 09 March 2007 13:33, Robert Fischer wrote:
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
>
> As long as you play within the bounds of their VM.  This is no different
> than Ocaml.

On the contrary, it is very different:

Can you dynamically load code and get native performance? Not with OCaml.

Can you compile to a cross-platform format and keep native performance? Not 
with OCaml.

Can you write an interactive environment (top level) and keep native 
performance? Not with OCaml.

Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml 
(I think, because you need a custom run-time).

I've got a killer high-performance 2D and 3D visualization library written in 
OCaml and I'd like to sell it, but I don't want to sell the source code 
because I value it too much. What can I do? Well, I can port it to F# and 
sell it there. In the mean time, OCaml users are stuck with GNUPlot.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


^ permalink raw reply	[flat|nested] 40+ messages in thread
* RE: [Caml-list] Interactive technical computing
@ 2007-03-09 14:13 Robert Fischer
  2007-03-09 15:21 ` skaller
                   ` (2 more replies)
  0 siblings, 3 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-09 14:13 UTC (permalink / raw)
  To: caml-list

Performance of Ocaml's bytecode is slower than F#?  Really?

~~ Robert.

-----Original Message-----
From: skaller [mailto:skaller@users.sourceforge.net]
Sent: Friday, March 09, 2007 7:54 AM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Fri, 2007-03-09 at 07:33 -0600, Robert Fischer wrote:
> >> After all, Java and C# aren't intended to be used like that, yet they
> >> certainly have wide-spread adoption.
> >
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
> >
> As long as you play within the bounds of their VM.  This is no different than Ocaml.

Performance is different :) That's why I use Ocaml native code
exclusively, which doesn't support dynamic loading (yet :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


^ permalink raw reply	[flat|nested] 40+ messages in thread
* RE: [Caml-list] Interactive technical computing
@ 2007-03-09 13:33 Robert Fischer
  2007-03-09 13:49 ` Jon Harrop
  2007-03-09 13:54 ` skaller
  0 siblings, 2 replies; 40+ messages in thread
From: Robert Fischer @ 2007-03-09 13:33 UTC (permalink / raw)
  To: caml-list

>> After all, Java and C# aren't intended to be used like that, yet they
>> certainly have wide-spread adoption.
>
> They don't make binary shared libraries
> because the architecture is a virtual machine driven by
> bytecode .. they DO make dynamically linkable bytecode
> libraries.
>
As long as you play within the bounds of their VM.  This is no different than Ocaml.

~~ Robert.

-----Original Message-----
From: skaller [mailto:skaller@users.sourceforge.net]
Sent: Thursday, March 08, 2007 6:04 PM
To: Robert Fischer
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] Interactive technical computing


On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages).  I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.

It is in fact an utter and complete show stopper.
I've spent 6 years developing Felix precisely to solve this
problem: a high level language that can generate shared libraries
which can use and be used by other shared libraries.

Ocaml is great for stand-alone programs but a significant
fraction of software development is library building,
and Linux distros such as those based on Debian provide
a library component model which demands dynamic linkage
so the components can be upgraded without end user recompilation.

I expect this will eventually be solved too.

> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.

They don't make binary shared libraries
because the architecture is a virtual machine driven by
bytecode .. they DO make dynamically linkable bytecode
libraries.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


^ permalink raw reply	[flat|nested] 40+ messages in thread
* Interactive technical computing
@ 2007-03-08  1:13 Jon Harrop
  2007-03-08  1:49 ` [Caml-list] " Jim Miller
                   ` (3 more replies)
  0 siblings, 4 replies; 40+ messages in thread
From: Jon Harrop @ 2007-03-08  1:13 UTC (permalink / raw)
  To: caml-list


Being a user of both OCaml and Mathematica, playing with the new F# language 
from Microsoft and watching tutorial videos about VPython:

  http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries

has given me a lot of inspiration about interactive technical computing 
environments. This class of applications is hugely useful for working 
scientists and engineers because it lets you slice and dice your data in 
interesting ways whilst also giving you visual throwback and even letting you 
do some fancy visualisations.

For example, I'm in the process of updating my ray tracer language comparison:

  http://www.ffconsultancy.com/languages/ray_tracer/index.html

and I'm using a mix of OCaml (to fire off compilation and execution commands) 
and Mathematica (to dissect the results, compute verbosity using regexps and 
plot graphs):

  http://www.ffconsultancy.com/tmp/mathematica.png

Mathematica's equivalent of the OCaml top-level is called a notebook. It 
provides expression input and result output, just like OCaml, but integrates 
graphics, adds typesetting and lots of mathematical functions. However, it is 
widely used for more general purpose programming despite being very slow.

Using F# from Visual Studio 2005 provides some of this functionality. The 
following screenshots illustrate 2D and 3D graphics spawned from an F# 
interactive session using a little of my own code and DirectX/ComponentsXtra:

  http://www.ffconsultancy.com/tmp/fs_xygraph.png
  http://www.ffconsultancy.com/tmp/fs_3dplot.png

For all non-trivials examples in F# it is necessary to spawn a separate thread 
to handle the GUI of the visualization, or the GUI will hang when the 
top-level is doing an intensive computation.

I think F# has a great future because of its ability to spawn visualizations 
from a running interactive session. Expensive commercial offerings like 
Matlab and Mathematica are ok when you're doing something they have built-in 
(e.g. a Fourier transform) but when you're problem is not trivially 
decomposed into their built-in operators (e.g. a wavelet transform), F# and 
OCaml are typically 2-5x faster, and when you must resort to more general 
purpose programming F# and OCaml are often 100x faster.

However, there is a lot of work to be done in getting competitive charting and 
visualization tools into F# and I'm thinking that OCaml could benefit from a 
joint venture here. Low-level routines would target DirectX in F# and OpenGL 
in OCaml but high-level routines could be language and platform agnostic, 
handling a scene graph that is essentially a typed version of Mathematica's 
to provide much faster graphics and even interactive visualisation 
(Mathematica is software rendered and not interactive!).

This raises several questions:

. What OCaml programs currently allow OpenGL-based visualizations to be 
spawned from the top-level?

. Has anyone tried to write an IDE that mixes OCaml code with graphics?

. Would anyone here be interested in a low-cost cross-platform technical 
computing environment based upon the OCaml and F# languages?

Obviously I'm interested in this from a commercial perspective. That looks 
easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not as 
portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and even 
make the library available to other .NET languages (albeit with a 
significantly less productive API).

Finally, I'd like to note that operator overloading is probably the single 
biggest difference between my F# and OCaml code. The ability to apply + and - 
to many types, particularly vectors and matrices, makes this kind of work so 
much easier. Even if you have to add the odd type annotation. So I'd love to 
see a compatible implementation of overloading introduced into OCaml.

I'd like to hear everyone's opinions on this as, it seems to me, we're sitting 
on the foundations of a great technical computing system.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2007-03-30 11:36 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-08 21:26 [Caml-list] Interactive technical computing Robert Fischer
2007-03-09  0:04 ` skaller
2007-03-09 10:06   ` Jon Harrop
2007-03-09 10:25 ` Jon Harrop
2007-03-10 14:55 ` Richard Jones
2007-03-10 22:07   ` Michael Vanier
2007-03-29  0:33     ` Jon Harrop
2007-03-29  8:41       ` Joel Reymont
2007-03-30 11:31         ` Jon Harrop
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 17:41 Robert Fischer
2007-03-09 15:35 Robert Fischer
2007-03-09 14:21 Robert Fischer
2007-03-09 14:13 Robert Fischer
2007-03-09 15:21 ` skaller
2007-03-09 17:26 ` Jon Harrop
2007-03-09 18:50 ` Jon Harrop
2007-03-09 13:33 Robert Fischer
2007-03-09 13:49 ` Jon Harrop
2007-03-09 13:54 ` skaller
2007-03-08  1:13 Jon Harrop
2007-03-08  1:49 ` [Caml-list] " Jim Miller
2007-03-08  2:52   ` skaller
2007-03-08  3:00     ` Jim Miller
2007-03-08  3:10       ` skaller
     [not found]         ` <beed19130703071919g1f537f59o93ce06871fba8f3a@mail.gmail.com>
2007-03-08  3:27           ` skaller
2007-03-08  3:36             ` Jim Miller
2007-03-08 21:16               ` Richard Jones
     [not found]                 ` <45F10E90.5000707@laposte.net>
2007-03-09  7:43                   ` Matthieu Dubuget
2007-03-10 14:58                     ` Richard Jones
2007-03-08 12:22             ` Gerd Stolpmann
2007-03-08 14:24               ` Christophe TROESTLER
2007-03-08 19:34                 ` Jon Harrop
2007-03-08 20:34                   ` Christophe TROESTLER
2007-03-09 10:22                     ` Jon Harrop
2007-03-09 10:45                       ` Christophe TROESTLER
2007-03-08  2:12 ` Erik de Castro Lopo
2007-03-08 11:12 ` Andrej Bauer
2007-03-08 11:59 ` Vu Ngoc San
2007-03-08 12:43   ` Jon Harrop
2007-03-08 21:28     ` Vu Ngoc San
2007-03-09  0:14       ` skaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).