[MAGEEC] [mageec-magicians] Re: Structure of the Results Database
James.Pallister at bristol.ac.uk
Wed Aug 28 19:08:51 BST 2013
> A test (and test id) refers to a single combination of a platform,
> compiler, benchmark, and flag set.
> A run (and run id) refers to a single run of a test. A test can have
> multiple runs.
In the ERD, do the flags_tests and runs tables need test_id?
> The raw_results table is the bottleneck. We record 200,000+ individual
> results for a single run, so this table will get really quickly.
I'm guessing this is the power trace directly from the measurement
board? If so, the fields should be run_id, timestamp and power.
We may not want to store the entire trace in the database - with
millions of measurements, the database might get unmanagably large -
might be better if the raw_results was just the time, energy, average
power, peak power, etc for that specific run.
> We could split this out into a different results table, but it's a
> one-to-one relationship
The join between tests and runs should be changed from one-to-many in
the diagram to one-to-one.
Looks good from the energy measurement side :)
On 28/08/13 18:24, Simon Hollis wrote:
> Hi Ashley,
> Thanks very much for starting this discussion. This is a really good
> starting point.
> What I would like is that if everybody who has an interest in the
> structure of this database can provide their feedback on the structure
> that Ashley has proposed and see if it will work for their anticipated
> As I see it there are at least three interests we need to support:
> Energy Measurement; the MAGEEC framework; ML.
> Perhaps all sides could outline the suitability of the proposed
> structure for their needs?
> P.S. for Magicians: If you received this message, but not Ashley's
> original one, it is because you are not yet signed up for the external
> mageec at mageec.org mailing list. Please do so!
> On 28/08/13 17:21, Ashley Whetter wrote:
>> Hey everyone,
>> At the last meeting we looked at the ER diagram
>> (http://mageec.org/wiki/Database) for the database that would store
>> the results that would be recorded by the test framework and used by
>> the plugin.
>> I've taken some of the comments made at the meeting and made a more
>> detailed ER diagram to discuss.
>> A test (and test id) refers to a single combination of a platform,
>> compiler, benchmark, and flag set.
>> A run (and run id) refers to a single run of a test. A test can have
>> multiple runs.
>> Currently the flag table is only really storing a flag name (eg
>> "-fgcse", "-fno-gcse", etc). I've kept this as a separate table,
>> though, because eventually we'll want to start storing values for
>> flags that aren't just on or off. We could add this value field now,
>> keep the table as is for now, or get rid of flag_id all together and
>> just use the flag name in flags_tests instead.
>> I've put summary data in the runs table. We could split this out into
>> a different results table, but it's a one-to-one relationship it
>> would add an unnecessary overhead of joining the runs and results
>> table when we want to search it. This isn't such a problem if we
>> search for results by run_id though.
>> The raw_results table is the bottleneck. We record 200,000+
>> individual results for a single run, so this table will get really
>> mageec mailing list
>> mageec at mageec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mageec