4 ms·

I wonder why they deemed templates to be "insufficient or not efficient enough for a high-performance, multithreaded kernel".

nly 8y ago
Probably code size. Any two template instantiations, even if they produce identical machine code or in-memory representation, will generally be output twice due to language requirements like needing distinct memory addresses and linkage for things like functions, static data members, static locals, RTTI, vtables etc. Eliminating code bloat with templates requires careful judgment about where to put type erasure and how to factor your code
- kjgkjhfkjf 8y ago
  Hand-coding multiple versions of a function or class to accommodate various types would be just as bad in terms of code size, no? Plus it'd be tedious and error-prone to do this.
  - Negitivefrags 8y ago
    In practice most of the time you would just write a generic version using one of the other mechanisms. Virtual functions, void* and casting, type ids, or whatever. Just like everything else, it's a time/space tradeoff because it generates less optimal code in exchange for a smaller binary size.
    - cbsmith 8y ago
      There's actually a pretty well established design pattern about wrapping one of those methods with the template class, thereby allowing type safety checks and such whilst still minimizing bloat.
- kllrnohj 8y ago
  C++11 added extern templates which can easily solve the bloat problem. If a template consistently has the same type like, say, std::vector<int>, you can just extern it and tada they all share the same generated implementation ( https://isocpp.org/wiki/faq/cpp11-language-templates#extern-templates https://isocpp.org/wiki/faq/cpp11-language-templates#extern-... ) So even if the linker fails to de-dupe, you're still able to manually fix it pretty easily without giving up on templates entirely. But libkern predates C++11, so decisions made by that team at that time are largely obsolete and should be heavily re-evaluated rather than blindly followed.
  - olliej 8y ago
    A lot of the xnu c++ dates back almost two decades (maybe more?), and abi compatibility kind of screws in terms of changing decisions like this. You can’t really just say “update to a newer version of the language” when you have both API and ABI compatibility constraints. For source you can deprecate APIs, etc so future versions would have an early warning the source changes would be necessary. But that doesn’t help shipping kexts, for that you need ABI stability, which really puts the hammer on changing/updating the features that you use. Many of the C++ features cause exciting binary compatibility problems, and make it super easy to accidentally change the ABI :-/
    - kllrnohj 8y ago
      My point was just that anybody using C++ now shouldn't treat language-feature advice from 20+ years ago as anything particularly relevant. It's outdated and obsolete and should be treated as such. Sure if you're working on an obsolete codebase in bare-bones maintenance mode then you're kinda stuck, but most of us aren't. That aside yes, you totally can just update to a newer version of the language. If you are trying to maintain C++ ABI stability then your life is harder, yes, but it's no harder than it already is when you just upgrade compilers or deal with people building with other compilers (and most everyone ships C ABIs anyway to avoid this entire category of problems - extern "C" still works great in C++17). But you are still completely free to use newer features in the implementation itself which doesn't impact API or ABI stability in the slightest.
tcbawo 8y ago
It would probably expose too much of the implementation. Also, instantianted methods would live within the downstream libraries, making shared library linking fragile and un-upgradeable. Also, you could create your own specializations potentially circumventing safety/security features.
- deleted 8y ago
  [deleted]
olliej 8y ago
I suspect (never written anything substantial) that at least part of it relates to the age of a lot of xnu. Basically think about the state of c++ and c++ compilers two decades ago. I wouldn’t be surprised if that factored into it. As others have said codesize can also be an issue - it’s super easy to make templates produce insane amounts of code, especially in older compilers.
- mrpippy 8y ago
  Exactly. OS X 10.0 shipped with GCC 2.95, it wasn’t uncommon at all to avoid templates and exceptions back then.

nly 8y ago

Probably code size. Any two template instantiations, even if they produce identical machine code or in-memory representation, will generally be output twice due to language requirements like needing distinct memory addresses and linkage for things like functions, static data members, static locals, RTTI, vtables etc. Eliminating code bloat with templates requires careful judgment about where to put type erasure and how to factor your code

kjgkjhfkjf 8y ago
Hand-coding multiple versions of a function or class to accommodate various types would be just as bad in terms of code size, no? Plus it'd be tedious and error-prone to do this.
- Negitivefrags 8y ago
  In practice most of the time you would just write a generic version using one of the other mechanisms. Virtual functions, void* and casting, type ids, or whatever. Just like everything else, it's a time/space tradeoff because it generates less optimal code in exchange for a smaller binary size.
  - cbsmith 8y ago
    There's actually a pretty well established design pattern about wrapping one of those methods with the template class, thereby allowing type safety checks and such whilst still minimizing bloat.
kllrnohj 8y ago
C++11 added extern templates which can easily solve the bloat problem. If a template consistently has the same type like, say, std::vector<int>, you can just extern it and tada they all share the same generated implementation ( https://isocpp.org/wiki/faq/cpp11-language-templates#extern-templates https://isocpp.org/wiki/faq/cpp11-language-templates#extern-... ) So even if the linker fails to de-dupe, you're still able to manually fix it pretty easily without giving up on templates entirely. But libkern predates C++11, so decisions made by that team at that time are largely obsolete and should be heavily re-evaluated rather than blindly followed.
- olliej 8y ago
  A lot of the xnu c++ dates back almost two decades (maybe more?), and abi compatibility kind of screws in terms of changing decisions like this. You can’t really just say “update to a newer version of the language” when you have both API and ABI compatibility constraints. For source you can deprecate APIs, etc so future versions would have an early warning the source changes would be necessary. But that doesn’t help shipping kexts, for that you need ABI stability, which really puts the hammer on changing/updating the features that you use. Many of the C++ features cause exciting binary compatibility problems, and make it super easy to accidentally change the ABI :-/
  - kllrnohj 8y ago
    My point was just that anybody using C++ now shouldn't treat language-feature advice from 20+ years ago as anything particularly relevant. It's outdated and obsolete and should be treated as such. Sure if you're working on an obsolete codebase in bare-bones maintenance mode then you're kinda stuck, but most of us aren't. That aside yes, you totally can just update to a newer version of the language. If you are trying to maintain C++ ABI stability then your life is harder, yes, but it's no harder than it already is when you just upgrade compilers or deal with people building with other compilers (and most everyone ships C ABIs anyway to avoid this entire category of problems - extern "C" still works great in C++17). But you are still completely free to use newer features in the implementation itself which doesn't impact API or ABI stability in the slightest.

tcbawo 8y ago

It would probably expose too much of the implementation. Also, instantianted methods would live within the downstream libraries, making shared library linking fragile and un-upgradeable. Also, you could create your own specializations potentially circumventing safety/security features.

deleted 8y ago
[deleted]

olliej 8y ago

I suspect (never written anything substantial) that at least part of it relates to the age of a lot of xnu. Basically think about the state of c++ and c++ compilers two decades ago. I wouldn’t be surprised if that factored into it. As others have said codesize can also be an issue - it’s super easy to make templates produce insane amounts of code, especially in older compilers.

mrpippy 8y ago
Exactly. OS X 10.0 shipped with GCC 2.95, it wasn’t uncommon at all to avoid templates and exceptions back then.