* HLVM...
@ 2009-09-27 18:06 David McClain
0 siblings, 0 replies; 4+ messages in thread
From: David McClain @ 2009-09-27 18:06 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
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 of what parts of the code are compiled. This
can also compile dynamically generated code, which can, in many
scenarios, provide substantial performance advantages over statically
compiled code, as well as over most JIT systems."
Dr. David McClain
dbm@refined-audiometrics.com
[-- Attachment #2: Type: text/html, Size: 2362 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* HLVM...
@ 2009-09-27 22:09 David McClain
0 siblings, 0 replies; 4+ messages in thread
From: David McClain @ 2009-09-27 22:09 UTC (permalink / raw)
To: 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 SSM, and have to be synthesized. DSP chips on the other hand almost
always offer these variations implicitly or explicitly.
Dr. David McClain
dbm@refined-audiometrics.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* HLVM
@ 2009-09-27 16:57 David McClain
0 siblings, 0 replies; 4+ messages in thread
From: David McClain @ 2009-09-27 16:57 UTC (permalink / raw)
To: caml-list
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 the OCaml compiler
back end to target the HLVM?
Dr. David McClain
dbm@refined-audiometrics.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* HLVM
@ 2009-09-26 17:21 David McClain
0 siblings, 0 replies; 4+ messages in thread
From: David McClain @ 2009-09-26 17:21 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
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
form of whole-program analysis? I still don't have a handle on HLVM...
>
> http://www.ffconsultancy.com/ocaml/hlvm/
> http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html
Dr. David McClain
dbm@refined-audiometrics.com
[-- Attachment #2: Type: text/html, Size: 1790 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-09-27 22:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-27 18:06 HLVM David McClain
-- strict thread matches above, loose matches on Subject: below --
2009-09-27 22:09 HLVM David McClain
2009-09-27 16:57 HLVM David McClain
2009-09-26 17:21 HLVM David McClain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox