[drlvm][gc]Allocation rate test

[Rana Dasgupta <rd...@gmail.com>]

Hi,
  I ran a simple test that allocates and discards a large number of objects
repeatedly on multiple threads. These should all be gen zero objects( none
survive ) that are repeatedly collected. So the test is of effective
allocation rate( I set heap size for all the gc's to 64M and 256 M ). I
think the test emulates a web server repeatedly creating and discarding page
level objects with each page invocation. This is NOT a perf comparison. gcv5
is just getting created, and comparisons are meaningless. But we can use
tests like this to tune. I am attaching the raw test output file.

 I submitted the test and build mods to JIRA, issue 1993. I am not sure that
we have decided where such focussed tuning tests that take too long to be
acceptance tests and don't really pass or fail should live. For right now, I
created a tests directory under gc_gen.

Thanks,
Rana

Re: [drlvm][gc]Allocation rate test

[Rana Dasgupta <rd...@gmail.com>]

Mikhail,
  Wonderful :-) Yes, we are still missing some hoisting opportunities, I saw
that in VTune( the old scores I ran are also with JET since the jitrino WB
was no yet in svn and I was lazy ). We shoule be able to match RI on
allocation rate, we use Appel's algorithm for the allocation of young
objects, so our algo is great. We can tune nursery size to some extent I
think.

But, better codegen is the key :-)

Rana


On 10/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> Rana,
> With a helper inlined we have significantly better results in your
> synthetic
> test. I think we can outperform SUN here if we add some very primitive
> loop
> optimizations into the JIT for TLS. I mean moving hythread_self out of the
> loop as it's already done for BBP.
>
> ps.
> Well, the list of TODO tasks for JIT is growing with a jet speed..
>
> On 10/29/06, Mikhail Fursov < mike.fursov@gmail.com> wrote:
> >
> > It's already done. I'll put it to JIRA on Monday.
> >
> > On 10/29/06, Ivan Volosyuk < ivan.volosyuk@gmail.com> wrote:
> > >
> > > As I can see we are far behind stock java implementation. This can
> > > change after fast path for object allocation gets implemented.
> > > Looking at the data received from stack java, I see that it is only
> > > limited by memory bandwidth so it will not scale when changing number
> > > of CPUs.
> > > --
> > > Ivan
> > >
> >
> >
> >
> > --
> > Mikhail Fursov
>
>
>
>
> --
> Mikhail Fursov
>
>

Re: [drlvm][gc]Allocation rate test

[Mikhail Fursov <mi...@gmail.com>]

Rana,
With a helper inlined we have significantly better results in your synthetic
test. I think we can outperform SUN here if we add some very primitive loop
optimizations into the JIT for TLS. I mean moving hythread_self out of the
loop as it's already done for BBP.

ps.
Well, the list of TODO tasks for JIT is growing with a jet speed..

On 10/29/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> It's already done. I'll put it to JIRA on Monday.
>
> On 10/29/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> >
> > As I can see we are far behind stock java implementation. This can
> > change after fast path for object allocation gets implemented.
> > Looking at the data received from stack java, I see that it is only
> > limited by memory bandwidth so it will not scale when changing number
> > of CPUs.
> > --
> > Ivan
> >
>
>
>
> --
> Mikhail Fursov




-- 
Mikhail Fursov

Re: [drlvm][gc]Allocation rate test

[Mikhail Fursov <mi...@gmail.com>]

It's already done. I'll put it to JIRA on Monday.

On 10/29/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> As I can see we are far behind stock java implementation. This can
> change after fast path for object allocation gets implemented.
> Looking at the data received from stack java, I see that it is only
> limited by memory bandwidth so it will not scale when changing number
> of CPUs.
> --
> Ivan
>



-- 
Mikhail Fursov

Re: [drlvm][gc]Allocation rate test

[Ivan Volosyuk <iv...@gmail.com>]

As I can see we are far behind stock java implementation. This can
change after fast path for object allocation gets implemented.
Looking at the data received from stack java, I see that it is only
limited by memory bandwidth so it will not scale when changing number
of CPUs.
--
Ivan

On 10/27/06, Rana Dasgupta <rd...@gmail.com> wrote:
> Hi,
>   I ran a simple test that allocates and discards a large number of objects
> repeatedly on multiple threads. These should all be gen zero objects( none
> survive ) that are repeatedly collected. So the test is of effective
> allocation rate( I set heap size for all the gc's to 64M and 256 M ). I
> think the test emulates a web server repeatedly creating and discarding page
> level objects with each page invocation. This is NOT a perf comparison. gcv5
> is just getting created, and comparisons are meaningless. But we can use
> tests like this to tune. I am attaching the raw test output file.
>
>  I submitted the test and build mods to JIRA, issue 1993. I am not sure that
> we have decided where such focussed tuning tests that take too long to be
> acceptance tests and don't really pass or fail should live. For right now, I
> created a tests directory under gc_gen.
>
> Thanks,
> Rana

Re: [drlvm][gc]Allocation rate test

[Xiao-Feng Li <xi...@gmail.com>]

Rana, this would be very useful for us to understand the GC behavior.
Thanks for this.

There is a synthesis benchmark GCold that can be also used for this
study. We were using it for a while.

Thanks,
xiaofeng

On 10/28/06, Rana Dasgupta <rd...@gmail.com> wrote:
> Hi,
>   I ran a simple test that allocates and discards a large number of objects
> repeatedly on multiple threads. These should all be gen zero objects( none
> survive ) that are repeatedly collected. So the test is of effective
> allocation rate( I set heap size for all the gc's to 64M and 256 M ). I
> think the test emulates a web server repeatedly creating and discarding page
> level objects with each page invocation. This is NOT a perf comparison. gcv5
> is just getting created, and comparisons are meaningless. But we can use
> tests like this to tune. I am attaching the raw test output file.
>
>  I submitted the test and build mods to JIRA, issue 1993. I am not sure that
> we have decided where such focussed tuning tests that take too long to be
> acceptance tests and don't really pass or fail should live. For right now, I
> created a tests directory under gc_gen.
>
> Thanks,
> Rana
>
>
>
>