FSharp.Core не оптимизирован?

Недавно я проверил производительность приложения F # и, копаясь в CIL, обнаружил, что FSharp.Core (для .NET v4.0) содержит несколько инструкций nop, множество неиспользуемых переменных и переменных, которые только записываются/читаются один раз с помощью последовательностей инструкций stloc/ldloc.
Я исследовал возможные причины и заметил, что даже в режиме выпуска сборки F# включают директиву --debug:pdbonly, и нет никакого способа отключить ее и переключиться на --debug- из пользовательского интерфейса настроек проекта.
Мне интересно, был ли какой-то конкретный выбор для настроек компиляции FSharp.Core, и если да, то какой. В противном случае законно ли ожидать полностью оптимизированную версию среды выполнения?


f# cil
person em70    schedule 24.08.2010    source источник
comment
Связанный вопрос stackoverflow.com/questions /1612543/   -  person Brian Rasmussen    schedule 24.08.2010
comment
--debug:pdbonly является нормальным для кода выпуска, он включает только ограниченную информацию об отладке и позволяет декодировать стеки. Вся Windows (включая .NET) устроена так: именно так MS может предоставлять символы на своих серверах символов.   -  person Richard    schedule 24.08.2010
comment
@ Ричард: спасибо. Я подозревал, что причины связаны с отладкой, однако мне остается только гадать, будут ли преимущества в производительности с более оптимизированной версией... цикл процессора...   -  person em70    schedule 24.08.2010
comment
@ emaster70: только отладочная информация PDB не влияет на производительность, я не комментирую суть вашего вопроса.   -  person Richard    schedule 24.08.2010
comment
Обнаружили ли вы при профилировании конкретные проблемы с основной библиотекой F#? Я ожидаю, что компилятор JIT будет игнорировать любые nops, поэтому я не ожидаю, что это вызовет какие-либо реальные проблемы с производительностью.   -  person kvb    schedule 24.08.2010
comment
На самом деле я наткнулся на nops в FSharp.Core, когда решил посмотреть, насколько широко они присутствуют в базовой библиотеке; мое профилирование выявило только чрезмерное использование функций из модуля Seq и некоторую упаковку/распаковку, связанную с этим (речь идет о моем коде, а не о ядре). Когда я обратился к CIL-коду, чтобы исследовать упаковку/распаковку, я начал находить ошибки.   -  person em70    schedule 25.08.2010

Ответы (2)


arrow_upward
5
arrow_downward

Похоже, что комментарии к вопросу уже ответили примерно на 90%; повторить их:

  • почти каждый бинарный файл релиза во вселенной скомпилирован с --debug:pdbonly
  • даже если IL-код неоптимален, это может не иметь никакого реального влияния из-за JIT-оптимизации.

Конечно, существуют всевозможные способы, которыми компилятор F# потенциально может генерировать лучший код (вероятно, это верно для каждого компилятора); если вы профилируете свое приложение и заметите что-то плохое (например, большое несоответствие по сравнению с сопоставимым кодом из C#), вы можете сообщить об этом команде F#, отправив письмо fsbugs. Но сначала измерьте.

person Community    schedule 24.08.2010

arrow_upward
1
arrow_downward

В противном случае законно ли ожидать полностью оптимизированную версию среды выполнения?

Предлагаемые вами изменения не могут разумно рассматриваться как оптимизация. Оба безвредны и будут скомпилированы виртуальной машиной. ISTR, мутация используется для замены стека, поскольку виртуальная машина на основе стека может переполнять стек. Итак, F# правильно работает с ошибкой в ​​CLR.

person J D    schedule 28.08.2010