F # вопросы компилятора

Question

Пара вопросов о компиляторе F #

1) что делает --noframework? Я скомпилировал его, но мне все еще был нужен .Net 4.0 (я подумал, может быть, он разрешил порт для более ранней версии?) Удаляет ли он зависимость F #?

2) Какие оптимизации включает F # --optimize +? все они? если да, то что они все?

3) Каковы преимущества / недостатки --tailcall? Я знаю, что x64 иногда игнорировал .tailcall, мне было любопытно, были ли другие проблемы или эти проблемы сохраняются.

4) что такое --crossoptimize и что оно делает?

5) Есть ли на самом деле быстрый подъязык или это что-то действительно старое ??

Answer 1

Вот более подробный ответ на вопрос 2. Компилятор F # имеет много опций для оптимизации, и --optimize + включает большинство из них.

Чтение из исходного кода компилятора, вот список вещей, которые --optimize + включает. Я также даю вам скрытые флаги, на случай, если вы захотите поиграть с ними. Конечно, поскольку это не скрыто и не задокументировано, это может измениться в следующем выпуске:

• JIT-оптимизация (--jit-optimize)
• локальные оптимизации (--local-optimize), такие как устранение мертвых частных привязок.
• межмодульная оптимизация (--crossoptimize +)
• разрешить встраивание лямбда-функций (--inlinethreshold: 6). Большие функции, размер которых больше заданного предела, не будут встроены.
• устанавливает ignoreSymbolStoreSequencePoints (для этого флага нет)
• исключить кортежи, выделенные на сайтах вызовов, из-за неиспользуемых функций (--detuple: 1). См. detuple.fs для подробного комментария.
• do TLR (--tlr: 1). Я не знаю, что это такое, но есть много комментариев в tlr.fs
• последний этап упрощения (--finalSimplify: 1) применяет некоторые оптимизации во второй раз (после других этапов оптимизации).

Похоже, что --extraoptimizationloops: 1 флаг не активируется --optimize +. Он выполняет те же оптимизации, что и последний упрощенный проход, но в другое время. Может быть бесполезным.

В вопросе 3 оптимизация хвостовых вызовов очень полезна для предотвращения переполнения стека (когда вы выполняете много хвостовых рекурсивных вызовов). Это усложняет отладку, так что вы можете иногда отключить ее (это по умолчанию в VS в режиме отладки).

Answer 2

Вот несколько быстрых ответов, основанных на памяти. (Вы всегда можете подробно изучить код компилятора.)

1) Позволяет нацеливаться на разные фреймворки, не пытаясь неявно использовать какие-либо сборки mscorlib / FSharp.Core. Таким образом, вы используете это, например, когда вы явно ссылаетесь на Silverlight mscorlib / FSharp.Core, чтобы указать на Silverlight.

2) Да, почти все из них, и я не знаю, чем они все являются. Вы можете посмотреть на opt.fs.

3) Отладка - при использовании VS в режиме «Отладка» --tailcalls- передается для отключения оконечных вызовов и сохранения всех кадров стека для упрощения отладки.

4) FSharp может выполнять встраивание и другие оптимизации через границы сборки. Это может быть опасно для опубликованных библиотек, потому что, если ссылки A B и A были скомпилированы с помощью перекрестной оптимизации, а затем развернуты, а затем кто-то изменил / повторно развернул B, возможно, что A "вызовет" метод в "старом" B, потому что это код из B был встроен в A, и поэтому A все еще имеет «старый B» код, если A не перекомпилирован. На практике это редко имеет значение, но в «типичном» сценарии, если у вас есть несколько зависимых, но независимо распространяемых библиотек F #, вы хотите отключить перекрестную оптимизацию, чтобы избавиться от хрупких зависимостей.

5) Это больше не существует.