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.
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
On Sun, Sep 27, 2009 at 6:57 PM, David McClain d...@refined-audiometrics.com
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
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
... 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,
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 produce
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
... 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
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 conditions,
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 arrays of any
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 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
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 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 I
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
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
On Friday 13 March 2009 20:40:10 Mikkel Fahnøe Jørgensen wrote:
2009/3/13 Jon Harrop j...@ffconsultancy.com:
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
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
2009/3/13 Jon Harrop j...@ffconsultancy.com:
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
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
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 aspires to
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 project for
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 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++,
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 interface
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.
The OCaml
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
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,
28 matches
Mail list logo
