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
Hi,
I think what Jon means is that, with JIT, polymorphic functions can be
specialized at run-time
and allow optimizations that are not currently achieved by the Ocaml
native code compiler.
V.
Le 27 sept. 09 à 19:18, David McClain a écrit :
Ahh, I see from doing a bit more research that
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
Vincent Aravantinos wrote:
Hi,
I think what Jon means is that, with JIT, polymorphic functions can be
specialized at run-time
and allow optimizations that are not currently achieved by the Ocaml
native code compiler.
V.
The alternative to specializing at runtime using JIT is to do it at
... 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:35:32 Edgar Friendly wrote:
Vincent Aravantinos wrote:
I think what Jon means is that, with JIT, polymorphic functions can be
specialized at run-time and allow optimizations that are not currently
achieved by the Ocaml native code compiler.
The alternative
Jon Harrop wrote:
C++ has those features and they are blamed for slow compilation. However,
separate compilation is not the issue so much as dynamic loading.
Yes, dynamic loading doesn't mix with whole-program analysis. Although
I wonder if it's possible to have our cake and eat it too, with
I think
that an OCaml-like language that addresses OCaml's performance
(including
parallelism) and FFI issues would be much more widely useful and is an
entirely achievable goal.
I'm not as committed to abandoning OCaml as you seem, and have hope for
incremental improvement of OCaml's
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 Sunday 27 September 2009 20:23:13 kche...@math.carleton.ca wrote:
I'm not as committed to abandoning OCaml as you seem, and have hope for
incremental improvement of OCaml's weaknesses, although I realize we'll
have to break a number of things to get to where we both (and likely
many
Hello,
I'm trying to have bin-prot compiled with mingw version of OCaml with
the original OCamlMakefile.
This fails on my computer.
I reproduced the problem here:
On linux, there is no problem:
$ uname
Linux
$ echo $BIN_PROT_CPP
cpp
$ echo $pp
$BIN_PROT_CPP $ARCH_FLAGS
$ ocamlc -c -verbose -pp
On Sunday 27 September 2009 20:23:13 kche...@math.carleton.ca wrote:
If Grand Central Dispatch makes its way
into *nix...
Incidentally, what exactly (technically) is Grand Central and how does it
relate to existing alternatives and the state-of-the-art? I Googled it but
failed to find
Le 27 sept. 09 à 23:10, Jon Harrop a écrit :
On Sunday 27 September 2009 20:23:13 kche...@math.carleton.ca wrote:
If Grand Central Dispatch makes its way
into *nix...
Incidentally, what exactly (technically) is Grand Central and how
does it
relate to existing alternatives and the
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
We should thank them for enlightening us but this will only
ever get built if we build it ourselves. But, hey, at least we can build it
in OCaml. ;-)
So that's why I was reminded of John Skaller all this time...
Pascal
winmail.dat___
Caml-list
... 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
21 matches
Mail list logo
