You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since PCG is oriented towards speed, I thought I'd mention that as far as performance goes, not being able to inline the core functions like pcg32_random_r has a significant impact on speed. I'm getting around this by simply doing #include "pcg-basic.c" - yes, including the implementation file!
A usual solution is to declare the key functions static inline in the header file, then you don't have to mess around with "out of line" versions.
The more fully featured C library is able to be inlined.
The text was updated successfully, but these errors were encountered:
I don't think gold linker has anything to do with it (?), but yes LTO
solves it.
LTO is still a bit like PGO - some people know about it, few people use it.
If you are writing a high performance library you don't want to rely on
people using it.
In a way LTO is harder to turn on than PGO even, because the old
TU-at-a-time model hides certain types of bugs that are revealed when you
enable LTO, because the compiler can now see that what you've been doing is
UB after all, etc.
Since PCG is oriented towards speed, I thought I'd mention that as far as performance goes, not being able to inline the core functions like
pcg32_random_r
has a significant impact on speed. I'm getting around this by simply doing#include "pcg-basic.c"
- yes, including the implementation file!A usual solution is to declare the key functions
static inline
in the header file, then you don't have to mess around with "out of line" versions.The more fully featured C library is able to be inlined.
The text was updated successfully, but these errors were encountered: