On Dec 12, 2010, at 16:55 , Török Edwin wrote:
On Sun, 12 Dec 2010 14:54:14 -
Jon Harrop j...@ffconsultancy.com wrote:
The Haskell guys got their best performance improvement moving to
LLVM from the hailstone benchmark so it is interesting to examine
this case as well. I just added
On Dec 5, 2010, at 23:34 , Erik de Castro Lopo wrote:
Benedikt Meurer wrote:
Using a different data representation within OCaml would indeed be
possible, but one has to ask what it's worth?
Is it necessary to use a different data representation? What does
that buy you?
Read my mail
On Dec 5, 2010, at 17:13 , Basile Starynkevitch wrote:
On Sun, 5 Dec 2010 17:02:37 +0100
CUOQ Pascal pascal.c...@cea.fr wrote:
ygrek wrote:
BTW, while we are on this topic, why the following is not in upstream yet?
http://eigenclass.org/R2/writings/optimizing-caml_modify
Looks like
On Dec 5, 2010, at 17:57 , Török Edwin wrote:
On Sun, 5 Dec 2010 17:37:32 +0100
Benedikt Meurer benedikt.meu...@googlemail.com wrote:
Two main areas for now: The GC interface and the exception handling.
LLVM's exception support is really limited; the GC support is better
and more generic
On Dec 5, 2010, at 21:12 , Jon Harrop wrote:
Benedikt wrote:
On Dec 3, 2010, at 21:07 , Jon Harrop wrote:
Benedikt wrote:
So, let's take that LLVM thing to a somewhat more serious level
(which
means no more arguing with toy projects that simply ignore the
difficult stuff).
You can
On Dec 5, 2010, at 22:21 , Benedikt Meurer wrote:
On Dec 5, 2010, at 21:12 , Jon Harrop wrote:
Using a different data representation within OCaml would indeed be
possible, but one has to ask what it's worth? You'd get better floating
point performance (most likely)
And faster tuples
So, let's take that LLVM thing to a somewhat more serious level (which means no
more arguing with toy projects that simply ignore the difficult stuff). What
would be necessary to support LLVM in ocamlopt, and what would be the benefits?
First, what has to be done:
1. Obviously, one would need
On Dec 1, 2010, at 15:11 , Jon Harrop wrote:
If you're asking what the advantages of using LLVM over generating C code
are, I'd say functionality like more numeric types, tail calls and JIT
compilation come top but also the fact that LLVM bundles nice OCaml bindings
and makes it easy to
On Nov 30, 2010, at 11:48 , Török Edwin wrote:
In short: Performance measured on a P4 Northwood (no long mode,
plain x86) 2.4GHz. OCamlJIT2 beats OCamlJIT by a factor of 1.1 to 2.0
in every benchmark, and - rather surprising - was even able to beat
ocamlopt in the number crunching benchmark
On Nov 30, 2010, at 23:06 , Jon Harrop wrote:
Because benchmarks like my HLVM ones have proven that LLVM can generate
*much* faster code than ocamlopt does.
For example, Fibonacci function over floats in HLVM with optimization passes
disabled and compilation time included in the
On Nov 29, 2010, at 00:34 , Jon Harrop wrote:
I see. Yes, that sounds like a great idea. How well does Immix cope with
high allocation rates of short-lived objects? Been a while since I read the
Immix paper...
In theory this should be handled more efficiently compared to a generational
On Nov 28, 2010, at 20:40 , Jon Harrop wrote:
I don’t understand why this would help here though. Wouldn’t that help when a
long-lived structure was single large block but, in this case, the long-lived
structure is a tree composed of many small heap-allocated blocks and,
therefore, they
On Nov 20, 2010, at 16:19 , Vincent Balat wrote:
On Nov 19, 2010 21:20:01, Yoann Padioleau wrote:
On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
...
Actually, Facebook has a compiler that transforms PHP source code into
C++ [1], and they claim a 50% reduction in CPU usage.
Yes,
On Nov 20, 2010, at 17:10 , Yoann Padioleau wrote:
It's probably not a technical decision, but more likely a marketing
decision. If you tell Joe
Who is Joe ? A developer ? A user ? A venture capitalist ?
Joe is 99.9% of world's population, excluding experts in this special area.
that
script prints a line
indicating whether the JIT engine is enabled or not (if not, it'll be just a
regular OCaml 3.12 installation).
Comments are welcome.
Enjoy!
Benedikt Meurer
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi
On Nov 19, 2010, at 19:30 , Ashish Agarwal wrote:
On Fri, Nov 19, 2010 at 1:24 PM, Hezekiah M. Carty hca...@atmos.umd.edu
wrote:
ocamlscript is certainly a wonderful tool, for prototyping and
otherwise. It unfortunately doesn't help specifically with the load
a large file and do
On Nov 19, 2010, at 19:43 , Yoann Padioleau wrote:
OCamlJit 2.0 was specifically designed for desktop processors and is not
really portable to anything else in its current shape, because the target
audience are people using the interactive top-level and the byte-code
interpreter for rapid
On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote:
Benedikt Meurer wrote, On 11/19/2010 06:29 AM:
This is indeed very interesting. I haven't thought of the native top-level.
I haven't done any measurements yet, but from my experience with ocamlopt, I
know that the optimizing native
On Nov 17, 2010, at 09:44 , Alain Frisch wrote:
There is actually already a native top-level in the distribution, even though
it is undocumented and unmaintained. You can build it with the make
ocamlnat target. The implementation is based on the same approach as native
dynlink. The
was not a goal for the current implementation).
HTH,
Benedikt Meurer
___
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
20 matches
Mail list logo
