GitLab

Mbind is giving us trouble again, will need to spend time looking at it
carefully.

Modify the benchmarks to use the new functions.

Instead of asking the user to provide the offsets into a tiling, add a
function providing a tileid. This tileid corresponds to the in-memory
order of tiles, making the tilestart functions a lot simpler.

We still need to split the tileid for tilestart because scratchpads
create requests based on tileids.

Also add a unit test for tiling_2d, to make sure we're not doing
anything crazy.

Tiling 2d and its interfaces wasn't the right way of looking at 2d grids
of tiles. Rename the contig ones to provide the required features.

This patch provides aligned allocations for all areas. Simple tests
included.

Note that I haven't tested if it conflicts with arena-wide alignements.

We are going to need more of those flags, and keeping track of the
conversions is tricky. So let's use a copy of the macros.

mbind requires that the input ptr be aligned on a page.

NOTE: we could also figure out a way to ask jemalloc
for page-aligned allocations, but that would probably
be too much for each alloc.

Prevents issue with the new arena/alloc logic. This way, no allocation
can end up overlapping the pages of another one on a different binding.

The way jemalloc handles big allocations can often result in surprising
calls to mmap/mbind (splitting allocations, rounded up sizes). It also
makes the path between an aml_alloc and mbind quite difficult to see.
More worrying, if jemalloc reuses a previous allocation, the mbind will
not be called again, which might result in the wrong binding happening.

To fix those issues, we move the mbind logic to be around the
allocations returned from jemalloc. This will ensure that we always bind
properly. The only issue is that it might slow down allocations.

It can also cause issues if the same arena is used by multiple areas, as
allocations might be overlapping a page. We will move away from sharing
arenas for benchmarks from now on.

Duplicate changes to dgemm_nofetch.c from commits
6a0d1cbd and
9326c388.

We had a race condition where OpenMP threads were accidentally reusing
the same variables on stack, resulting in races and incorrect results.
The number of FP operations was probably correct, although the memory
accesses to the arrays may have been wrong.

The A, B, and C matrices are tiled (tiles in A are also transposed).
Add initialization code for A and B and conversion code for C that
respects the tiling, thus enabling a direct comparison of results with
mkl and vanilla.

Benchmarks were crashing due to bad parameters.

Use the new 2D tilings for dgemm_prefetch, also refactor the code to
match the rest of the benchmarks. The code should be a lot more cleaner
now.

Fix dgemm_noprefetch to match pattern from @suchyb in #19.
In order to do so we split our 2d tiling into column-major and
row-major ones. Note that those are refering to the order of the tiles,
not the internal data of a tile, as a tiling should be agnostic to it.

1. refactor overall main function to match intended benchmark interface.
2. Use the new tiling type to cleanup the noprefetch version. Careful
inspection unearthed some bad offset computations, which are fixed here.
3. double checked the way we were spawning threads, new code should be
straightforward.

I believe that code should be easier to read and to play with.
Converting the prefetch versions might not be as easy.

Add a tiling representing a 2d array of contiguous tiles. Also add a
ndims function to retrieve the dimensions in tiles of the tiling.

It also became quite obvious that the iterators are useless right now.
We should think about changing that.

Just to be able to test various matrix placements.

Match intended benchmarking interface, including computing
flops directly.

Add parallel option to the compile step to speed things up.

Implement 3 dgemm benchmarks versions:
- standard mkl code on total matrix
- prefetch scheme based on UTK/INRIA/ANL on-going collaboration
- same tiling but no prefetch version of the code

This is the version ready for merging, after several weeks of work on
independant branch. Further improvements to API/code will continue after
it reaches master.

Implement a 2D tiling with continuous tiles in memory, with tiles
organized in row-major order inside the virtual address range.

Also adds functions to query the size of a tile inside the tiling.

When a code using aml is also linking against jemalloc, errors can occur
because we use the default jemk prefix for the aml specific jemalloc
install. To fix these issues, we instead use a prefix aml-specific.

Discovered when using mkl on a knl box.

Extracted from my usual scripts for experiments

Move towards a common list of args and a common log/timing
infrastructure for benchmarks.

We are starting to work on benchmarks to evaluate the usefulness of this
library. Instead of integrating them into the testing infrastructure, it
makes more sense for them to have their own directory and a different
way of handling them.

This patch:
 - creates a benchmark directory for actual codes that we want to use as
   benchmarks of our library.
 - moves functional tests into it.
 - add proper OpenMP detection for these codes

Useful and currently missing.

Mempolicy seems to be inconsistant depending on the distro. Need a more
complete investigation.

The mbind test could end trying to MBIND to too many numanodes at the
same time. Use only one numa node instead.

Disable CI runs for refs that are work in progress.

Simple gitlab-ci config with a single step, running the full list of
configure, make, make install and make check.

No tags, no split build and test for now, as artifacts are a bit tricky
to get right.

This config should grow in the future to ensure that we run all the test
on all the platforms we want.

Fix small issues with type convertion across several tests,
as a change of architecture might trigger bad behavior in
variadic functions.

We were unlocking the dma before the request type get set to a
proper value, resulting in requests sometimes overlapping when
multiple threads were used in benchmarks.

This is a second type of use for the scratchpad: a single master
thread is responsible for launching all data movements, but the tiles
are worked on in parallel. We support this model by using a sequential
scratch on top of a parallel dma.