harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [performance] a few early benchmarks
Date Thu, 23 Nov 2006 11:11:12 GMT
2006/11/23, Mikhail Loenko <mloenko@gmail.com>:
> 23 Nov 2006 16:34:22 +0600, Egor Pasko <egor.pasko@gmail.com>:
> > On the 0x22A day of Apache Harmony Alexey Petrenko wrote:
> > > 2006/11/23, Vladimir Strigun <vstrigun@gmail.com>:
> > > > On 23 Nov 2006 14:37:09 +0600, Egor Pasko <egor.pasko@gmail.com>
wrote:
> > > > > On the 0x22A day of Apache Harmony Vladimir Strigun wrote:
> > > > > > The numbers that I published was received on P4 under Windows
+
> > > > > > server.emconf +Harmony-1980. Unfortunately I haven't run Dacapo
under
> > > > > > x86_64, but I hope we could receive almost the same range (10-20
%
> > > > > > slower that Sun) with the mentioned configuration.
> > > > >
> > > > > And Sun was running with "-server" too I guess? :)
> > > >
> > > > Yes, of course.
> > > >
> > > > > Maybe, it is time to track performance comparisons of *different
> > > > > platforms* in one place? That should help to avoid major differences
in
> > > > > our visions for harmony performance.
> > > >
> > > > Yes, good idea. Should we define the configuration for all VM's as well?
> > > > For instance, for Sun we could use parameters from spec site. What do
> > > > you think about it?
> > > +1 for options from spec site.
> >
> > I am in love with it too. We could present results similar to how
> > spec.org does. Just a list of runs.
> > For each:
> > * revision number
> > * hardware/os summary (number of cores)
> > * link to full details
> +1
>
> > * more?
>
> score? :)
Scores are most visible things but we can not easily publish them for
all specs...
For example: http://www.spec.org/jbb2005/docs/FAQ.html#Qpublish
== cut ===
Q15
How can I publish SPECjbb2005 results?

A15
You need to get a SPECjbb2005 license in order to publish results.
For more information about submitting results, please contact SPEC.
== cut ===
Another link on SPECjbb2005:
http://www.spec.org/jbb2005/docs/RunRules.html#_Toc102806116
This question need more investigation.

Anyway I think that we should define suite list first.

SY, Alexey


> >
> > that would be great if we had volunteers on this, to avoid performance
> > confusions :)
> >
> > > > > * Melody
> > > > > * marmonytest.org
> > > > > * Robin's site
> > > > > * wiki (just for the start, maybe)
> > > > >
> > > > > > Thanks,
> > > > > > Vladimir.
> > > > > >
> > > > > > On 11/23/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > > > > > > I reviewed - looks like Robin is seeing DRLVM get an aggregate
> > > > > > > performance of about 35% of whatever he's measuring against.
> > > > > > >
> > > > > > > geir
> > > > > > >
> > > > > > >
> > > > > > > Geir Magnusson Jr. wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Stefano Mazzocchi wrote:
> > > > > > > >> Geir Magnusson Jr. wrote:
> > > > > > > >>>
> > > > > > > >>> Stefano Mazzocchi wrote:
> > > > > > > >>>> Sergey Kuksenko wrote:
> > > > > > > >>>>
> > > > > > > >>>>> Lets do the simplest thing fist. :)
> > > > > > > >>>>> We can do it. We only need to specify
a set of workloads.
> > > > > > > >>>> I've tried running dacapo with 10 warming
stages and we are constantly
> > > > > > > >>>> around 25% speed against the leading JVM
(which is always sun5 or
> > > > > > > >>>> sun6),
> > > > > > > >>>> bea5 is around 80% and ibm5 is around
70%, I'll have more detailed
> > > > > > > >>>> results shortly.
> > > > > > > >>> I don't understand this at all.  It wasn't
but a few weeks ago when
> > > > > > > >>> someone was reporting decapo numbers that
ranged from 90% of Sun5 to
> > > > > > > >>> 110% of Sun5.
> > > > > > > >>
> > > > > > > >> on x86_64?
> > > > > > > >
> > > > > > > > That's true.  It was x86.
> > > > > > > >
> > > > > > > > But the numbers that Robin is reporting aren't great
either, are they?
> > > > > > > >
> > > > > > > > geir
> > > > > > > >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Egor Pasko
> > > > >
> > > > >
> > > >
> > >
> >
> > --
> > Egor Pasko
> >
> >
>

Mime
View raw message