On Wed, 2005-11-02 at 11:31 +0100, Christian Thalinger wrote:
> On Tue, 2005-11-01 at 22:16 +0100, Mark Wielaard wrote:
> > That seems like an significant improvement. Could you test with a larger
> > dataset (or just run the test in a loop 10 times)? I still haven't tried
> > with gcj. If someone
On Tue, 2005-11-01 at 22:16 +0100, Mark Wielaard wrote:
> That seems like an significant improvement. Could you test with a larger
> dataset (or just run the test in a loop 10 times)? I still haven't tried
> with gcj. If someone could test, that would be super. I believe gcj has
> really slow monit
Hi Christian,
On Tue, 2005-11-01 at 21:03 +0100, Christian Thalinger wrote:
> On Tue, 2005-11-01 at 21:00 +0100, Christian Thalinger wrote:
> > On Sun, 2005-10-30 at 12:28 +0100, Mark Wielaard wrote:
> > > position. Opinions? Volunteers? Anyone want to test against other
> > > runtimes? Or another
On Tue, 2005-11-01 at 21:00 +0100, Christian Thalinger wrote:
> On Sun, 2005-10-30 at 12:28 +0100, Mark Wielaard wrote:
> > position. Opinions? Volunteers? Anyone want to test against other
> > runtimes? Or another test set?
>
> Hmm, just tested the patch with cacao. It finished in 1.48user with
On Sun, 2005-10-30 at 12:28 +0100, Mark Wielaard wrote:
> position. Opinions? Volunteers? Anyone want to test against other
> runtimes? Or another test set?
Hmm, just tested the patch with cacao. It finished in 1.48user with and
without the patch, so you should benchmark with an interpreter ;-)
Hi Anthony,
On Fri, 2005-10-28 at 17:05 -0700, Anthony Green wrote:
> On Fri, 2005-10-28 at 15:40 +0200, Mark Wielaard wrote:
> > Interesting. What was the total running time before/after this patch?
>
> I don't have the modified library anymore.
>
> > Could you post your test program?
>
> impo
On Fri, 2005-10-28 at 15:40 +0200, Mark Wielaard wrote:
> Interesting. What was the total running time before/after this patch?
I don't have the modified library anymore.
> Could you post your test program?
import java.io.*;
import java.util.*;
public class pread
{
public static void main(S
Hi Anthony,
On Thu, 2005-10-20 at 22:18 -0700, Anthony Green wrote:
> On Wed, 2005-10-19 at 14:53 -0700, Anthony Green wrote:
> > On Wed, 2005-10-19 at 12:49 -0700, David Daney wrote:
> > > You also might want to look at comment #1 of:
> > >
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Andrew,
I suspect that Vector usage is from the time when Vector was the only storage
class we had available. AFAIK ArrayList (which is IMHO Vector without locking)
and friends have been introduced with 1.2
Could you find out where Vector is used i
On Wed, 2005-10-19 at 12:24 -0700, Anthony Green wrote:
> Synchronization often shows up near the very top of gcj-compiled
> benchmarks. It turns out that, for benchmarks I've run, ~50% of the
> synchronization calls come from reading property files with
> StringBuffer. This should all go away if
> "Anthony" == Anthony Green <[EMAIL PROTECTED]> writes:
Anthony> I patched the FC rawhide GCC to use gnu.gcj.runtime.StringBuffer in
Anthony> java.util.Properties, and wrote a little program to read the locale
Anthony> property files from GNU Classpath. Reading the property files was
Anthon
On Wed, 2005-10-19 at 14:53 -0700, Anthony Green wrote:
> On Wed, 2005-10-19 at 12:49 -0700, David Daney wrote:
> > You also might want to look at comment #1 of:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
>
> Thanks for the pointer. I think a non-copying unsynchronized
> StringBuf
On Wed, 2005-10-19 at 12:49 -0700, David Daney wrote:
> You also might want to look at comment #1 of:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
Thanks for the pointer. I think a non-copying unsynchronized
StringBuffer clearly makes the most sense. I'll demonstrate the
improvement wi
Anthony Green wrote:
Synchronization often shows up near the very top of gcj-compiled
benchmarks. It turns out that, for benchmarks I've run, ~50% of the
synchronization calls come from reading property files with
StringBuffer. This should all go away if we use StringBuilder instead.
Have yo
Synchronization often shows up near the very top of gcj-compiled
benchmarks. It turns out that, for benchmarks I've run, ~50% of the
synchronization calls come from reading property files with
StringBuffer. This should all go away if we use StringBuilder instead.
Ok?
2005-10-19 Anthony Green
15 matches
Mail list logo
