similar to: [LLVMdev] HLVM performance and shadow stack overheads

On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote: > Jon Harrop wrote: > >Even if this puts LLVM at an unfair disadvantage, I think you will find > >that > >LLVM will thrash MLton's current x86 backend anyway. > > > >I did some benchmarking on HLVM and found that it was often several times > >faster than OCaml when the GC is not the bottleneck: > >

Comments inline. On Sun, Dec 4, 2011 at 1:38 PM, Jon Harrop < jonathandeanharrop at googlemail.com> wrote: > Hi Talin, > > I wrote HLVM: > > http://www.ffconsultancy.com/ocaml/hlvm/ > > The whole project took a few man months. HLVM provides an ML-like type > system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, > POSIX threads, mark-sweep

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: >> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: >> > Is this really a problem for MLton? I think you only get less precise >> > alias analysis, and that's it. >> >> Correct. However, I want a fair comparison between LLVM performance >> and the native x86

Hi Talin, I wrote HLVM: http://www.ffconsultancy.com/ocaml/hlvm/ The whole project took a few man months. HLVM provides an ML-like type system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, POSIX threads, mark-sweep GC and both JIT and standalone compilation. I wrote several (accurate) garbage collectors for it including a stop-the-world mark-sweep collector and they

I have committed the changes to HLVM that bring it up to date with respect to the new LLVM 2.6 release: http://hlvm.forge.ocamlcore.org/ This required handling of llcontexts and the injection of a call to the new Llvm_executionengine.initialize_native_target function (that is undocumented) *before* the JIT EE is created, otherwise LLVM resorts to the LLVM interpreter which breaks at

On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: > On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: > > Is this really a problem for MLton?  I think you only get less precise > > alias analysis, and that's it. > > Correct. However, I want a fair comparison between LLVM performance > and the native x86 codegen. If I don't

I have been working on a high-level virtual machine built upon LLVM since Christmas 2008 and just released the first working version: http://forge.ocamlcore.org/projects/hlvm/ This alpha release of HLVM provides: . Unit, bool, int and float primitive types. . Tuples (as first-class structs). . Homogeneous array type. . Boxed value type. . Function pointers. . Generic printing. . Full tail

All, Chris Lattner and I had a recent discussion about merging the HLVM (http://hlvm.org/) and LLVM (http://llvm.org/) projects. We agreed in principle and the merging of the two projects will now commence. This merger makes sense for both projects. LLVM needs to expand into the realm of front end tool kits. HLVM provides LLVM with some initial front-end capabilities. Since HLVM uses LLVM and

HLVM is a garbage collected virtual machine built upon LLVM: http://forge.ocamlcore.org/projects/hlvm/ The development of HLVM was described in a series of three OCaml Journal articles that turned out to be among our most popular. Consequently, we have decided to run another series of related articles that build upon this foundation in order to develop complete compilers. The first article

Hi, I am senior student at Tashkent University of Information Technologies and I am highly interested in programming language design. I want to develop Python front-end for HLVM as a part of LLVM participation in Google Summer of Code project. I am in long love with Python programming language for its simplicity and effectiveness. Last year I noticed ShedSkin Python to C++ translator among SoC

The HLVM project is a high-level VM optimized for scientific computing: http://www.ffconsultancy.com/ocaml/hlvm/ I implemented the first-working version of a garbage collector capable of collecting from threads that run in parallel in November. Initial performance was awful due to the overhead of accessing thread-local data via POSIX pthreads. I just completed optimizing HLVM so

What happened to the HLVM project? I understand it was intended to be a high-level VM specifically for dynamic languages and this post indicates that it was integrated into the LLVM project last year: http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html But I cannot find any code in LLVM that looks like it would have come from HLVM. -- Dr Jon Harrop, Flying Frog Consultancy

On Sun, Jan 4, 2009 at 2:36 PM, Jon Harrop <jon at ffconsultancy.com> wrote: (...) > But I cannot find any code in LLVM that looks like it would have come from > HLVM. Don't know about the status of the project, but the code seems to be here: http://llvm.org/viewvc/llvm-project/ (in directory "hlvm") Regards, Kevin André

The ocamldoc-generated documentation for HLVM is now available here: http://www.ffconsultancy.com/ocaml/hlvm/docs/ -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

Gabe, I'm quite new to hacking on LLVM, but I'll give you an idea I had reading some of the recent dev list posts. I think investigating concurrency with regards to LLVM would be very useful (what with multi-cores and all). This could be concurrency in regards to GC, or it could be simply looking at how LLVM can best interface with standard concurrency paradigms (OpenMP, MPI)

Hello, I would also like to apply for Google's Summer of Code, but I am having difficulty finding a concrete project idea to tackle. (Though certainly interesting, a new front-end or a compiler optimization pass seem like to large as projects for a single summer -- and certainly something I couldn't accomplish given my lack of familiarity with the code-base.) I have read the

To illustrate the value of value types to the OCaml community I recently did a couple of benchmarks. The first was similar to a hash table and stores key-value pairs unboxed in an array: http://groups.google.com/group/fa.caml/msg/8430ebdb687b9268 The second is the hailstone benchmark that the Haskell guys found gave huge performance improvements when using LLVM from GHC:

>From a cursory glance, it looks like something is messing with the stack canarys. Probably a stack buffer overflow. On Tue, Mar 10, 2009 at 11:41 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Someone is trying to work on HLVM with me but they're hitting a problem that > we have not been able to resolve. Specifically, GCC seems to be performing > some kind of

Forgive my top post but I hate Windows. J I am surprised you (Talin) say that "we know conservative collectors work" because my experience has very much been of them not working. Indeed, if you have 400Mb of allocated heap blocks on a 32-bit machine is there not a 10% chance of *each* random 32-bit int "pointing" into your heap, i.e. a false positive? I just did a simple

Someone is trying to work on HLVM with me but they're hitting a problem that we have not been able to resolve. Specifically, GCC seems to be performing some kind of sanity check for "stack smashing" and is calling abort because it is unhappy with something that the code is doing. However, I am not sure what and cannot reproduce the problem. The stack trace they have given me is: