4 ms·
I mean to say, the compiler might see std::vector<a> and std::vector<b> as strictly separate types, but at their base/binary might be code that is identical (ef
by coroutines 11y ago
I mean to say, the compiler might see std::vector<a> and std::vector<b> as strictly separate types, but at their base/binary might be code that is identical (effectively std::vector<int>). I am imagining that the compiler would generate code for both, and not see the opportunity to deduplicate identical object code. Again, I suspect I am naive here.
- scott_s 11y agoI think you're saying that a and b are actually typedefs to the same type. Yes, in that case I believe C++ compilers are smart enough to share code.
- catnaroek 11y agoIf `a` and `b` are typedefs to the same type, then `foo<a>` and `foo<b>` are literally the same type, so sharing code isn't a matter of compilers being “smart” - it's a matter of respecting C++'s semantics. I think GP is talking about something different. Let's say you have two completely unrelated types `a` and `b`, but, for whatever reason, `foo<a>` and `foo<b>` happen to compile to exactly the same machine code. (For a concrete example, say `a` and `b` have the same size and alignment requirements, and say `foo` is `std::vector::reserve`.) Then either the compiler or the linker can “merge” the duplicated code for `foo<a>` and `foo<b>`.
- coroutines 11y agoThat is not what I'm saying. Example: You can have 2 struct types that each only contain an int with the same member name. They would [likely] have the same binary representation. You could then create 2 vector types specialized for each struct type. The code for both vectors would handle the data in the same way - but the compiler would view the vector types as _STRICTLY_ separate types. I do not think this code would be uniquely shared - the compiler would generate code for both vector types.
- scott_s 11y agoNow I get what you're saying. I think it's possible for a C++ compiler to be smart about this. But why is this such a big deal to you? Have you seen it become an issue in projects you've worked on?
- coroutines 11y agoFull disclosure: I have not had a problem with this. It's just a theory I have that this is low-hanging fruit to reduce C++ binary size. You're less likely to define the same structure and methods of a type in exactly the same way as someone else in C because we don't have the STL (ofc). So it's probably a worse issue in C having a hundred different implementations of a linked list or some array type across your system in each program. I just think there's an opportunity to aggressively dedupe object code for "representation-identical" types in C++.
- scott_s 11y agoWe've had optimizing C++ compilers for a long time - decades. I think it's safe to assume that the low-hanging fruit was picked a long time ago.
- coroutines 11y agoForgive me here if I'm being argumentative, but I think we're both speculating. Someone further up the chain mentioned this sort of deduplication might be done by the linker, but the code for the duplicated type would still exist in the binary before linking.. An old but probably negligible complaint about C++ is that it creates larger binaries than if one were writing C. I think this is something overlooked because C++ has a focus on type strictness - perhaps the linker has a better way of seeing through abstractions.. I've identified where I think a problem lies.. now I just have to find proof it :3 Unrelated: I wonder if identical libraries that exist in separate filesystem trees (like in Docker) are deduped in memory, or if it's done by inode.