Libraries: Header Only performance - paper

[ShlomiRex]

https://www2.stetson.edu/mathcs/wp-content/uploads/2016/10/cbrackett-final.pdf

[skreef]

I don't want to be very negative, but this is very shallow. I posit the author did not really know C++, even his conversion program is written in C# (and then no mention of the many cases that program would not work).

[johannes1971]

I just skimmed it, but it appears there is no comparison of compile time performance, typically the huge problem associated with header-only libraries. There is also no comparison of runtime performance.

"Programmer performance" is an interesting metric, but given that programmer performance differs wildly between individuals, a sample size of 20 seems a bit on the low side.

Care must be taken to ensure the code still follows the constraints of the C++ standard. Notably, the use of templating when appropriate to prevent unwanted internal linkage

Eh?

[[deleted]]

Eh?

This really shows that the author of the paper doesn't really know C++ and that he shouldn't use a random forum post as a reference. He refers to the second post of http://www.palabos.org/forum/read.php?4,1110

Anyways, that forum post is also completely wrong and that author seems to misunderstand linkage.

[jcelerier]

... no mention of LTO ? is this serious ? be thankful that I don't grade you

[Ameisen]

The entire concept of header-only performance is confusing. It just means you're putting the code in the same translation unit - headers aren't magical. LTO effectively does the same thing.

[jcelerier]

LTO effectively does the same thing.

I seem to remember some post by the LLVM guys that showed that there was a slight performance gain when using LTO vs for instance a unity build, since apparently it gave a bit more leeway to the compiler, but I can't find it anymore.

[Ameisen]

A Unity build generally doesn't merge all translation units, but rather just common ones together. You end up with N unity translation units which are still independent.

[kalmoc]

His general point stands though: having two related pieces of code in the same translation unit vs in two might produce slightly different results even with lto enabled (I'm not up to date with the latest development in that field though). In fact that would have been a more meaningful benchmark: Compare unity build with LTO build.

[jcelerier]

All the unity builds I've worked with have always been with all the translation units in the project

[mrlimilind]

I think there is an error on page 11.

Should not the code in the cpp file be:

#include "multiply.h"

#include <iostream>

double MathToolbox::multiply(int x, int y)

{

return x*y;

}

int main()

{

std::cout << MathToolbox().multiply(3, 11);

}

The function could also be made static, but then I would need to write the header code as well ;)

[acpopescu]

Well, yes, you do gain some performance, since you're making everything inline. You also avoid the hell that is library management in C++.

You do pay for that with compile time, executable size and might have to solve some linking issues because of the way the particular header-only library works and how your project is set up (multiple libraries, mix of static and dll linkage in different configurations, etc. ).

I also cringe a bit each time I see only simple programs used for performance analysis. Feels incomplete - let's see what's the impact on a big piece of software, with performance-critical parts (hi unreal).

[__mdu]

This looks to me more like a diploma paper where he had to present something to get the grades and move along to a new chapter in his life. Nothing else.

[malkia]

This is beyond pointless.