search for: flyingfrogblog

...;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: > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html For numerical tasks and Array tasks but your graphs show for data manipulation for Lists LLVM is slower. I thnk you need further benchmarks, is this at all posible for you to do :) Interesting, Aaron

Hi all, I would like to implement GC for a language supporting multiple threads. There will be no shared state between threads as communication will be based on message passing. I do not care much about performance. The priority for me is to get things working. I have read LLVM guide on writing GC: http://llvm.org/docs/GarbageCollection.html. Shadow stack approach looks very promising. The

...ir 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: > > > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta- > >04.html > > For numerical tasks and Array tasks but your graphs show for data > manipulation for Lists LLVM is slower. I thnk you need further benchmarks, > is this at all posible for you to do :) The only benchmarks where H...

The release of a new code generator in Mono 2.2 prompted me to benchmark the performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz 64-bit Opteron and I have published the results here: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html The LLVM results were generated using llvm-gcc 4.2.1 on the C version of SciMark2 with the following command-line options: llvm-gcc -Wall -lm -O2 -funroll-loops *.c -o scimark2 Mono was up to 12x slower than LLVM before and is now only 2.2x slower on average...

The (new) HLVM project is continuing to improve and I have graphed and analysed some performance-related data. Beating OCaml on numerical performance using LLVM turned out to be quite easy on x86: http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html This was achieved using a single optimization pass in HLVM (unrolling) and none of LLVM's own IR optimization passes. So the performance is essentially due to LLVM's excellent x86 code gen and sane IR generation by HLVM itself....

...39;s an unfair comparison. 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: http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html And, of course, OCaml is fast as ML compilers go... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

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 give LLVM the same information the x86 codegen has, it's an unfair comparison.

...:56 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > The release of a new code generator in Mono 2.2 prompted me to benchmark the > performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz > 64-bit Opteron and I have published the results here: > > http://flyingfrogblog.blogspot.com/2009/01/mono-22.html > > The LLVM results were generated using llvm-gcc 4.2.1 on the C version of > SciMark2 with the following command-line options: > > llvm-gcc -Wall -lm -O2 -funroll-loops *.c -o scimark2 > > Mono was up to 12x slower than LLVM before and is no...

Hi all, I've been working recently on a precise garbage collector which runs alongside native code JITted by LLVM. Today marks the first time the GC has passed its entire test suite as well as extensive soak tests in non-trivial programs. It's been an interesting and educational process, to say the least, and I've run into quite a few things that might be useful to know for others

...:56 AM Subject: [LLVMdev] Performance vs other VMs > > The release of a new code generator in Mono 2.2 prompted me to benchmark > the > performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz > 64-bit Opteron and I have published the results here: > > http://flyingfrogblog.blogspot.com/2009/01/mono-22.html > > The LLVM results were generated using llvm-gcc 4.2.1 on the C version of > SciMark2 with the following command-line options: > > llvm-gcc -Wall -lm -O2 -funroll-loops *.c -o scimark2 > > Mono was up to 12x slower than LLVM before and is no...

...relevant here is the use of value types to avoid heap allocation in order to alleviate the garbage collector. For example, HLVM is about 3x faster than Java on the following ray tracing benchmark because HLVM does no allocation or collection whilst tracing whereas Java does a huge amount: http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html I believe that benchmark shows that even the most heavily optimized GC can be thrashed by a program that simply avoids GC. Value types make this possible and the lack of value types on the JVM is, therefore, a major issue. Now, I ha...

On Sat, Sep 20, 2008 at 9:57 AM, Jon Harrop <jonathandeanharrop at googlemail.com> wrote: > I think your new OCaml tutorials and the original C++ ones are absolutely > brilliant! Thanks Jon. I'm sorry I missed this message. Now that you've had some more experience with llvm, would you be interested in adding to the doc some performance and GC stuff? I haven't personally

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a

On Monday 31 March 2008 09:56:45 Erick Tryzelaar wrote: > The full series of the ocaml tutorial is done! You can find it here: > > http://llvm.org/docs/tutorial/ > > Please let me know if you have any comments, bugs, suggestions, and > etc. I'll send a mail to the ocaml mailing list tomorrow to drum up > some interest from the other ocaml users. I think your new OCaml

...value types to avoid heap allocation in order to alleviate the > garbage collector. For example, HLVM is about 3x faster than Java on the > following ray tracing benchmark because HLVM does no allocation or > collection whilst tracing whereas Java does a huge amount: > > > http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html > > I believe that benchmark shows that even the most heavily optimized GC can > be thrashed by a program that simply avoids GC. Value types make this > possible and the lack of value types on the JVM is, therefore, a majo...

So I've been using LLVM for about 4 years now, and I've posted a lot on this list about specific issues. What I would like to do is step back for a moment and give my "big picture" assessment of LLVM overall, particularly with respect to developing a "managed" language like Java / C# or my own language, Tart. Obviously, I feel that LLVM is the best choice out there,