Update size of (continuous) benchmarks / Add benchmarks for new features

[mrfh92]

Due Diligence

• General:
  • title of the PR is suitable to appear in the Release Notes
• Implementation:
  • unit tests: all split configurations tested
  • unit tests: multiple dtypes tested
  • benchmarks: created for new functionality
  • benchmarks: performance improved or maintained
  • documentation updated where needed

Description

Issue/s resolved: #

Changes proposed:

Type of change

Memory requirements

Performance

Does this change modify the behaviour of other functions? If so, which?

yes / no

[mrfh92]

@JuanPedroGHM do you think we should...

• ...come up with some standardized sizes and shapes (as I started in this draft)...
• ...or choose a size/shape individually for every function?

[mrfh92]

The first one would be quite easy, because you can choose a number of GB per process, resulting in a number of elements per process which then results in a total number of elements for the data set that then can result in a concrete shape (different for square, tall-skinny, very tall-skinny etc. data, but all with the same global and process-local amount of data)

[mrfh92]

looks like that it will become difficult to have a uniform size of the benchmarks...

[JuanPedroGHM]

It's a good idea to align all our benchmarks by using standardized sizes, easier to design and change everything in the future if we get again more powerful hardware.

For the time being, I'm going to raise the time of the slurm job so that you can experiment better.

[JuanPedroGHM]

Raised the time limit to 2 hours, but once you have more data fine tune it better.