Below...
On Wed, 2004-04-14 at 10:30, Anthony Green wrote:
On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote:
AOT (or pre-JITing) assemblies is not as useful as you'd think. It has
two primary effects:
- Reduce memory requirements, as memory doesn't need to be allocated
for the
No, he is not.
YOu can run
mono -O=shared my.exe
or, if you would like to aot:
mono -O=shared --aot my.exe
However, as miguel stated earlier, the need for shared code is very
rare. What shared means here is that the same code can be used by
multiple appdomains (look that up if you are not
On Wed, 2004-04-14 at 19:47, Jonathan Pryor wrote:
Below...
On Wed, 2004-04-14 at 10:30, Anthony Green wrote:
On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote:
AOT (or pre-JITing) assemblies is not as useful as you'd think. It has
two primary effects:
- Reduce memory
Hello,
Because you didn't mention the key advantage that you get from
AOT-compiled shared libraries: saving memory from sharing library code
between processes. You're only two points were about saving time and
memory from not having to JIT compile code.
Ah, that is correct, and I had at
Sigh.
Building
a development version of Jikes RVM is pretty stressful on the hosting VM.
It's found bugs in more than one product VM in the past. This
looks like one of the nastier forms; the host VM managed to write the RVM.image
file without any obvious error, but the image file is
On Tue, 2004-04-13 at 15:08, Jonathan Pryor wrote:
AOT (or pre-JITing) assemblies is not as useful as you'd think. It has
two primary effects:
- Reduce memory requirements, as memory doesn't need to be allocated
for the JITed code
- Decrease startup time, as (again) the JITing
Hello,
snip/
Interestingly, my installation of mono (from debian sid) doesn't even
come with its own libraries AOT'd. I'd have thought that you'd get the
best performance by AOT'ing *all* the libraries, including (and
especially) the low-level platform ones such as System.dll and
Stuart Ballard wrote:
Mark Wielaard wrote:
and overhead. Hope I have time next week to update it with
at least rvm
development results and maybe IKVM ahead of time results
(Jeroen, any
hints on how to do that in this case?)
I don't know whether you have a zip/jar or individual
Mark Wielaard wrote:
You then still need the original exe for execution.
The man page says about --aot:
This option is used to precompile the CIL code in the specified
assembly to native code. The generated code is stored in a file
with the extension .so. This file will
Hi,
On Tue, 2004-04-13 at 20:55, Stuart Ballard wrote:
Did you try --aot'ing classpath.dll, IK.VM.NET.dll etc?
I'd imagine that this particular microbenchmark spends a large
proportion of its time inside classpath itself, suggesting that merely
JITing the mauve part wouldn't help much.
Hi,
On Mon, 2004-04-12 at 16:43, David P Grove wrote:
Development Jikes RVM can take a while to build, but does buy some
performance. Probably not worth it for classpath development or mauve
tests, but if you want to run some apps it can pay off. I have
prototype and development 2.3.2
Below...
On Tue, 2004-04-13 at 14:55, Stuart Ballard wrote:
snip/
Interestingly, my installation of mono (from debian sid) doesn't even
come with its own libraries AOT'd. I'd have thought that you'd get the
best performance by AOT'ing *all* the libraries, including (and
especially) the
Hi,
On Thu, 2004-04-08 at 18:44, Stephen Crawley wrote:
The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath
from CVS.
Thanks a lot for that!
The interesting thing is that the test run 200 times faster with JDK 1.4.2
than with Kissme. Yes TWO HUNDRED TIMES!
[...]
Development Jikes RVM can take a while
to build, but does buy some performance. Probably not worth it for
classpath development or mauve tests, but if you want to run some apps
it can pay off. I have prototype and development 2.3.2 images sitting
around on my machine, so just for fun.
Mark Wielaard wrote:
There are quite some differences between the free runtime environments.
Here are some results from JC, although this is on a much faster machine
(Intel(R) Pentium(R) 4 CPU 2.40GHz):
$ time echo gnu.testlet.java.lang.Character.unicode | jc
gnu.testlet.SimpleTestHarness
Hi,
On Mon, 2004-04-12 at 15:53, Mark Wielaard wrote:
There are quite some differences between the free runtime environments.
(Total) running time goes from 1.2 seconds (native gcj) to 1.5 minutes
(kissme). This is on a AMD Athlon XP 1600+ (1.4 Ghz).
Note the interesting differences between
Mark Wielaard wrote:
and overhead. Hope I have time next week to update it with at least rvm
development results and maybe IKVM ahead of time results (Jeroen, any
hints on how to do that in this case?)
I don't know whether you have a zip/jar or individual classfiles but
assuming it's a single jar
Hi Guilhelm,
Thanks for the info. Your numbers tend to confirm my suspicion that the
factor of 200 is a Kissme-specific problem.
In the meantime, I think I have come across a problem in Kissme's
implementation of the CONSTANT_STRING instruction that does some way
towards explaining this.
--
Folks,
I've just checked in a new version of the Mauve testcase for Unicode
character handling. This fixes previous problems that resulted in
huge numbers of test failures with the current version of Classpath.
[It turns out that they were partly because the testcase used an old
Unicode table,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Crawley wrote:
| Folks,
|
| I've just checked in a new version of the Mauve testcase for Unicode
| character handling. This fixes previous problems that resulted in
| huge numbers of test failures with the current version of Classpath.
| [It
20 matches
Mail list logo
