RE: rundata_once UNIQUE clause

[James Cownie]

Joachim,

Can you give a slightly more detailed example of how to use the
"store_set" property?

I grepped the tests (which is normally a good way to find an example),
but couldn't find anything with store_set in it.

I think it's just what I need for the SPEC input (from the .raw spec
file), where I have something like this

  <!-- *** -->
  <!-- *** parameters and results which change during the run -->
  <!-- *** -->
  <named_location>
    <name>Benchmark</name>
    <match>.benchmark: </match>
  </named_location>

  <named_location store_set="yes">
    <name>Time</name>
    <match>.reported_time: </match>
  </named_location>

which is supposed to handle input of this general form...

spec.omp2001.results.316_applu_m.base.000.benchmark: 316.applu_m
spec.omp2001.results.316_applu_m.base.000.reported_time: 39425.654243
spec.omp2001.results.310_wupwise_m.base.000.benchmark: 310.wupwise_m
spec.omp2001.results.310_wupwise_m.base.000.reported_time: 27.990909090
(uninteresting lines elided)

Thanks

-- Jim

James Cownie <james.h.cownie@...>
SSG/DPD/PAT
Tel: [phone]

> -----Original Message-----
> From: Joachim Worringen [mailto:joachim@...]
> Sent: 27 July 2006 14:20
> To: users@...
> Subject: Re: [perfbase-users] rundata_once UNIQUE clause
>
> Ethan Mallove wrote:
> > Joachim Worringen wrote On 07/27/06 03:12,:
> >> Ethan Mallove wrote:
> >>
> >>> Could we also use the <set_seperation> element? I think we would

opt

> for this
> >>> over multiple files since we input to perfbase over HTTP.
> >>
> >> This will create a new run, which you don't want.
> >>
> >
> > I don't suppose it would be easy to implement something like:
> >
> > <!ELEMENT set_separation      (match|regexp)>
> > <!ATTLIST set_separation runs (single|multiple) "multiple">
>
> To achieve what exactly?
>
> A 'set_separation' (confusion! should better be called

'run_separation')
> is used to create multiple runs from a single input file. I guess this
> is not what you want? Instead, you want to reduce the number of runs
to
> be created for your given experiment output data?
>
> What you probably want is a way to create multiple data sets within
one
> run, each covering i.e. a different test and its result within the
same
> environment. To achieve this, define the required parameters and
> results, and use the "store_set" attribute of a <named_location> (or a
> <tabular_location>, which does this implicitely) to have perfbase
store

> the current dataset, and start gathering data for the next one.
>
>   Joachim
>
> --
> Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
> phone ++49/(0)228/324 08 17 - http://www.dolphinics.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joachim Worringen-4]

Cownie, James H wrote:
> Joachim,
>
> Can you give a slightly more detailed example of how to use the
> "store_set" property?
>
> I grepped the tests (which is normally a good way to find an example),
> but couldn't find anything with store_set in it.

Yes, that seems to be missing and should be added. It's not too
complicated, actually: a "data set" is one set of content for all
parameters and result values that have occurence=multiple (actually,
they are stored in one row of the database table "rundata").

The problem is to decide when a set is considered ready to be stored.
Requiring a set to be completely filled before being stored it is too
unflexible; partly filled sets need to be supported. One default trigger
is when a row of a <tabular_location> has been read (assuming it
contains values with occurence=multiple). But if you gather data i.e.
via <named_locations>, this does not work. Therefore, apply
'store_set="yes"' to the <named_location> that should trigger the
storage of the data set when it is filled with content.

> I think it's just what I need for the SPEC input (from the .raw spec
> file), where I have something like this
>
>   <!-- *** -->
>   <!-- *** parameters and results which change during the run -->
>   <!-- *** -->
>   <named_location>
>     <name>Benchmark</name>
>     <match>.benchmark: </match>
>   </named_location>
>
>   <named_location store_set="yes">
>     <name>Time</name>
>     <match>.reported_time: </match>
>   </named_location>
>
> which is supposed to handle input of this general form...
>
> spec.omp2001.results.316_applu_m.base.000.benchmark: 316.applu_m
> spec.omp2001.results.316_applu_m.base.000.reported_time: 39425.654243
> spec.omp2001.results.310_wupwise_m.base.000.benchmark: 310.wupwise_m
> spec.omp2001.results.310_wupwise_m.base.000.reported_time: 27.990909090
> (uninteresting lines elided)

What you did looks o.k. and matches my description above, assuming the
definition of these result values is 'occurence=multiple'. What happens
when you run this? Using the -t option for the input command gives you a
dry run.

  Joachim

--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...