Можно ли сохранять данные MPGO между сборками?

Я только что прочитал сообщите о MPGO (управляемая оптимизация профиля), и описанный процесс:

  1. Получите компьютер с Visual Studio 11 Ultimate Beta и установленным приложением.
  2. Запустите инструмент MPGO (от имени администратора) с необходимыми параметрами:
    MPGO -scenario MyLargeApp.exe -AssembyList *.* -OutDir C:\Optimized\ Оптимизированные сборки IL создаются в папке C:\Optimized.
  3. Запустите инструмент NGen (от имени администратора) с необходимыми параметрами для каждой DLL приложения: NGEN.exe myLargeApp.exe
  4. Запустите ваше приложение — теперь оно будет использовать оптимизированные нативные изображения.

Кажется, это означает, что вы должны выполнять направляющие сценарии для двоичных файлов, которые входят в ваш выпущенный продукт.

Для меня не имеет смысла, что в процессе сборки требуется ручное вмешательство. Есть ли способ выполнить направляющие сценарии один раз, а затем зафиксировать сгенерированные данные, чтобы они автоматически вставлялись в скомпилированные сборки в будущих сборках?


.net optimization .net-4.5 ngen
person Motti    schedule 30.04.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Несколько лет назад я работал в лаборатории сборки в Microsoft, которая занималась большим количеством управляемого кода. Подчеркну, это было много лет назад, до того, как управляемая MPGO стала государственной. Но тогда они использовали старые данные профиля (обычно за день до этого, но иногда и до недели) для «частичной оптимизации» набора внутренних двоичных файлов. Я не могу говорить о цифрах, но мы бы не стали этого делать, если бы в этом не было какой-то выгоды. Эти «частично оптимизированные» двоичные файлы будут использоваться только для автоматического дымового тестирования и только для внутреннего использования. Когда-либо будут выпущены только полностью оптимизированные двоичные файлы (данные профиля которых были собраны из одной сборки).

Я не эксперт, но, насколько я понимаю, данные руководства MPGO используют сигнатуры методов (например, используемые символами отладки) и смещения файлов, которые не являются стабильными между сборками. Тогда возникает вопрос: какой процент достаточно стабилен, чтобы иметь какую-то пользу?

Допустим, имя метода изменилось для метода, который часто используется. Тогда, конечно, «горячие» страницы в старом бинарнике (из-за этого метода) не будут найдены в новом бинарнике, а страница, которая часто используется, вероятно, будет помещена в «конец» оптимизированного бинарника. с кодом, который никогда не используется. С другой стороны медали: какой % методов переименовывается из одной ежедневной сборки? (Или даже чаще с CI?) Думаю, менее 1%.

Позвольте мне вернуться к внутренним сборкам. Конечно, сбор новых данных профиля производительности занял некоторое время, поэтому чувствительные ко времени внутренние функции (которые необходимо запускать сразу после сборки) будут выполняться с использованием частично оптимизированной версии сборки, потому что эта сборка завершится за несколько часов до полностью оптимизированной версии сборки. . Позвольте мне объяснить, почему это заняло так много времени. IIRC мы использовали «проходы» профиля, где сначала запускаются сценарии основной библиотеки, эти двоичные файлы оптимизируются, а оптимизированное ядро ​​​​используется в более поздних «сквозных» сценариях (например, веб-служба на стороне сервера или графический интерфейс на стороне клиента). сценарии). Таким образом, основные библиотеки будут профилированы и оптимизированы несколько раз. Как вы можете догадаться, все это требует времени, поэтому «полностью проанализированный/оптимизированный» билд занял ДОЛГОЕ время.

Я надеюсь, что это было полезно.

P.S. Этот вопрос напомнил мне о проблемах перебазирования 32-разрядной DLL.

person yzorg    schedule 07.06.2012