Существуют ли какие-либо инструменты, которые помогают в переносе F# на OCaml?

К сожалению, из-за отсутствия в .NET инкрементного GC (либо в MS, либо в моно-реализации), создание программного обеспечения реального времени, такого как игры с F#, является проблематичным. Я написал язык в F#, который, если -

A) он не работает адекватно перед лицом поколения GC (произвольные паузы во время интерактивного моделирования, и б) данные, используемые получает хороший полноценный порт с помощью LLVM бэкэнд -

Я перенесу его из F# в OCaml. Я избегал как можно большего количества специфичных для .NET библиотеки, как я мог, и поскольку синтаксис F#основан на OCaml, я предполагаю, что должны быть некоторые автоматизированные инструменты, чтобы помочь в преобразовании кода.

Кто-нибудь знает о таких вещах, законченных или находящихся в стадии разработки?

Большое спасибо!

2 3
f# llvm real-time ocaml

2 ответа:

Чтобы ответить на ваш вопрос в ответе - насколько я знаю, таких инструментов нет, и я не думаю, что кто-то их создаст.

Хотя F# вдохновлен OCaml, он сильно эволюционировал и отличается по ряду причин (см. это обсуждение SO), поэтому автоматическое преобразование не является тривиальным. Даже если бы кто-то сделал это, это было бы больше похоже на компиляцию в трудночитаемый OCaml, чем на преобразование в идиоматический код, над которым вы можете позже продолжить работу.

К добавьте несколько общих замечаний, когда вы говорите о" реальном времени", я представляю себе управление каким-то роботом на заводе, занимающемся опасными вещами или управлением самолетом. В этих областях опасения по поводу ГК, безусловно, обоснованны. Однако я не думаю, что игры обязательно должны быть "в реальном времени". Вам нужна хорошая производительность, это точно, но люди пишут игры с .NET и F# довольно счастливо. Некоторые примеры F# см.:

Это, вероятно, проще, чем то, к чему вы стремитесь, но может быть достаточно хорошо, чтобы показать, что написание игр с использованием GC выполнимо.

6

К сожалению, из-за отсутствия в .NET инкрементного GC (либо в реализации MS, либо в моно), создание программного обеспечения реального времени, такого как игры с F#, является проблематичным.

Несколько моментов здесь:

  • Инкрементные GCs-не единственный способ получить низкие паузы. Параллельные GCs, такие как VCGC, выполняют работу в объеме, но делают это одновременно с запущенными мутаторами, например, реализация VCGC, которую я описал в несвободной статье здесь выполнялась с суб-миллисекундных время паузы.

  • Инкрементный GC не обязательно означает низкое время паузы. Например, GC OCaml обычно имеет паузы 10 мс и может иметь произвольно длинные паузы, когда он сталкивается с глубоким стеком потоков или длинным массивом в куче.

Я измерил типичное время паузы 10 мс с OCaml и 30 мс с F# на .NET 3. С помощью простой реализации я смог построить отказоустойчивый сервер в F# с нуля, который обрабатывал 20k msgs/s с 50% задержки под 114us и 95% под 500us.

Я написал язык в F#, который, если -

А) он не работает адекватно перед лицом поколения GC (произвольные паузы во время интерактивного моделирования, и

Я бы не отказался от платформы - ваша первая рабочая версия имеет недопустимую задержку. Есть много вещей, которые вы можете сделать, чтобы снизить максимальную задержку.

Б) данные, используемые получает хороший полноценный порт серверной инфраструктуры LLVM -

Я серьезно сомневаюсь, что OCaml когда-либо получит то, что я бы назвал "хорошим полным портом для бэкенда LLVM". Они просто перенастроят LLVM с текущим безтиповым IR, и он будет работать не намного лучше, чем текущий компилятор ocamlopt, потому что LLVM не предназначен для оптимизации такого рода рабочей нагрузки.

Я перенесу его из F# в OCaml. Я избегал как можно большего количества библиотек, специфичных для .NET, и поскольку синтаксис F#основан на OCaml, я предполагаю, что некоторые из них должны быть автоматизированные инструменты для помощи в преобразовании кода.

Нет автоматизированных инструментов, но я перенес сотни тысяч строк кода между OCaml и F# теперь, и это, как правило, очень легко, потому что большинство кода написано в основном подмножестве ML обоих языков.
6