Benedikt wrote:
> Nice. But it would be even better to avoid the dummy, in your example
>
> let x = u in
> let y = v in
> if b then x <- v; y <- u
>
> This does not only avoid the dummy, but would also allow lowering to
> "cmovcc" instructions in the backend selector (atleast for x86-32/64)
Edwin wrote:
> http://www.hackersdelight.org/HDcode/magic.c.txt
> http://www.hackersdelight.org/HDcode/magicu.c.txt
Nice! :-)
Cheers,
Jon.
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Ar
Edwin wrote:
> On Sun, 12 Dec 2010 22:05:34 -
> Jon Harrop wrote:
> > Edwin wrote:
> > > AFAICT LLVM's OCaml bindings are only good for generating LLVM IR
> > > from OCaml, not for actually performing transformations on it
> > > (there is no binding
Edwin wrote:
> AFAICT LLVM's OCaml bindings are only good for generating LLVM IR from
> OCaml, not for actually performing transformations on it (there is no
> binding to retrieve the type of a value for example). I'll probably be
> looking into fixing that in the near future, and this may indirect
Benedict wrote:
> > A C compiler would optimize this to a right shift. Changing that to
> > 'Int64.shift_right n 1' speeds up the code.
>
> This is easy to fix in ocamlopt (see attached patch ocamlopt-
> natint.patch), by applying the same optimizations already used for
> constant int's to constant
Brian Hurt wrote:
> On Sun, 12 Dec 2010, Jon Harrop wrote:
> > let rec collatzLen(c, n) : int =
> >if n = 1L then c else
> > collatzLen (c+1, if Int64.rem n 2L = 0L then Int64.div n 2L else
> > Int64.add (Int64.mul 3L n) 1L);;
> >
> > let rec loop(
Török Edwin wrote:
> Do you really need to use Int64 for that though? Won't the 63-bit
> version do?
I'm running 32-bit.
> > I am unable to reproduce your results. Here, the time falls from 24s
> > to 19.5s (using ocamlopt 3.12.0 on Intel x86) which is still 26×
> > slower than HLVM.
Sorry, I'm
Török Edwin wrote:
> Problem #1: Int64.rem n 2 -> another idiv instruction
>
> A C compiler would optimize this to an 'and' instruction.
> Change that to 'Int64.logand n 1L = 0L'/
Yes. LLVM did that for me.
> Problem #2: Int64.div n 2 -> idiv instruction.
>
> A C compiler would optimize this to
running 32× faster than the OCaml here.
2. LLVM makes it easy to JIT fast code from OCaml. HLVM is using it to beat
GCC-compiled C code here.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com
___
Caml-list mailing list. Sub
Benedikt wrote:
> Also looking at the GHC work you mentioned, they also start at the Cmm
> level (slightly different C--, but comparable to ocamlopt), with mostly
> the same amount of type information available. And as you said, they
> did quite well in some cases.
Yes. They did well in benchmarks
Richard Jones wrote:
> It might kick-start efforts to automatically generate bindings, at
> least to C code, which wouldn't be a bad thing. camlidl is clumsy and
> doesn't handle a very important case (pointers to handles) so it's not
> really useful for this.
Yes, LLVM is ideal for this. Using L
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).
Michael:
> We would also get new optimizations developed by the compiler backend
> and computer architecture researchers working on LLVM for free. I see
> that as one of the major benefits - it lets the OCaml community harness
> that work (and share it with other languages) and focus our energies
Philippe wrote:
> I'm totally noob on compilers internals, but if the processing of float
> arrays can be improved a lot by a LLVM ocamlopt, I would use it
> exclusively.
LLVM's x86 code gen will generate more efficient floating point code than
ocamlopt if and only if the type information is avail
Till wrote:
> You seem to think LLVM wouldn't actually buy us much in term of
> optimisations. In my experience the current ocaml compiler is really
> good when writing code fairly low level but discourages use of
> combinator library, higher order functions, functors in performance
> sensitive cod
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 learn a lot from prototypes.
> 3. A better LLVM. If we do it right, other's implementing functional
> languages usi
Benedikt wrote:
> 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
Benedikt wrote:
> This has nothing to do with LLVM, but is simply due to the fact that
> your code does not box the float parameters/results.
Exactly, yes.
> The following peace of C code is most probably even faster than your
> code, so what?
>
> double fib(double x) { if (x < 1.5) return x else
Erik wrote:
> Jon wrote:
> > LLVM is also much better documented than ocamlopt's internals.
>
> LLVM has well over 20 full time programmers working on it. The
> Ocaml compiler has how many?
Another reason why LLVM deserves its hype.
Cheers,
Jon.
___
Yoann wrote:
> Yes, and it has to stop. I don't understand why there is so much hype
around LLVM. Why
> would you think something written in C++ would be far better than the
ocaml code we have
> in the ocamlopt compiler?
Because benchmarks like my HLVM ones have proven that LLVM can generate
*much
Bluestorm wrote:
> - more optimizations : the LLVM guys try to develop a wide range of
optimization passes between
> LLVM IR and native code, while ocamlopt is mostly a "non-optimising
compiler". It's not clear
> however how much gain we could have, as OCaml has already optimized the
most important
What would be responsible for collecting the shared heap?
Cheers,
Jon.
Eray wrote:
> Seconded, why is this not possible? That is to say, why cannot each thread
maintain a separate GC,
> if so desired?
___
Caml-list mailing list. Subscription managemen
I assume he means one thread has one behaviour and another has the other
behaviour, in which case there certainly is a problem!
Cheers,
Jon.
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Christophe Raffalli
> Sent:
ia.fr] On Behalf Of Benedikt Meurer
> Sent: 28 November 2010 20:00
> To: caml-list@yquem.inria.fr
> Subject: Re: [Caml-list] OCaml GC [was Is OCaml fast?]
>
>
> On Nov 28, 2010, at 20:40 , Jon Harrop wrote:
>
> > I don't understand why this would help here thoug
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 would undergo the same wasteful "allocate in young only
t
Stefan wrote:
> I think OCaml's
> problem with this benchmark do point at a weakness of the current
> GC code.
A difference but not necessarily a weakness. OCaml makes performance
transparent and gives you the ability to improve it with a high glass
ceiling. I prefer that to hiding the controls an
idiomatic
OCaml/Java code.
Cheers,
Jon.
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Erik de Castro Lopo
> Sent: 24 November 2010 01:24
> To: caml-l...@inria.fr
> Subject: Re: [Caml-list] Is OCaml fas
Oliver wrote:
> AFAIK in the past, functional langauges were not adapted, because they
> were
> very unperformant - at least this is one reason.
> Another reason might be, that the available functional languages in the
> past
> were overloaded with parenthess ;)
That was also true of early ML impl
Yes, an answer to a better question.
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Isaac Gouy
> Sent: 23 November 2010 18:07
> To: caml-l...@inria.fr
> Subject: [Caml-list] Re: Is OCaml fas
Note that the regex-dna solution for Haskell tweaks its GC parameters via
the -H command-line parameter:
http://shootout.alioth.debian.org/u64q/program.php?test=regexdna&lang=ghc&id
=2
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.f
ion/3.12/byterun/config.
h?rev=10787&r1=10496&r2=10787> &r1=10496&r2=10787
Cheers,
Jon.
From: Eray Ozkural [mailto:examach...@gmail.com]
Sent: 22 November 2010 23:14
To: Jon Harrop
Cc: Sylvain Le Gall; caml-l...@inria.fr
Subject: Re: [Caml-list] Re: Optimizing garbage co
And almost all of the "Haskell" solutions (reverse-complement,
spectral-norm, Mandelbrot, n-body, fannkuch-redux, k-nucleotide, regex-dna)
abuse GHC's FFI in order to work around Haskell.
The k-nucleotide benchmark in Haskell even uses malloc! Ketil Malde crafted
a much better solution but noted:
What happens if you just increase the default size?
___
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_beginne
Sylvain Le Gall:
> I doubt an old code, not written with multicore in mind is easily
> portable to multicore. So basically, the migration you are talking
> about
> is starting a new project that will replace one software/library by
> another.
Yes, the systems are kept loosely coupled during the tr
Yoann Padioleau wrote:
> On Nov 20, 2010, at 9:08 AM, Jon Harrop wrote:
> >> Do we have example of big companies porting their whole codebase to
> >> another language ?
> >
> > Yes, of course. Companies modernise all the time. We have a client
> > who jus
> Do we have example of big companies porting their whole codebase to
> another language ?
Yes, of course. Companies modernise all the time. We have a client who just
started porting 1MLOC of C++ to F#. Flying Frog have ported hundreds of
thousands of lines of OCaml to F#. It happens all the time
> This is actually a quick way to use multiple cores with ocaml. Find a
> often called function that takes considerable time and offload it to C
Or HLVM, F#, Scala, Clojure or any of the other languages that permit shared
memory parallelism. C is particularly poor in this regard so I would not
jus
Also for interactive data massaging and visualization.
From: caml-list-boun...@yquem.inria.fr
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Ashish Agarwal
Sent: 18 November 2010 16:50
To: Alain Frisch
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Native toplevel? (was: OCamlJit
Can you cite any papers from this century? ;-)
Cheers,
Jon.
From: Eray Ozkural [mailto:examach...@gmail.com]
Sent: 17 November 2010 13:41
To: Eray Ozkural; Jon Harrop; caml-list@yquem.inria.fr
Subject: Re: [Caml-list] SMP multithreading
On Wed, Nov 17, 2010 at 8:50 AM, Gabriel
Granularity and cache complexity are the reasons why not. If you find
anything and everything that can be done in parallel and parallelize it then
you generally obtain only slowdowns. An essential trick is to exploit
locality via mutation but, of course, purely functional programming sucks at
that
Wolfgang wrote:
> I'd like to point out how the big competitor to OCaml deals with it.
> The GHC Haskell system has SMP parallization built in for some time,
> and it does it quite well.
I beg to differ. Upon trying to reproduce many of the Haskell community's
results, I found that even their own
un...@yquem.inria.fr] On Behalf Of Stephan Tolksdorf
> Sent: 10 November 2010 16:11
> To: caml-l...@inria.fr
> Subject: Re: [Caml-list] Infix function composition operator
>
> On Wed, Nov 10, 2010 at 14:13 -, Jon Harrop wrote:
> > However, I don't see it as a useful advanta
r
> Subject: Re: [Caml-list] Infix function composition operator
>
> So how does value restriction affect things here? (excuse my lack of
> knowledge)
>
> One thing about using a pipeline like this is that it relies on '|>'
> being
> left-associative (w
A pipeline operator is usually preferred over function composition in impure
languages like OCaml and F# due to the value restriction. For example, your
example would be written in F# as:
x |> op1 |> op2 |> op3 |> op4 |> op5
This style is very common in F#, particularly when dealing with coll
mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Michael Ekstrand
> Sent: 30 October 2010 18:38
> To: caml-list@yquem.inria.fr
> Subject: Re: [Caml-list] How does OCaml update references when values
> are moved by the GC?
>
> On 10/30/2010 12:15 PM, Jon Harrop wrote:
&g
f the whole application.
> -Original Message-
> From: Jon Harrop [mailto:j...@ffconsultancy.com]
> Sent: 30 October 2010 18:16
> To: 'Damien Doligez'; 'caml-l...@inria.fr'
> Subject: RE: [Caml-list] How does OCaml update references when values
> are move
gt;
> On 2010-10-28, at 23:48, Jon Harrop wrote:
>
> > How does OCaml update references in the stacks and heap when values
> are
> > moved by the GC?
>
>
> They are updated by the GC, of course.
>
> -- Damien
>
> _
How does OCaml update references in the stacks and heap when values are
moved by the GC?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin
Is there a tutorial on using something like LWT for asynchronous programming
in OCaml? I'm looking for an example like an echo server that handles
clients concurrently without blocking threads, so it can handle thousands of
clients without significant performance degradation.
--
Dr Jon H
Note that you are using physical equality (==) and not structural equality
(=).
Also, you can always rewrite:
if then true else false
more simply as:
> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of ben kuin
>
> Hmm, this would only optimize the bytecode fetch/decode step of the ocaml
execution cycle. I am not sure that it will result in much real-world
speedup.
Would be interesting to try. I suspect the C compiler would then optimize
the sequences of operations on the data as well. For example, somethi
> * Hacking a C generator inside Ocaml is non-trivial, because of the
> garbage collector, currified function calls, and tail recursion
> etc.
BTW, I was always surprised nobody had converted the bytecode interpreter
into a via-C compiler by unwinding the C code the interpreter goes thro
> Other GC algorithm for Java/C# often made the assumption of long-living
> objects with mutation. This is not the case for OCaml.
They do favour mutation and, consequently, have cheaper write barriers but
both the JVM and CLR use pointer-bumping minor heaps for the first "nursery"
generation to c
Hi Eray,
Retrofitting a new multicore-friendly GC onto OCaml is difficult for two
main reasons:
1. You want plug-and-play GCs but the OCaml compiler is tightly coupled to
the old GC (although OC4MC has decoupled them!).
2. Recovering similar performance whilst reusing the same data
representatio
> Intel is developing a functional language which will scale
> on multicore machines
This sounds very interesting. Any references or a name?
Cheers,
Jon.
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listin
You might prefer to multiply by 1.0 because adding 0.0 changes -0.0.
Cheers,
Jon.
> Some black magic is needed:
>
> let r = ref 0.0 in
> for i = 0 to 1000_000_000 do r := float i done;
> Printf.printf "%f\n" (!r +. 0.);
> Printf.printf "words: %f\n" (Gc.stat ()).Gc.minor_words
>
> and the refer
If you can keep it agnostic wrt boxing then you should be able to plug it
into HLVM easily for much faster numerics and parallelism.
Cheers,
Jon.
From: ivan chollet [mailto:ivan.chol...@gmail.com]
Sent: 30 August 2010 18:10
To: Jon Harrop
Cc: Jeremy Bem; caml-list List
Subject: Re: [Caml
Try to remove all assumptions of uniform run-time representation from the
compiler because avoiding boxing gives huge performance gains and makes it
much easier to write a performant garbage collector. You'll need to
sacrifice polymorphic recursion though, which you probably already have
anyway.
lity types) would be worth putting in a
minimalistic language because it is so useful.
Cheers,
Jon.
From: Jeremy Bem [mailto:jere...@gmail.com]
Sent: 12 August 2010 01:22
To: Jon Harrop
Cc: bluestorm; caml-list List; Florian Weimer
Subject: Re: [Caml-list] interest in a much simpler, but mo
Ivan wrote:
> I have noted that there are now many implementation of OCaml. Namely :
> - caml light
> - jocaml
> - mincaml
> - your implementation ?
> etc.
>
> which means there is a lot of interest in implementing tools and runtimes
for ML.
I'm not sure 3.5 implementations over 25 years is a "lo
> > if Int.(x = 42) then ... else ...
> This approach is very nice indeed
What happens when you do:
if Int.(x = 42 || x = 45) then ... else ...
Presumably it either barfs on the assumption that "||" refers to bitwise-or
between ints, or we're back to inventing progressively more absurd operat
> One issue I ran into was syntactic. How would you write:
> if 'A' <= c && c <= 'Z' then ...
> where c is a char, without polymorphic comparison, and without more
radical changes such as type
> classes?
SML's ad-hoc polymorphism. Would also be nice if you could fill out the
primitive types wi
> Is there a better approach to polymorphic equality floating around?
SML's equality types are simpler than type classes and more robust than
OCaml's polymorphic equality (and comparison, and hashing). F# uses equality
types.
Cheers,
Jon.
___
Caml-lis
Xavier Clerc wrote:
> Jon Harrop a écrit :
> > I don't think this is heated at all. We were talking about "high
> > performance" languages and you cited a bunch of languages that get
> whipped
> > by Python on this benchmark:
> >
> >
> >
Xavier Clerc wrote:
> Jon Harrop a écrit :
> > Xavier Clerc:
> >> Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
> >> > Xavier Clerc wrote:
> >> >> Limiting myself to the JVM...
> >> >> Moreover, at least Scala and Bigloo deliver excelle
Xavier Clerc:
> Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
> > Xavier Clerc wrote:
> >> Limiting myself to the JVM...
> >> Moreover, at least Scala and Bigloo deliver excellent performances.
> >
> > I have benchmarks where the JVM is well over 10x slower th
Erik wrote:
> Jon Harrop wrote:
> > Not really. Windows supports a far wider variety of hardware than
> > Linux and
>
> Oh really?
Yes, really.
> I have a three machine here:
>
> a) A Dual PowerPC G5 Apple Mac.
> b) A SUN ultra-sparc X1.
> c) One of t
Raoul Duke wrote:
> On Fri, May 14, 2010 at 11:59 AM, ben kuin wrote:
> > but that would be the big benefit of a clr like vm: It doesn't matter
> > how messed up, chaotic or just heterogen the environment is as long
> > as you can count on a regular execution of your portable bytecode.
>
> of cou
Goswin wrote:
> Hardly any business today has an inhomogene environment. And if the
> environment is homogene then the vm gives you 0 advantage. It just
> costs you overhead to emulate.
A Common Language Runtime (CLR) is an obvious counter example => the shared
VM gives you safe and high-level int
Ben Kuin wrote:
> technical:
> - in .NET everything is easy (from the surface): you have your source
> file (hello.cs) you take your compiler (cs.exe) and compile it to a
> msil bytecode file (hello.dll). You can run reflection tools to
> hello.dll or link it to a exe or generate back to source. T
Xavier Clerc wrote:
> Limiting myself to the JVM...
> Moreover, at least Scala and Bigloo deliver excellent performances.
I have benchmarks where the JVM is well over 10x slower than .NET. So I do
not regard any JVM-based language as "high performance".
Cheers,
Jon.
Ben Kuin wrote:
> > A little off topic, but how is Mono/Unix these days?
> >> Still leaks memory,
> you refer to your examinations?
> (http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-
> memory.html?showComment=1233522107493#c7872630239059031867)
> where you say yes and the mono devs
Peng Zang wrote:
> It even has a native mode toplevel now that's
> suppose to be fast (anyone have any experience with this?).
You mean "ocamlnat"? The performance was great but it was buggy and I think
it never made it into mainline OCaml.
Cheers,
Jon.
_
> A little off topic, but how is Mono/Unix these days? Last I checked
> (>2 years ago) it implemented the basic libraries and runtimes but had
terrible
> performance. Is it now on par with Windows?
Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen
even farther behind n
This was a promising project from the Jane St Summer Projects 2007 that
released a 0.1 but I haven't seen anything since:
http://sourceforge.net/projects/ocaml-mf/
What is the current status of this project? Is anyone using it?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
ot;rec" is tiny so I don't think it is worth
discussing in such detail.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mai
ly incompatible, and many reasonable people
> disagree on which one of the two is more important.
>
> Stefan "who extensively used that feature in SML, but happens
> to prefer the other feature nevertheless"
Standard ML doesn't have the feature that
IIRC, there is an OCaml macro that will autogenerate the code to print values
of a variant type from the type definition. Does it handle polymorphic
variants?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml
On Wednesday 10 February 2010 22:25:44 Till Varoquaux wrote:
> Some (including me) would even argue that it is sad that type
> definitions don't use "rec".
Agreed. Less useful than "rec" on function definitions but that would still be
useful sometimes.
--
Dr Jon
redictable and high performance.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
B
82770d5e79402#3ee82770d5e79402
See my response there:
http://groups.google.com/group/comp.lang.functional/msg/2cb15a6281087b04
:-)
I was wondering if anyone here was familiar with this work and/or had anything
to say about their OCaml solutions and discussion?
--
Dr Jon Har
Anyone studied this paper by Garcia et al.:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.122&rep=rep1&type=pdf
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subs
; the namespace, personally I find it easier to read.
You can do that in OCaml as well, if you choose.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http:/
ack overflow:
http://stackoverflow.com/questions/900585/why-are-functions-in-ocaml-f-not-recursive-by-default/1891573
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management
On Tuesday 09 February 2010 22:01:03 Gerd Stolpmann wrote:
> In the ML community it is consensus that a recursive function is a total
> different thing than a non-recursive function...
Note that Standard ML does this differently to CAML/OCaml.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd
other languages for comparison. Has anyone tried to
translate this into OCaml?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo
Richard asked me to draw a comparison on 64-bit as well because OCaml
sometimes does relatively better there. With level=13, I get:
OCaml 32-bit: 118s
OCaml 64-bit: 95s
HLVM 32-bit: 34.8s
HLVM 64-bit: 30.4s
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
to force the evaluation of thunks in the shared scene tree which
incurs global synchronization in wholly unpredictable ways (it even depends
upon the layout of the scene!). So, while this is academically interesting,
I'd argue that it is practically useless.
--
Dr Jon Harrop, Flying Frog Cons
> j...@ubuntu:~/Desktop$ time ./ray 9 512 > /dev/null
>
> real 0m6.572s
> user 0m6.544s
> sys 0m0.016s
Are you running x64 or on Intel hardware? What results do you get for 12, 13
or 14 instead of 9?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy
1, you should get
> the new version of objsize -- 0.12:
> http://forge.ocamlcore.org/frs/?group_id=3
> OCaml has new heap since 3.11...
Can anyone elaborate on this?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
__
abled.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's
c. Since the latter
> intelligently produces an html file "Module.html" for a module named
> "Module" I can quickly access its documentation by invoking gnome do
> with its hot key, type an abbreviation of "Module" and hit return.
> This opens th
On Tuesday 05 January 2010 08:45:04 Maxence Guesdon wrote:
> My favorite editor is Chamo:
> http://home.gna.org/cameleon/chamo.en.html
Nice! Why do you prefer it?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.
pay 2K EUR/year
>
> Is that correct?
You could always ask nicely if they mind you violating their license. :-)
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http
ink the best way to write a decent editor for OCaml would be to write one
using LablGTK for the GUI and camlp4 to parse OCaml code.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscript
bright again. :-)
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's
wondering if anyone has studied the makeup of heaps in idiomatic OCaml
code and could point me to data on the proportion of the heap typically
consumed by duplicate references, i.e. how much space is HLVM likely to
waste?
Many thanks,
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.
On Friday 01 January 2010 22:33:42 Yoann Padioleau wrote:
> On Jan 1, 2010, at 2:29 PM, Jon Harrop wrote:
> > I think it was a big mistake for the Go developers at Google and the
> > Mono developers at Novell to not build upon LLVM.
> >
> > My main concern about other J
the fastest
compilers and it generates code that runs 2-10x faster. For example,
compiling the 155kLOC of LLVM IR generated by HLVM's test suite takes 9.65s.
I think it was a big mistake for the Go developers at Google and the Mono
developers at Novell to not build upon LLVM.
My main concern
> ld, etc. seems a much heavier and less scalable approach that generating
> code at runtime.
Sounds like you really want HLVM. :-)
> Thanks and Happy New Year, Joel
Happy New Year!
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
1 - 100 of 433 matches
Mail list logo
