I just published results for the ray tracer benchmark written in HLVM and
compared to other languages including OCaml:
http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html
Note that these results were obtained with HLVM's multicore garbage collector
enabled.
-
On Monday 28 September 2009 01:35:32 David McClain wrote:
> Yes, this is beginning to sound very interesting...
FWIW, I wrote this up as a blog post here:
http://flyingfrogblog.blogspot.com/2009/09/f-vs-ocaml.html
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
On Sun, Sep 27, 2009 at 03:09:02PM -0700, David McClain wrote:
> ... remember too, in signal and image processing applications,
> converting to raw machine integers and plowing ahead is often
> counterproductive.
>
> Rather we need saturating arithmetic to avoid abrupt transitions on
> overf
On Monday 28 September 2009 01:35:32 David McClain wrote:
> Yes, this is beginning to sound very interesting... So now that you
> have F#, which I understand to be some derivative of OCaml,
F# is superficially similar to OCaml, most notably its OCaml-like syntax, but
there are some quite major di
On Sep 27, 2009, at 16:14 PM, Jon Harrop wrote:
Here is a better one-line F# solution:
images |> Array2D.map (fun xs -> Array.sortInPlaceWith compare xs;
xs.[m/2])
This solves your problem from the REPL in 0.34s. Moreover, you can
easily
parallelize it in F#:
Parallel.For(0, n, fun y
On Sunday 27 September 2009 22:58:59 David McClain wrote:
> On Sep 27, 2009, at 12:25 PM, Jon Harrop wrote:
> > where the "kthSmallest" and "Array2D.parallelInit" functions are both
> > polymorphic. The former handles implicit sequences of any comparable
> > type and
> > the latter handles 2D array
On Sunday 27 September 2009 23:09:02 David McClain wrote:
> ... remember too, in signal and image processing applications,
> converting to raw machine integers and plowing ahead is often
> counterproductive.
>
> Rather we need saturating arithmetic to avoid abrupt transitions on
> overflow conditio
... remember too, in signal and image processing applications,
converting to raw machine integers and plowing ahead is often
counterproductive.
Rather we need saturating arithmetic to avoid abrupt transitions on
overflow conditions, or modulo addressing. Neither of these is native
to SSM,
On Sep 27, 2009, at 12:25 PM, Jon Harrop wrote:
where the "kthSmallest" and "Array2D.parallelInit" functions are both
polymorphic. The former handles implicit sequences of any comparable
type and
the latter handles 2D arrays of any element type. This use of
polymorphic
But facing a situa
On Sunday 27 September 2009 18:43:24 David McClain wrote:
> ... as a specific example, I remember dealing with stacks of images
> taken from an infrared imaging sensor -- perhaps 256 images, each of
> which is, say 512 x 512 pixels. I needed to obtain median pixel values
> from the stack and produc
Interesting quote from a Wikipedia article on JIT compiling...
"...For instance, most Common Lisp systems have a compile function
which can compile new functions created during the run. This provides
many of the advantages of JIT, but the programmer, rather than the
runtime, is in control o
... as a specific example, I remember dealing with stacks of images
taken from an infrared imaging sensor -- perhaps 256 images, each of
which is, say 512 x 512 pixels. I needed to obtain median pixel values
from the stack and produce one "median image", as well as perform
thresholding, mas
Okay, I think I may be seeing what you are driving at...
In order for any language to statically accommodate polymorphism, some
uniform (boxed) representation of possible operands is needed.
Whereas, with JIT, you have the option of detecting unboxed types at
runtime and dispatching to code
On Sun, Sep 27, 2009 at 6:57 PM, David McClain wrote:
> And forgive me for asking what may seem a question with an obvious
> answer... but now don't you also have to change the OCaml compiler back end
> to target the HLVM?
>
The current "example" provided with HLVM is a very minimal ML-style lan
Wow! Thanks for that much more substantive feedback on HLVM.
I am not intimately familiar with LLVM. I am surprised that JIT can
offer speedups over statically compiled code.
And forgive me for asking what may seem a question with an obvious
answer... but now don't you also have to change t
On Saturday 26 September 2009 18:21:21 David McClain wrote:
> What, in particular, sets HLVM apart. Surely not just the native
> machine types?
JIT compilation opens up several hugely-productive optimizations:
1. Polymorphism no longer persists to run-time so there is no need for a
uniform repre
Yes, I saw those references already. Still not enough information...
What, in particular, sets HLVM apart. Surely not just the native
machine types?
Are you handling array references in some unusually efficient manner?
Are you avoiding unnecessary copy-on-writes of large arrays by some
fo
On Saturday 26 September 2009 17:33:41 David McClain wrote:
> Hello Jon,
>
> I searched around for information on HLVM, and what, in particular,
> makes it so well suited for scientific computing. I also have a long-
> standing interest in scientific computing and OCaml, dating back to
> 1999 when
Hello Jon,
I searched around for information on HLVM, and what, in particular,
makes it so well suited for scientific computing. I also have a long-
standing interest in scientific computing and OCaml, dating back to
1999 when I created my NML system.
However, wherever I found a reference
On Friday 13 March 2009 20:40:10 Mikkel Fahnøe Jørgensen wrote:
> 2009/3/13 Jon Harrop :
> > On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> >> Well, I have my first working GC running in HLVM now! Woohoo!
> >
> > I have just updated HLVM's GC to use a hash table instead of a linear
> > search
2009/3/13 Jon Harrop :
> On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
>> Well, I have my first working GC running in HLVM now! Woohoo!
>
> I have just updated HLVM's GC to use a hash table instead of a linear search
> of the allocated list. This brings GC time down from O(n^2) to amortized
>
On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> Well, I have my first working GC running in HLVM now! Woohoo!
I have just updated HLVM's GC to use a hash table instead of a linear search
of the allocated list. This brings GC time down from O(n^2) to amortized
O(n). In practice, the benchmar
On Mon, Mar 09, 2009 at 04:13:11AM +, Jon Harrop wrote:
> On Sunday 08 March 2009 09:35:42 Richard Jones wrote:
> > On Sun, Mar 08, 2009 at 02:45:41AM +, Jon Harrop wrote:
> > > On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> > > > I have applied to the OCaml Forge to create a new proj
On Monday 09 March 2009 11:37:52 Jon Harrop wrote:
> HLVM aspires to provide the following benefits over OCaml:
I forgot the second most important goal (!):
. Easy and efficient parallelism to leverage multicores.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_
On Monday 09 March 2009 09:04:57 Jan Kybic wrote:
> > The OCaml Forge has kindly accepted to host the HLVM project:
> >
> > http://hlvm.forge.ocamlcore.org
>
> Hello. Just out of curiosity:
>
> I recall reading that one of your priorities for HLVM is performance of
> numerical code.
HLVM aspire
> The OCaml Forge has kindly accepted to host the HLVM project:
>
> http://hlvm.forge.ocamlcore.org
>>
Hello. Just out of curiosity:
I recall reading that one of your priorities for HLVM is
performance of numerical code. Does it mean that you expect numerical
code to run faster than natively c
On Sunday 08 March 2009 09:35:42 Richard Jones wrote:
> On Sun, Mar 08, 2009 at 02:45:41AM +, Jon Harrop wrote:
> > On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> > > I have applied to the OCaml Forge to create a new project for HLVM
> > > where I will upload my initial prototype.
> >
> >
On Sunday 08 March 2009 09:43:37 Joel Reymont wrote:
> On Mar 8, 2009, at 2:45 AM, Jon Harrop wrote:
> > The OCaml Forge has kindly accepted to host the HLVM project:
> >
> > http://hlvm.forge.ocamlcore.org
>
> Am I the only one who VASTLY prefers the clean, uncluttered and easy
> to use GitHub in
On Mar 8, 2009, at 2:45 AM, Jon Harrop wrote:
The OCaml Forge has kindly accepted to host the HLVM project:
http://hlvm.forge.ocamlcore.org
Am I the only one who VASTLY prefers the clean, uncluttered and easy
to use GitHub interface to the *Forge one?
---
http://tinyco.de
Mac, C++, OCa
On Sun, Mar 08, 2009 at 02:45:41AM +, Jon Harrop wrote:
> On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> > I have applied to the OCaml Forge to create a new project for HLVM where I
> > will upload my initial prototype.
>
> The OCaml Forge has kindly accepted to host the HLVM project:
>
On Sunday 08 March 2009 01:19:20 Jon Harrop wrote:
> I have applied to the OCaml Forge to create a new project for HLVM where I
> will upload my initial prototype.
The OCaml Forge has kindly accepted to host the HLVM project:
http://hlvm.forge.ocamlcore.org
If you are interested in following,
Well, I have my first working GC running in HLVM now! Woohoo!
The implementation has some interesting properties:
. The GC is written entirely in HLVM's own intermediate language.
. When a new type is defined a new function to traverse that type is JIT
compiled. So code for the GC is generated
32 matches
Mail list logo
