Я считаю, что концепция кеша кода (например, ccache ) должна быть расширена до более мелкозернистой памятки как промежуточного кода (IC), так и целевого кода ( TC) в компиляторах, таких как GCC или LLVM + Clang.
Это может быть использовано для целого ряда новаторских умов, приносящих пользу как программисту производительности , так и производительности во время компиляции, выполнения и оперативной памяти.
Более конкретно, этот репозиторий (или база данных) должен автоматически кэшировать IC и TC функций. Затем их можно найти и повторно использовать в различных наборах сборок (скомпилированных только один раз, чтобы связать множество) в разных наборах программ и библиотек, а не только через границы объектов во время компоновки (LTO).
Это будет особенно полезно для C ++ STL контейнер-алгоритм-реализации. Например, сколько раз алгоритмы, такие как std::sort, примененные к std::vector<T>, не создавались, не оптимизировались и не компилировались в разных программах с использованием одного и того же типа T, обычно int, float и double?
В реализации IC-модули должны индексироваться ключами, построенными из хэш-цепочки (должно быть достаточно SHA-1) конфигурации компилятора и IC-кода дерева (включая код поддерева) -хэши функций, которые он вызывает) и хранятся, например, в std::unordered_map, обеспечивающем дешевых поисков . Чтобы еще больше способствовать повторному использованию кода, IC-репозиторий может быть переведен онлайн как сетевой сервис .
Конечно, памятки должны кэшироваться только тогда, когда это необходимо для оптимально хорошей производительности. Это должно иметь очень небольшие накладные расходы. Поскольку большинство поисков хеш-ключей должно быть пропущено, ключи должны быть помещены в память, но необязательно фрагменты кода.
Этот проект уже доказал полезность этой идеи применительно к языку Python. Я считаю, что Haskell (GHC) может быть идеальным языком для экспериментов с этими идеями из-за своей чистоты функций по умолчанию и гибкого контроля побочных эффектов функций.