Какой хороший и безопасный язык для рисования интенсивных систем частиц в течение длительного периода времени? - PullRequest
1 голос
/ 11 сентября 2011

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

В настоящее время я написал несколько приличных программ, в которых есть RESTful-клиент типа roll your own, который извлекает данные из твиттера. Затем эти данные визуализируются с помощью ряда систем частиц с использованием Open FrameWorks (фреймворк, работающий с c ++).

Мои планы заключались в том, чтобы бесконечно запускать программное обеспечение на моем VPS и создавать какой-то интерфейс GUI, позволяющий пользователям исследовать красивые частицы и так далее. Между библиотекой JSON, которую я использую, C / C ++, OpenFrameworks и волнующимся Xcode4, я создал слишком много ошибок SIGBIRT и GDB, чтобы их можно было обработать. Я пошел к концу виртуального мира, чтобы исправить их, и переписывал все снова и снова. Мне даже удалось SIGBIRT метод рисования кругов с открытым каркасом, ХА!

(TL; DR начинается здесь). Хорошо, так или иначе, я начинаю с нуля, ищу мощный язык, который мог бы перебирать математику и взрываться через хороший набор частиц, и работать довольно хорошо в течение самых длительных периодов времени. Прямо сейчас я думаю о haskell, есть идеи?

Заранее всем спасибо!

Ответы [ 2 ]

5 голосов
/ 12 сентября 2011

Скорость обработки чисел в Haskell (или, точнее, в GHC) приближается к скорости C ++, но немного отстает.Однако это, конечно, не страшно, и преимущества Хаскелла в параллелизме могут стать важными.То есть, если вы сначала напишите это прямо на Haskell, есть большая вероятность, что будет легко реорганизовать его для параллельной работы сейчас или в будущем.Это не так верно для C ++.

Пакет 'vector' (в Hackage) был бы хорошим выбором для массивов, подходящих для обработки чисел.Он поддерживает изменяемые массивы в случае необходимости такого подхода.Тем не менее, если вы готовы пойти еще дальше, и ваш алгоритм может быть распараллелен, вы можете посмотреть на пакет 'repa', а для максимальной производительности на GPU посмотрите на 'Accelerate' (которыйработает, но все еще относится к категории экспериментальных).

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

Интерфейс сторонней функции в Haskell хорошо спроектирован, хотя вам потребуется написать клей C между Haskell и C ++.Итак, это еще один вариант для сокращения вашего номера.

Для веб-интерфейса посмотрите на 'yesod', который видит очень активную разработку и рекламирует себя как выполняющий RESTful.

2 голосов
/ 11 сентября 2011

AFAIK, скорость вычисления чисел не самая сильная сторона Хаскелла - это очень абстрактный язык, далекий от «металла»;его сила в контексте числовой обработки заключается в «математичности» его семантики - код на Haskell часто читается как математическое доказательство, и многие его концепции заимствованы из различных областей математики.

Для простого старого числаСкорее всего, C ++, вероятно, по-прежнему остается вашим лучшим выбором, поскольку он позволяет вам оставаться ближе к аппаратному обеспечению и оптимизировать узкие циклы на уровне машины, предлагая при этом высокоуровневые программные конструкции для управления сложностью.

OTOH, если выу вас есть библиотека для тяжелой работы, и вам просто нужно написать клей, чтобы заставить различные части работать вместе, а затем пойти с тем, что вам удобнее всего - python, C #, java, haskell, C ++, ...- пока у них есть привязки для всех ваших библиотек, у вас все хорошо.Если у вас нет библиотеки, вы можете также написать критические для производительности части в C, а затем перетащить их на ваш любимый язык высокого уровня - это тривиально в C ++, немного сложнее в python или haskell и довольно чертовскинеудобно в Java.

...