Interaction with tiered compilation Ahead-of-time generated code is not as highly optimized as code produced by the JIT. To address this issue, tiered compilation will replace commonly used ReadyToRun methods with JIT-generated methods.
А почему, что мешает? Runtime статистики не хватает или еще чего?
Здравствуйте, Sharov, Вы писали:
S>А почему, что мешает? Runtime статистики не хватает или еще чего?
Не думаю, что это основной недостаток, т.к. не уверен, что статистика вообще существует (если речь о profile-guided optimization), потому как tiered compilation — это не об этом вообще.
А вот, что, например, точно может иметь последствия: будучи AoT компилятором, нет никакой возможности трактовать static readonly поля, как константы, и тот типичный код, который на это полагается получит бранчинг (1), и увеличение размера кода таких методов (2).
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, Sharov, Вы писали:
S>>А почему, что мешает? Runtime статистики не хватает или еще чего?
MA> Не думаю, что это основной недостаток, т.к. не уверен, что статистика вообще существует (если речь о profile-guided optimization), потому как tiered compilation — это не об этом вообще.
With runtime hot-swapping of code .NET could start doing more detailed profiling and then use the runtime feedback to do even better optimization (profile guided optimization). Such techniques can allow code generators to out-perform even the best static optimizers that don’t have access to profile data.
Здравствуйте, Sharov, Вы писали:
S>По-моему, об этом, цитата отсюда: S>
S>With runtime hot-swapping of code .NET could start doing more detailed profiling and then use the runtime feedback to do even better optimization (profile guided optimization). Such techniques can allow code generators to out-perform even the best static optimizers that don’t have access to profile data.
Видишь ли, типичный нативный компилятор и так дает неплохой результат, и сверху этого ему помогают принимать правильные решения через PGO. (Тот же хром получает в среднем около 10% бонусов от использования этой техники.)
В дотнете с Tiered Compilation речь немного о другом: компилируем tier0 — с прицелом на скорость генерации кода, но не очень оптимально, и только потом случается tier1 компиляция на основании метрик.
Пока даже нет On-Stack Replacement включенного по дефолту (но уже можно включить ключиком), поэтому опять таки есть компромисс.
Но, пока нативный PGO собирает статистику по возможности по более-менее реальному (хоть и инструментированному) коду и может тебе ответить на вопрос, каков рейт бранчей и оптимизировать лэйаут — в tier0 ещё нет ничего похожего на реальный код, например, то что обычно инлайнится — он не инлайнит. Соответственно эта фаза не может в полной мере помочь сбору статистик да и само профилирование имеет цену. Соответственно ограниченность здесь есть.
Но в большем масштабе это может дать хороший эффект, т.к. есть куча run-once кода, внедрение в код всяких проверок которые потом могут быть отброшены (например инициализация статического класса традиционно впиливалась по месту использования и была заметна в циклах, — а tier1 может эту проверку уже не генерировать вовсе).
В общем, на мой взгляд — пока это всё борьба за время старта, а реальные массовые улучшения в .NET5 получили за счет улучшения самого компилятора/кодогенерации (т.е. и статического), и переписывания библиотечного кода на оптимальный или векторный.
Вообще, можно полистать структуры вокруг секции с информацией о профиле CORBBTPROF, что бы составить представление приблизительно о чём там вообще может идти речь.
Это круто, как для дотнета, но по сути, там не так что бы есть что-то особо интересное (если вообще о PGO). [Впрочем, без релиза .NET 6 о нём говорить пока рано]
Здравствуйте, Sharov, Вы писали:
S>А почему, что мешает? Runtime статистики не хватает или еще чего?
Первое, что хочется предположить, что это все больше треп на будущее. У МС много говорят о мифических потенциальных оптимизациях, которых на практике не делаются. По крайне мере так было в докорочном дотнете.
Теоретически у джит-компиляции есть много способов создать более производительный код.
1. Джит компилирует код для конкретного процессора и даже конкретной системы. Он может использовать любые инструкции. И даже перенести вычисления на видюху (но это пока только совсем в теории).
2. Джит работает в момент когда все сборки или уже загружены или может быть перджитен когда появятся новые сборки. Отсюда становятся доступны оптимизации вроде агрессивного инлайнинга виртуальных методов или переписывания объектов из кучи в стековые объекты. Эти оптимизации открывают дорогу другим, которые нельзя сделать без предыдущих.
3. Так как джит может оптимизировать только "горячие точки", и работать в бэкграунд-потоке — он может делать более тяжелые оптимизации для отдельных частей кода.
4 Оптимизированный код может разбухнуть. А это хреново влияет на скорость загрузки приложений. Этот ReadyToRun предназначен для ускорения старта приложения. Я не пробовал ReadyToRun, но NGen существенно сокращал скорость загрузки приложения в котором имеется большое количество типов и много мелких методов. Скорость загрузки росла даже не в разы, а в десятки раз. Но это специфично для приложения. А вот наш современный продукт не может использовать Ngen из-за уязвимостей которые несет загрузка неподписанных бинарей. ReadyToRun может оказаться хорошей альтернативой (надеюсь, что его бинари удастся подписать).
Когда же компилируется нативный код для всей сборки, то он не может использовать всего перечисленного, не может работать очень долго (хотя это можно было бы отрегулировать опциями компиляции) и не может производить тех оптимизаций, которые требуют знаний о наличии загруженных сборках (наследников типов и т.п.).
Но еще раз повторюсь — это больше теория. На практике многим задачам вообще по фигу оптимизации. Скажем веб-бэкэнду или ГУЮ некоего продукта обычно плевать на скорость выполнения отдельных методов, так как они перекладывают данные из/в базу данных и занимаются разным биндингом, который по факту ни что иное как динамика на рефлексии. А вот перекомпилированные бинари могут дать ему ускорение загрузки и, как следствие, ощущение ускорения работы при взаимодействии с пользователем.
Судя по написанному в МС хотя получить и ускорение загрузки, и джит-компиляции отдельных функций, и высокую скорость работы отдельных методов за счет реджита отельных, часто выполняемых методов, и не сильное раздувание памяти, так как перекомпилируются только отдельные методы.
Звучит красиво. Ну, а как оно будет на практике нужно смотреть на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Первое, что хочется предположить, что это все больше треп на будущее. У МС много говорят о мифических потенциальных оптимизациях, которых на практике не делаются. По крайне мере так было в докорочном дотнете.
