Примечание: следующий пост может содержать противоречивые мнения, поэтому обратите внимание, что они являются только моими мнениями и не предназначены для того, чтобы кого-то обидеть.
Я программирую в той или иной форме примерно с 1999 года. Сначала я использовал R, а затем, примерно в 2004 году, перешел в основном на Python.
Например, для многих научных приложений, в том числе для моделирования, включая MCMC, и R, и Python слишком медленные и требуют ускорения. Обычный способ сделать это - расширить с помощью C или C ++. И для R, и для Python это то, что я сделал, используя R API C с C ++ и библиотеку Boost Python с Python.
Однако по разным причинам эта комбинация не является идеальным решением. Что важно в программировании, особенно алгоритмы? Выразительность и скорость, которые, конечно, связаны. Чем выразительнее язык, тем быстрее на нем можно писать.
1) Что касается выразительности, то, на мой взгляд, ни R, ни Python не являются идеальными для написания научных алгоритмов. Они не тесно связаны с базовым алгоритмом. Тем не менее, они оба значительно лучше, чем C ++.
2) Мне нравится писать на Python, который является приятным языком, хотя, как отмечалось выше, он не идеален для алгоритмической работы. Однако, когда приходится работать с комбинацией Python / C ++ из-за проблем со скоростью, с этим сочетанием становится значительно менее приятно работать. Обычно происходит то, что я сначала пишу на Python, и когда у меня получается что-то, что работает хорошо, часто обнаруживают, что это слишком медленно (для некоторого субъективного значения слишком медленно). Затем я сталкиваюсь с решением о том, стоит ли тратить какое-то неоправданное количество времени на его переписывание на C ++ или смириться с медлительностью. Оглядываясь назад, я часто чувствую, что, возможно, мне лучше смириться с медлительностью, особенно учитывая, что полученные ускорения непредсказуемы. Кроме того, интерфейс Boost Python между ними является значительной головной болью при обслуживании, и склеивание кода на двух очень разных языках, как это просто отвлекает. Никакой критики в адрес Boost Python нет, это настолько мощный интерфейс, насколько можно себе представить, и почти все время он работает.
Теперь, в идеальном мире, с неограниченным временем и ресурсами, ни одна из этих проблем не будет серьезной. Однако в научных проектах, над которыми я работал, у меня был следующий опыт.
Независимо от того, есть ли у меня коллаборационисты в проекте, мне всегда кажется, что я выполняю подавляющее большинство вычислений. В общей сложности 5 значимых проектов, я имел существенное участие только одного человека в одном проекте. Этот один человек сделал больше, чем потянул его вес; он сделал столько же, сколько я или больше. Однако во всех других случаях, включая проекты с несколькими соавторами, я (практически) выполнил всю вычислительную работу. Хотя я могу сказать, что я не был благословлен лучшими соавторами (это, кажется, смесь лени и некомпетентности), мне не ясно, изменится ли эта ситуация в будущем.
Вычислительная научная работа требует огромных усилий, и если я не могу изменить поведение моих сотрудников, я могу изменить способ своей работы. Самым важным улучшением было бы сделать вещи быстрее. Это подводит меня к основному соображению, заключающемуся в том, что переключение языков на что-то менее ортодоксальное может помочь. Основываясь на прошлых исследованиях, наиболее вероятными кандидатами в порядке вероятности являются Common Lisp и Ocaml. Я думал об этом в течение многих лет, но в последнее время думал об этом более серьезно.
Насколько я могу судить, мало кто использует CL или Ocaml для научных расчетов. При поиске на этом сайте я нашел две ссылки на CL (одна была моей) и одна на Ocaml (моя). За эти годы у меня была пара обнадеживающих контактов с предприимчивыми людьми, работающими на краю. В 2008 году я наткнулся на рецензию Тамаса К. Паппа на книгу «Практический общий Лисп» Питера Сейбела (которая принадлежит мне). Это привлекло мое внимание, так как это было одно из немногих упоминаний о научных вычислениях для Lisp, с которыми я сталкивался в сети. Я написала Тамасу, который немедленно ответил услужливо и ободрительно. Процитировать его
Моя производительность программирования, вероятно, увеличилась в десять раз с Лиспом, но на это ушло около года, и я все еще учусь (хотя через 2 месяца у меня все было хорошо). Так что, если вы работаете над чем-то критически важным, откладывайте переход.
Вы должны рассмотреть вопрос о людях по cll, я не единственный, кто знает об этих вещах, другие занимаются научными вычислениями на Лиспе.
У него также есть блог и страница GitHub .
Другим человеком, с которым я кратко переписывался (в декабре 2006 года), была Ира Калет , которая использовала Common Lisp в контексте радиационной онкологии.
Возможно, есть другие, которые занимаются научными вычислениями на Лиспе, но я никого не знаю.
Наиболее распространенная проблема, с которой люди сталкиваются в CL, - это отсутствие библиотек. Это серьезная проблема в вычислениях общего назначения, но не в такой степени, как в научных вычислениях, особенно при внедрении алгоритмов с нуля. В частности, я могу получить большую часть времени с помощью базовой математической библиотеки, включая функции распределения вероятностей, библиотеку многомерных массивов и базовый набор контейнеров, например map, set, list и т. Д., Которые можно найти в стандартных библиотеках C ++ и Python.
Я знаю об Ocaml даже меньше, чем о CL, но добавил это как альтернативу. Он, предположительно, очень быстрый, имеет одну бесплатную реализацию французскими исследователями и кажется наиболее жизнеспособным из семейства языков ML для научных вычислений.
В заключение мне интересно, есть ли у других опыт с этим и какие у них мысли, если таковые имеются.
РЕДАКТИРОВАТЬ: Я в основном интересуюсь из первых рук, в контексте вопросов, которые я обсуждал выше. Например, если вы использовали Python и C ++ (или R и C ++) и перешли на более неясный язык, мне было бы очень интересно услышать о вашем опыте.
Ответы:
Мы разработали Юлю по точно причинам поднятым. Просто не было хорошего языка научных вычислений высокого уровня, который также давал бы достаточно хорошую производительность, чтобы вам не приходилось переписывать части кода на C / Fortran. Конструкция julia имеет значительное влияние, так что вы можете найти его по своему вкусу, в то время как ваши сотрудники могут просто относиться к нему как к matlab или R, если им нет дела до функциональных частей. Недостатком является то, что язык является новым и еще не имеет всех библиотек, которые понадобятся для повседневного использования.
Марк, хотел бы добавить Джулию в свой тест, чтобы посмотреть, как у нас дела. Перейдите к нашему списку рассылки и дайте нам знать, что вы хотели бы увидеть в Джулии, чтобы это было более полезным для вас.
источник
Скорость, размер и надежность языков программирования отлично справляются с множеством различных вопросов, выраженных в вашем «вопросе». Он сравнивает скорость и размер кодовой базы множества реализаций одинаковых тестов на 33 языках!
Я стал любителем Python в основном потому, что гораздо больше времени на программирование у меня больше, чем на программирование. Я более чем готов потратить циклы процессора, чем пожертвовать временем, которое можно было бы посвятить чему-то более интересному.
Также +1 на Юлию. Я думаю, что могу переключиться на него, когда он станет немного более стабильным и широко поддерживаемым, то есть когда стандартные модули обернуты для работы, которую я люблю делать.
источник
Для научных приложений OCaml, см., Например,
Для Lisp в науке, см. Например
Я уверен, что есть еще много ссылок. Тем не менее, я не могу привести какой-либо крупный исследовательский проект, в котором вычислительная работа была выполнена в OCaml или Lisp. Выбор любого из них означает работу в относительной изоляции.
Вас также может заинтересовать Julia , новый язык для научных вычислений, который в настоящее время разрабатывается, с явным влиянием на Лисп.
источник