Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HLVM -- the High-Level Virtual Machine

ffconsultancy.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: HLVM -- the High-Level Virtual Machine

#21

Post by megaman821 »

akeefer wrote: post #19
megaman821 wrote: post #8

Earlier quoted context omitted.

Kind of like Java in general, the JVM sits in the middle ground. LLVM is a good starting point for building low level languages (although nothing prevents you from writing high level languages in it, you just have write more). The HLVM is supposed to be a good starting point for building high level languages with things like garbage collection, closures, tail call elimination, etc. The JVM isn't the fastest for low l…

The JVM is a great platform if the language in question is relatively close to Java, and you're just layering on higher-level syntax like closures. (Sure, it would be nice if Java supported them, but they're not hard to implement as anonymous inner classes, and to simulate real closing over variables you just need to wrap all captured variables in one-element arrays or other wrapper objects at the declaration side. I…

Maybe it is because the strategy more closely resembles the relationship between the CLR and DLR than the JVM and nothing. Like you said the JVM is not dynamic language friendly, and Sun/Oracle has really shown much interest in making it so.

Re: HLVM -- the High-Level Virtual Machine

#22

Post by cabalamat »

ramchip wrote: post #9
godDLL wrote: post #2

""" The ability to interoperate safely and at a high-level between different languages, from managed C++ to F#, has greatly accelerated development on the Microsoft platform. The resulting libraries, like Windows Presentation Foundation, are already a generation ahead of anything available on any other platform. Linux and Mac OS X do not currently have the luxury of a solid foundation like the CLR. Consequently, they…

Making portable applications isn't a solved problem. There's Java. It's decent, especially with Clojure and other JVM languages, but I find the idea of a more powerful language (like OCaml) not without merits. Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.

> Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.

What in particular about the JVM prevents Clojure from being able to do tail-call optimization? My (admittedly naive) understanding of TCO is that it involves turning tail recusion into a loop, and Java can certainly handle loops OK.

Re: HLVM -- the High-Level Virtual Machine

#23

Post by cabalamat »

megaman821 wrote: post #8
caffeine wrote: post #3

I'm curious: what about the JVM?

Kind of like Java in general, the JVM sits in the middle ground. LLVM is a good starting point for building low level languages (although nothing prevents you from writing high level languages in it, you just have write more). The HLVM is supposed to be a good starting point for building high level languages with things like garbage collection, closures, tail call elimination, etc. The JVM isn't the fastest for low l…

The great advantage of the JVM is it has tons of libraries. This means that any competitor such as HLVM will have to fight very hard to gain traction.

Re: HLVM -- the High-Level Virtual Machine

#24

Post by 45g »

crux_ wrote: post #18

Neat technology, but, even as a rather serious O'Caml fan, even going so far as to use it in production ;), I tend to avoid the FF consultancy because of things like this: > If you would like to keep up to date with respect to HLVM development, please subscribe to The OCaml Journal. And when I go to read the online documentation? > The design and implementation of this high-performance garbage collected virtual machi…

The HLVM implementation is for everyone to see at http://hlvm.forge.ocamlcore.org/ . There is a public mailing list at https://lists.forge.ocamlcore.org/pipermail/hlvm-list/ and I am sure Jon Harrop would be more than happy to discuss all technical details there.

Mono OTOH might be okayish for C#, but for instance F# so far has no open source implementation. Also Mono is lacking w.r.t. TCO and GC, so its not even close to a decent VM for functional languages.

Re: HLVM -- the High-Level Virtual Machine

#25

Post by amock »

megaman821 wrote: post #20
amock wrote: post #12

Earlier quoted context omitted.

Why do you need HLVM to do this? OCaml already runs on multiple platforms, so all that's needed is some library work. The same is true for Haskell, Standard ML, Lisp, and many other languages. If you want to write languages for multiple platforms HLVM sounds useful. If you want to write portable programs, why not work on improving the libraries available for an existing language?

I don't think that is the point. I am pretty sure the author was using the CLR as an example. You could write WPF applications using F#, IronPython, or IronRuby because the are all compile CLR code. If the most popular languages on Mac and Linux all compiled down to LLVM they would be a lot more inter-operable like the CLR languages. It would be much easier to leverage the Cocoa framework from Python, Lisp, or Java i…

That makes sense. MacRuby is using the Objective-C runtime as the common denominator but I'd love to see other languages do that same.

Re: HLVM -- the High-Level Virtual Machine

#26

Post by WilliamLP »

cabalamat wrote: post #22
ramchip wrote: post #9

Earlier quoted context omitted.

Making portable applications isn't a solved problem. There's Java. It's decent, especially with Clojure and other JVM languages, but I find the idea of a more powerful language (like OCaml) not without merits. Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.

> Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization. What in particular about the JVM prevents Clojure from being able to do tail-call optimization? My (admittedly naive) understanding of TCO is that it involves turning tail recusion into a loop, and Java can certainly handle loops OK.

I'm naive too, but apparently there are use cases for TCO for state machines where the tail calls are between various functions, not necessarily in a simple loop.

Re: HLVM -- the High-Level Virtual Machine

#27

Post by crux_ »

cabalamat wrote: post #22
ramchip wrote: post #9

Earlier quoted context omitted.

Making portable applications isn't a solved problem. There's Java. It's decent, especially with Clojure and other JVM languages, but I find the idea of a more powerful language (like OCaml) not without merits. Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.

> Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization. What in particular about the JVM prevents Clojure from being able to do tail-call optimization? My (admittedly naive) understanding of TCO is that it involves turning tail recusion into a loop, and Java can certainly handle loops OK.

> My (admittedly naive) understanding of TCO is that it involves turning tail recursion into a loop

This is close, but not the full story.

TCO turns tail recursion into a GOTO (well, a goto-with-arguments). In the case of a single function which tail-calls itself, this becomes a loop, but for multiple functions that are mutually recursive, that's not the case.

Note that the issues with the lack of TCO boil down to efficiency: there are ways of faking TCO atop a runtime that does not support it (meaning deeply tail-recursive code will run, rather than overflow the stack), but they come at with a runtime cost.

Re: HLVM -- the High-Level Virtual Machine

#28

Post by pohl »

jurjenh wrote: post #16
lolcraft wrote: post #6

Interesting exercise, but of little use: this is solving (well, trying to) a political problem with more technology. JVM is already on the table, let's use that.

A contrarian option might be to target java code for the LLVM... don't know what that would achieve, but it may lead to interesting applications.

There is a project called VMKit which allows one to build a JVM or a CLR using the LLVM framework.

http://vmkit.llvm.org/

Re: HLVM -- the High-Level Virtual Machine

#29

Post by crux_ »

45g wrote: post #24
crux_ wrote: post #18

Neat technology, but, even as a rather serious O'Caml fan, even going so far as to use it in production ;), I tend to avoid the FF consultancy because of things like this: > If you would like to keep up to date with respect to HLVM development, please subscribe to The OCaml Journal. And when I go to read the online documentation? > The design and implementation of this high-performance garbage collected virtual machi…

The HLVM implementation is for everyone to see at http://hlvm.forge.ocamlcore.org/ . There is a public mailing list at https://lists.forge.ocamlcore.org/pipermail/hlvm-list/ and I am sure Jon Harrop would be more than happy to discuss all technical details there. Mono OTOH might be okayish for C#, but for instance F# so far has no open source implementation. Also Mono is lacking w.r.t. TCO and GC, so its not even clo…

Yes, it's 'open' -- not arguing that, nor would I dispute that Mono is far from perfect. [1]

But, like so many FF projects: is this the cart, or the horse?

In other words, this feels more like a promotional project for the consulting firm and its pay products than it does a 'real' project. I freely admit this judgement has some external bias; Jon H. has a reputation.

[1] footnote: (Of course, neither is the linked project... 128 bits for each and every pointer on a 32-bit architecture? Does that mean 256 bits per pointer on 64-bit? Yikes!)

Re: HLVM -- the High-Level Virtual Machine

#30

Post by oconnor0 »

nimrody wrote: post #17

HLVM is targeted at high performance scientific applications. The current implementation already outperforms OCaml in several benchmarks (OCaml is more optimized for symbolic computations and sometimes 'boxes' floating point values).

But "Closures for functional programming." is still on the TBD list.
Post reply on HN