I suspect a memory leak is due to that library not being updated.

I /think/ this helps with a memory leak, you can garbage collect the
results of an experiment as soon as you have consumed it, instead of
keeping it in memory. I'm not certain that's very important, though,
cause we don't store that many elements...

We don't want the stream to be parallel by mistake, that would destroy
the measurements.

There are a lot of strings which are actually the same string, except
the JVM stores the same data in two different objects. I used intern()
to try to make sure it's the same objects that is used if we've already
seen that string before.

I'm doing this, hoping that it prevents problems memory leaks in the
when writing the feature vectors to a file.

The sklearn original version doesn't take fresh benchmarks, while this
function does. It makes sure to use benchmarks in the test set which
are not present at all in the training set.

We still get roughly 70% accuracy with some small test data, that's encouraging!

We check the time spent to run benchmarks doesn't increase with the
number of iterations.

We track my version instead, with fixes (memory leaks)

We forgot to free the eventSets we were creating, now when the EventSet
object is garbage collected, we also destroy the underlying PAPI
EventSet.

Brainy uses ANNs, so we should too. Note: Random Forest yield better
results.

We validate in the functions that use this data already.

We also expect the iteration number for the sample.

If you consider all the duplicates, of course it doesn't work.

If we used a "Tracer" collection, the name would end up in the printed
output. We implement a function that removes that, so that it looks like
we used one of the normal collections.

We don't need to clean the eventSets if we used the same set at the
previous Spec

Not strictly necessary, since we don't use the generated EventSet in
Experiment. But might be useful later.

This is better because you don't need to allocate ALL the benchmarks
before benchmarking them!

Otherwise, you also have the non-normalized features included, and you'd
have to filter them out when doing the training, which I don't really
want to do.

We want to run with a heap big enough, otherwise we just do garbage collection...

Fixed error reporting

We only print it if there WERE dropped features

We use the checked features in the right places

Prints a more helpful error message, saying what features have been
dropped.

Doesn't work on windows

Instead of changing how features are interpreted depending of whether
they work or not, each feature can check itself if it is supported.

We then have a function which builds a new FeatureSet from an existing
one, filtering out the features that aren't supported.

I also added a method that only returns the features that were mentioned
in the FeatureSet in the map of the results.

We normalize the features by using the existing FeatureRatio, it's just
printed differently.

We don't need to supply a list, the FeatureSet IS a List

Makes the code much cleaner.

HTTP -> SSH

We can actually handle more than 2 counters! So we make sure we do

We just de-activate the counters that are not avaiable.

Some features are about hardware, some are about software. So you need
separate classes to print data with the right types

We'll look into /usr/local/ first.

That PAPI_PATH thing again.