2010-11-29 2 views
50

Я провел последние 18 месяцев, получив контроль над функциональным программированием, начиная с изучения OCaml и уже несколько недель Haskell. Теперь я хочу сделать следующий шаг и реализовать какое-то реальное приложение: простой редактор ландшафта в реальном времени. Я написал многочисленные механизмы рендеринга в реальном времени, поэтому это знакомая тема. И используемые рекурсивные алгоритмы и структуры данных кажутся очень подходящими для функциональной реализации.Что действительно более показательно? Haskell или OCaml

Учитывая, что это приложение в реальном времени, я, естественно, ищу лучшую производительность, которую я могу получить. Теперь некоторые (IMHO весьма раздражающие) сторонники OCaml довольно часто суют против Haskell медленным по сравнению с OCaml или F #. Но в соответствии с The Computer Language Benchmarks Game Хаскелл часто бьет OCaml, если только довольно небольшими фракциями - остается проблема, что в этом тесте взяты только очень конкретные образцы.

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

Но, может быть, другие люди делали сопоставимые приложения в OCaml и Haskell и давали некоторые цифры?

+4

@Trufa, я бы посмел сказать, что принцип DRY применяется при меньших «деталях», чем целое приложение; это будет иметь большее значение для метода или уровня класса. Я согласен с OP, что вы можете напрямую сравнивать только два языка и платформы, когда они по сути делают то же самое, но, конечно, это довольно экстремальный способ узнать и не очень практичен в большинстве случаев. – stakx 2010-11-29 21:18:03

+4

@Trufa: Написание двух эквивалентных программ для сравнения их характеристик производительности не имеет ничего общего с принципом DRY. DRY имеет один канонический источник для части информации, не так много независимых источников. В этом случае ни одна из программ сама по себе не содержит необходимой информации, поэтому DRY будет только вступать в игру, если вы уже написали сравнение и рассматривали ее снова по какой-то загадочной причине. Два - это минимальное количество программ, необходимых для сравнения, поэтому я не вижу, что это может быть «простой неэффективностью» по сравнению с. – Chuck 2010-11-29 21:19:52

+0

@stakx, хорошо, что вы на самом деле правы (удалил мой первый комментарий, чтобы избежать путаницы), Может быть, он применит, мне следовало бы не повторять себя, и нет, чтобы не повторить сам принцип :) Я не знаю, но если не это очень маленькая часть программного обеспечения, для меня нет смысла строить ее дважды, просто хотел указать на это. – Trufa 2010-11-29 21:23:05

ответ

57

По всем учетным записям, как OCaml, так и Haskell имеют достаточно эффективные компиляторы и время автономной работы практически для любого. Выбор между ними на основе чистого исполнения кажется мне глупым. Вы зашли так далеко - отошли от явно самых низкоуровневых и передовых языков (C, C++ и т. Д.) Во имя более четкого, более сжатого, более выразительного кода более высокого уровня. Итак, почему, когда различия в производительности значительно меньше, переключитесь на эти критерии сейчас?

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

Если вы хотите только очень грубый параллелизм в лучшем случае, и вы намерены придерживаться в основном функциональных структур, а затем выбирайте на основе чего-то другого, например синтаксиса (я думаю, что Haskell здесь гораздо приятнее, но это субъективно) или доступных библиотек (Haskell выигрывает от количества/доступности, но OCaml может отказаться от этого в отделе графики, тем не менее).

Я не думаю, что вы ошибетесь в любом случае

19

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

22

Я написал многочисленные двигатели рендеринга в реальном времени, поэтому это знакомая тема.

Знакомый достаточно, чтобы узнать, где больше всего времени будет потрачено?

Если да, то, возможно, вы можете написать код только для той части на разных языках и сравнить.

Но согласно The Computer Language Контрольные показатели игры Haskell часто бьет OCaml, если только сравнительно небольших фракций - остается проблема, что этот тест занимает только очень специфические образцы.

Игра контрольные отчеты 4 набора результатов - одно ядро ​​и quad core, 32 или 64 битную Ubuntu - и вы можете обнаружить, что программы тестов OCaml или Haskell работать лучше или хуже в зависимости от платформы.

Все, что может сделать бенчмарк, это взять очень конкретные образцы, и, конечно же, вы должны игнорировать сравнения по задачам, которые в отличие от того, где в вашем приложении будет потрачено больше времени - большая целочисленная арифметика? регулярное выражение? строки? - и посмотрите на сравнения, которые больше всего похожи на то, что вы намереваетесь сделать.

37

С помощью двух очень умных коллег, я написал библиотеку оптимизации потоков данных, как в Objective Caml и Haskell. Версия Haskell немного более полиморфна, имеет больше времени проверки типа компиляции и, следовательно, имеет меньшую проверку времени выполнения. Версия OCaml использует изменчивое состояние для накопления фактов потока данных, которые могут быть быстрее или медленнее на этой неделе, в зависимости от фазы луны. Ключевым фактом является то, что в их предполагаемых приложениях, обе библиотеки настолько быстра, что их не стоит обманывать. То есть в соответствующих компиляторах (Quick C-- и) так мало времени тратится на оптимизацию потока данных, что код не стоит улучшать.

Бенчмаркинг - это ад.

16

Интересный вопрос. Этот whole-planet terrain renderer был одной из последних программ, которые я написал на C++, прежде чем перешел на OCaml. Оглядываясь назад, эту программу было бы намного проще писать в OCaml, чем на C++. Haskell должен сделать это сравнительно легко, но программы обычно много сложнее оптимизировать в Haskell. Теоретически, Haskell лучше поддерживает мультикоры, но на практике даже эксперты редко получают приличные результаты, используя Haskell для параллельного программирования.

Кроме того, для приложений реального времени вам также понадобятся низкие времена паузы от сборщика мусора. OCaml имеет приятный инкрементный сборщик, который приводит к небольшому количеству пауз выше 30 мс, но у IIRC, GHC есть сборщик стоп-карт, который накладывает произвольно длинные паузы.

Я предполагаю, что вы используете Linux или F #, будет намного лучшим выбором, чем OCaml или Haskell.

EDIT: Если вы хотите изучить перестрелку, убедитесь, что вы прочитали исходный код. Вы также можете найти Haskell wiki pages about it интересный.

Смежные вопросы