Every place I worked at has a git introduction where all new employees learn about how git works internally. Takes 1h, and all junior devs stops memories random commands and actually start to understand. I highly recommend to you to poking around in the .git directory.
The git support for new employees drops basically to zero.
i investigated this yesterday and there is one cmake extension. It gives basic support to cmake. Not as neat as vscode/jetbrains/qt/vs but it works. It is depends on CMakePresets.json and has no gui etc.
If it captures variables, it is not possible to manually declare the type. You can however hide it in an std::function. But then you probably get some overhead and some heap allocations in real life.
I tried to reproduce it on Ivybridge (Windows VS20122) and failed (mulss and muldd) [0]. single and double precision takes the same time. I also found a behavior where the first batch of iterations takes more time regardless of precision. It is possible that this tricked me last time.
I agree with you. It should take the same time when thinking more about it. I remember learning this in ~2016 and I did performance test on Skylake which confirmed (Windows VS2015). I think I remember that i only tested with addsd/addss. Definitely not x87. But as always, if the result can not be reproduced... I stand corrected until then.
Yes, as I wrote, it is only true for one float value.
SIMD/MIMD will benefit of working on smaller width. This is not only true because they do more work per clock but because memory is slow. Super slow compared to the cpu. Optimization is alot about cache misses optimization.
(But remember that the cache line is 64 bytes, so reading a single value smaller than that will take the same time. So it does not matter in theory when comparing one f32 against one f64)
First IANACC (I'm not a compiler programmer), but this is my understanding:
What do you mean by interface?
A dynamic library is handled very different from a static one. A dynamic library is loaded into the process virtual memory address space. There will be a tree trace there of loaded libraries. (I would guess this program walks this tree. But there may be better ways i do not know of that this program utilize)
In the world of gnu/linux a static library is more or less a collection of object files. The linker, to my best knowledge, will not treat the content of the static libraries different than from your own code. LTO can take place.
In the final elf the static library will be indistinguishable from your own code.
My experience of the symbole table in elf files is limited and I do not know if they could help to unwrap static library dependencies. (A debug symbol table would of course help).