Displaying 3 results from an estimated 3 matches for "1984k".
Did you mean:
1984
2009 Feb 01
0
[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
2009 Jan 30
5
[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
2009 Jun 01
3
Problem EXCEPTION_ACCESS_VIOLATION (0xc0000005)
...,0x44f50000] [id=38]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 18240K, used 11385K [0x02740000, 0x03b00000, 0x04ea0000)
eden space 16256K, 69% used [0x02740000, 0x03248bc8, 0x03720000)
from space 1984K, 4% used [0x03720000, 0x03735ad0, 0x03910000)
to space 1984K, 0% used [0x03910000, 0x03910000, 0x03b00000)
tenured generation total 241984K, used 23850K [0x04ea0000, 0x13af0000, 0x22740000)
the space 241984K, 9% used [0x04ea0000, 0x065eabc0, 0x065eac00, 0x13af0000)
compacting p...