GitLab

We add some fields to BCBenchmarkPackage and a test to make sure we
don't run a benchmark more than 1 time per iteration.

That way, we try the test with several different seeds.

Previously, we didn't add the operationType to the key at all. Now the
map is a full function, but it just reports 0 cycles spent if there
weren't any in the benchmark.

The new papiRunner class (PapiTracerRunner) can get all the counters we
are interested in in one pass. So we use that class instead of the
regular PapiRunner.

We removed the need of a StopWatchRunner by making sure we only run the
benchmark once, even for getting the number of cycles per operation
type.

We check that the generation of runSpecs does avoid many runs for one
benchmark, and contains the right data.

The papiRunner class now gathers all the counters in one single run.
For that, we need to gather a limited number of counters: PAPI_TOT_CYC +
PAPI_TOT_INS + max 2 counters.

Because we don't do any aggregation either, I needed to change the
functions so they return a list of values for each iteration.

The test fails depending of the Java version. Works with Java 11, but
not java 8. I disabled it because I haven't found how to make IntelliJ
use Java 8, it keeps using java 11.

The bytecode was not correct because I compiled with the wrong Java
version once again..

Fixed conflicts with SyntheticBenchmarkFeaturePrinter and PapiRunner

Fixed smrt.jar and smrt-run.jar libraries so they work with
PapiTracerRunner

We used to run the benchmark many times are aggregate the values of
counters (median) before. Now when we print the features, we don't do
that anymore. We print the raw data.

Doing this required to add an "iteration" number for each specific run.

Recompiled it with Java 8 because we need to use java 8.

The string is not nullable.

I have to use Java 8 sometimes, but Java 8 doesn't have List.of and
Map.of which I was using in my tests. Replaced it by my own functions.

Feels more logical, but that wasn't really needed.

We have a map of cycles per operation type, and we use in a function
that will run specifications, aggregate the number of cycles per each
method of that type, and return a list of triplets (run#, opType,
cycles).

We move it because we want to use it in a context where we don't use
Timed collection.

We extracted one for running one iteration of a benchmark and one for
running many iterations.

The first thing we were doing with the stream was converting to string anyway.

map -> map + zip

Not needed, since we re-implemented runSpec directly.

Works similarly to how runSpec runs for a regular PapiRunner.

Updated smrt.jar because there are some methods we needed to reset the
tracer and set it's counters dynamically.

We run the benchmarks, get some counters, and aggregate them.

What's not finished is that we don't get the median over many runs,

nor do we gather counters yet.

It would fail if there are no samples. Now we filter to rule out the
values for which there are zero samples.

This PapiTracerRunner shares similarities with PapiRunner, so we make
an interface that contains stuff that's common to the two classes.

We'll add some classes that work as drop-in replacements for a Papi Runner.

This was a bit of a test to see if it feels nice, and it does!

That way, we're a bit more certain that the output does make sense.

I corrected the assertions to match what was given. That's not
necessarily how you should do, but the data looked reasonable to me.

We updated smrt.jar so that we can change the variable JPAPI and
JPAPI_COUNTERS dynamically (after class initialization).

We also initialize PAPI if it's not initialized yet, before running
the tests.

The tests still fail because the conditions are incorrect, but it runs!

Currently fails, because what's printed is more than an empty string.

We're using the tracing collections in this library to trace the
number of cycles per operation when running benchmarks.

The purpose is similar to timer collections in core/ but the
difference is that these collections are the ones we actually use when
making replacements in actual programs.

We track them as methods we would track when measuring times.

We decrease the number of seeds to try for some benchmarks because it
takes a long time (and triggered weird errors).

We update the test values for SyntheticBenchmarkFeaturePrinter, so it
prints the number of cycles and not the number of nanoseconds spent.

It wasn't set before, which caused the tests to fail with and
UnsatisfiedLinkError.

We used to use StopWatch runner to get the time spent in some methods,
but we now measure the number of cycles instead. This is because it's
easier to me to get the number of cycles when I run an actual Java
Program.