Reorganize sources

[Flamefire]

This does the discussed reorganization in preparation for cTracing.

File structure:

• src/. contains glue code to define the extension module
• src/scorepy contains namespaced implementation

Introduced optimization barries by using multiple cpp files can be removed by using LinkTimeOptimization and (optionally) visibility.

As it is related I also included the renaming if instrumenters to the "private" (by convention) name "_instrumenters". This signals that it is internally used only and allows developers to make breaking changes in that sub-package as long as externally visible behavior remains the same.

[Flamefire]

@AndreasGocht Travis shows up 3 times but there is only 1 real build (which passed). Guess a temporary issue on GH/travis

[AndreasGocht]

The Travis CI test does complete. So it looks like an issue with the Travis GitHub connection.

[AndreasGocht]

Introduced optimization barries by using multiple cpp files can be removed by using LinkTimeOptimization and (optionally) visibility.

Can you elaborate this in a bit more detail?

[Flamefire]

Can you elaborate this in a bit more detail?

In the call I mentioned that prior to this PR the C binding function static PyObject* parameter_int(... calls scorepy::parameter_int(name, value); which could be inlined into the former if the compiler chooses so saving 1 call and potentially allowing some more optimizations. Now that the scorepy:: function is in a separate TU (translation unit) the compiler can't see the definition and hence can't inline it which may introduce some overhead which wasn't there before. However this is at the C-level so that is dwarfed by the overhead of the instrumentation alone and simple calls are quite cheap in C.

There are 2 ways to improve:

• Enabling LTO allows the compiler to optimize the created library as-if it was a single TU. So inlining can happen at link time and all is the same as before
• Related is to compile with -fvisibility=hidden, which will reduce the binary size by removing most exported symbols. Remember that on Unix every single function, class, etc. is exported from a shared library so it could be used by another binary importing the shared lib. So all (mangled and hence long) names are contained making the library large. Using hidden visibility reverses this and nothing is exported by default (you have to export things explicitly). This reduces binary size and may enable better optimizations, especially LTO: If the compiler knows, this function is not used outside the library it is more likely to inline it into the only usage site. With default visibility even when inlining it there has to be an out-of-line definition for other libraries to call.

Hope this clears it up.
IMO this is a minor optimizations so we can also talk about and implement this later if a call is required.

[AndreasGocht]

Now I got it 😄 . Thanks.
I would propose, that we do a benchmark of the compiler settings, once the new instrumenter is there. So we could measure if the performance benefit is worth the additional complexity.

[Flamefire]

Added issue #91 to not forget that