So, should I make the benchmark ready for running via BTI?
Are there any guidelines and criteria it should meet?
Thanks,
Aleksey.
On Wed, Apr 16, 2008 at 8:09 PM, Sean Qiu <[EMAIL PROTECTED]>
wrote:
> What about adding a web UI for our BTI?
> I think it is natural since we have a similar one to publish our
results.
>
> Just like continuum[1], it is easier to manage.
> Maybe we can get some hint from it.
>
> Anyway, BTI is worthwhile devation.
>
> [1] http://continuum.apache.org/
>
>
>
> 2008/4/16, Stepan Mishura <[EMAIL PROTECTED]>:
> > On 4/16/08, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> > > 2008/4/16, Stepan Mishura <[EMAIL PROTECTED]>:
> > > > On 4/16/08, Alexey Varlamov <[EMAIL PROTECTED]>
wrote:
> > > > > 2008/4/16, Tony Wu <[EMAIL PROTECTED]>:
> > > > > > Is it possible to integrate into BTI? if not we can
consider the enhanced/tools/
> > > > >
> > > > > There is one already in drlvm trunk, see
working_vm/src/test/microbenchmark.
> > > > > There is no infrastructure around, it is mere store holder
for now.
> > > > > Feel free to add benches there, they are not intended to
be
> > > > > VM-specific.
> > > > >
> > > >
> > > > I would say opposite if they are DRLVM specific then it is
OK to put
> > > > them to the folder. Otherwise (i.e. they are not
VM-specific) we
> > > > should integrate them to BTI.
> > > >
> > > > Th point is that DRLVM workspace should contain only DRLVM
specific
> > > > tests. For example, IMO DRLVM workspace is not the right
place for
> > > > EHWA-API scenario.
> > >
> > > This is too radical position IMO. Absolute majority of tests
in DRLVM
> > > are functional and not impl-specific, should we move them all
to BTI?
> > >
> >
> > Yes, IMHO we should move them to BTI.
> >
> > The point is that any workspace (classlib/drlvm/jdktools) is not
a
> > repository for a set of different suites.
> >
> > > Sometimes convenience of using and extending is more important
for
> > > success. If we had appropriate infra for benchmarks I wouldn't
argue,
> > > but now I'm afraid most contributors would rather leave a
bench-case
> > > hanging in JIRA than dare to hack BTI. I'm happy to be proven
wrong,
> > > though.
> > >
> >
> > "convenience of using and extending" is questionable for me in
this case.
> > Well, yes I agree that from position of a DRLVM developer it is
more
> > convenient when EHWA-API scenario is located in DRLVM workspace
- no
> > additional efforts are required to run it. But what about
classlib
> > developer who wants to run EHWA-API on J9 - she/he needs to
checkout
> > DRLVM workspace. Is this convenient and extensible? (Hmm, may be
I was
> > wrong when I insisted on integration of LDAP scenario into BTI
then
> > into classlibrary ;-))
> >
> > Seriously, if we think that using BTI is complicated for a
developer
> > then we should do our best and make it simpler and more
convenient.
> > Otherwise we finish with zoo of different suites/scenarios in
several
> > places.
> >
> > Thanks,
> > Stepan.
> >
> > > Regards,
> > > Alexey
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > > > Re integration to BTI, this would require fair amount of
efforts and
> > > > > usage model is not clear to me.
> > > > >
> > > > > >
> > > > > > On 4/15/08, Aleksey Shipilev <[EMAIL PROTECTED]>
wrote:
> > > > > > > Hi Tony, all!
> > > > > > >
> > > > > > > Does it make sense to create special place in our
repository for
> > > > > > > storing the benchmarks like this one I've used in my
performance
> > > > > > > researches on Harmony? It would be great to have them
synchronized in
> > > > > > > repos rather than store in JIRA.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Aleksey.
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <
[EMAIL PROTECTED]> wrote:
> > > > > > > > Aleksey,
> > > > > > > > I think keep the benchmark somewhere such as JIRA
is also ok.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Best Regards
> Sean, Xiao Xia Qiu
>
>
>
> China Software Development Lab, IBM
>
