similar to: [LLVMdev] Performance vs other VMs

This is not a quite fair comparison. Other virtual machines must be doing garbage collection, while LLVM, as it is using C code, it is taking advantage of memory allocation by hand. On Fri, Jan 30, 2009 at 9: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

----- Original Message ----- From: "Jon Harrop" <jon at ffconsultancy.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Saturday, January 31, 2009 6: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

I just remembered an anomalous result that I stumbled upon whilst tweaking the command-line options to llvm-gcc. Specifically, the -msse3 flag does a great job improving the performance of floating point intensive code on the SciMark2 benchmark but it also degrades the performance of the int-intensive Monte Carlo part of the test: $ llvm-gcc -Wall -lm -O3 *.c -o scimark2 $ ./scimark2 Using

On Saturday 31 January 2009 03:42:04 Eli Friedman wrote: > On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst > > tweaking the command-line options to llvm-gcc. Specifically, the -msse3 > > flag > > The -msse3 flag? Does the -msse2 flag have a similar effect? Yes: $

On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst tweaking the > command-line options to llvm-gcc. Specifically, the -msse3 flag The -msse3 flag? Does the -msse2 flag have a similar effect? -Eli

>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

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: > >

> How do you handle tail calls and value types? I haven't worried too much about optimisation yet, so it doesn't do anything special for tail calls (although neither does the java compiler). LLVM types are translated to their equivalent java primitive type (or currently it raises an assertion if there is no equivalent type). -- David Roberts http://da.vidr.cc/ On Sat, Nov 28, 2009

> So it will stack overflow on tail calls At the moment, yes. But then again, so does java. Also, it looks like they're working on support for tail calls in the Da Vinci Machine[1]. > and break with run-time errors When I said it raises an assertion, I meant at compile-time. > on structs? No, structs are supported. The only unsupported types at the moment (as far as I am aware) are

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

On Sunday 29 November 2009 02:06:04 you wrote: > > So it will stack overflow on tail calls > > At the moment, yes. But then again, so does java. Sure but a lot of people like me are using LLVM precisely because it offers these wonderful features. As long as your JVM backend does not handle these features correctly its utility is greatly diminished. > Also, it looks like

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

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

On Saturday 28 November 2009 06:20:39 David Roberts wrote: > > How do you handle tail calls and value types? > > I haven't worried too much about optimisation yet, so it doesn't do > anything special for tail calls (although neither does the java > compiler). LLVM types are translated to their equivalent java > primitive type (or currently it raises an assertion if

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.

I am just considering various different designs for the code emitted by a HLVM and one alluring approach is to make all local variables immutable and replace loops with (tail) recursive functions. This makes it much easier to reason about injected code such as GC checks. However, I am concerned about the performance of the generated code. Specifically, this is likely to result in small

On Jan 25, 2009, at 12:21 AM, Jon Harrop wrote: > My question is: will LLVM optimize this back into a function > containing a loop > that runs inside a single stack frame that contains the constants > "a" and "x" > or should my compiler perform this rewrite itself? The easiest way to answer this is to write the moral equivalent in C, and see if it happens

Following a discussion about numerical performance on comp.lang.functional recently I just tried running a simple C mandelbrot benchmark that uses C99's complex arithmetic using gcc and llvm-gcc on a 2.1GHz Opteron 2352 running Debian: gcc: 5.727s llvm-gcc: 1.393s There is still 20% room for improvement but LLVM is >4x faster than gcc here. Sweet. Here's the code: #include

FYI, Yesterday's Slashdot had an article about Linux compiler benchmarks from Coyote Gulch (Scott Ladd). In this update he compares GCC and ICC. You can read the article here: http://www.coyotegulch.com/reviews/linux_compilers/ Of particular note was his use of SciMark 2.0 which is a NIST developed benchmark for scientific computing. Its available in both java and C and computes a MFLOPS

On Friday 05 February 2010 23:35:15 Evan Cheng wrote: > Does anyone actually using it? Yes, many LLVM-based projects rely upon TCO to work correctly. > I'd prefer to just remove it to clean up the implementation if no one has > any objections. Are you saying that you want to remove LLVM's working TCO and replace it with something that is faster but broken? I think you may