LINUX.ORG.RU

На чем сейчас модно писать научные программы?


0

3

Конечно большинство сегодня по инерции еще пишут на Фортране или Си, но ведь задачи на сегодняшний день изменились, требования уже другие. Да и логика гораздо сложнее стала.
Расчеты требуют больше удобного написания программы, чем скорость счета (не продакшен же), но скорость тоже важна.

Вот думаю, что бы можно было посоветовать молодому поколению (т.е. аспирантоте), если учить ЯП все равно какой-то придется.

★★★★★
Ответ на: комментарий от Ignatik

>Я сам пытался использовать Коммон Лисп для научных расчётов

А может быть стоит использовать CL по назначению?

Macil ★★★★★
()

Помнится, в свое время в matlab забацал программку на матрицах, которая за пол-часа считала то, что их программа на c/c++ за сутки еле-еле сводила. Правда у меня только пара недель ушла на понимание того простого принципа, что исходное приближение должно быть непротиворечивым по массообмену (управление СОТР, тепло-массообмен, огромная система нелинейных уравнений сводилась с учетом физики процессов и математики к 91 уравнению, чтоб поместиться в стандартные ограничения matlab по размеру матриц/8 байт на число/) — и все будет Ok и быстро. Смог предоставить решение и полностью оправдал финансирование.

anonymous
()
Ответ на: комментарий от dinn

> Только вот если новый проект (и новый разработчик), то для фортрана новее 95-го даже нормальной литературы нет.

Гм, как будто по Фортрану 90/95 есть _нормальная_. Почему-то многие вещи остаются непонятными даже после полного прочтения того же Бартеньева. Например, области видимости переменных: где они задаются локально, а где - глобально. Чтобы начать писать на Си достаточно 1й главы K&R, где все сразу расставлено по местам. Мне Си и полюбился именно после этой книги.

iVS ★★★★★
()
Ответ на: комментарий от Ignatik

> Я сам пытался использовать Коммон Лисп для научных расчётов

Внутрь Лиспа можно засунуть любой код, хоть Си, хоть ассемблер. Но вопрос, как это понимать: вы пишете на Си/ассембелере или всё еще на Лиспе :-)

iVS ★★★★★
()
Ответ на: комментарий от anonymous

> Помнится, в свое время в matlab забацал программку на матрицах, которая за пол-часа считала то, что их программа на c/c++ за сутки еле-еле сводила.

Только считал Matlab не «то, что их программа на c/c++», а что-то другое, жутко заоптимизированное.

iVS ★★★★★
()
Ответ на: комментарий от iVS

> Только считал Matlab не «то, что их программа на c/c++», а что-то другое, жутко заоптимизированное.

Считал ту же систему обеспечения теплового режима, но немного преобразованную. Пришлось пару месяцев вникать в немного непривычную (без гравитации) физику процессов тепло-массообмена, чтоб почувствовать себя уверенно в системе и понимать, что можно преобразовать, а что нельзя (пришлось даже a`la сдавать экзамен по системе двум академикам, хех :-). Был период попытки решения задачи «в лоб» и был период допустимого переосмысления целей и инструментов их достижения. В любом случае реализация стандартных алгоритмов в matlab по тем временам была на порядок быстрее любой ручной реализации этих же алгоритмов на c/c++, однозначно.

anonymous
()
Ответ на: комментарий от anonymous

> Помнится, в свое время в matlab забацал программку на матрицах, которая за пол-часа считала то, что их программа на c/c++ за сутки еле-еле сводила.

А если бы _Ваш_ алгоритм был переведён в си один к одному, и написан правильно - то было бы _гораздо_ менее получаса. Это я пишу для того, чтобы не было ложного впечатления, что матлаб быстрее си. Надо же сравнивать яблоки с яблоками, а не яблоки с апельсинами! Ясно же, что матлаб как фреймок имеет оверхеды, кои можно избежать, переписав только то - что действительно нужно на си (при той же точности, да ещё и поколдовать-пооптимизировать, что матлаб как общий инструмент не сделает как минимум в специальных случаях). И оракловский оптимизатор можно обмануть на сложных запросах, когда что-то действительно сложное, из чего делаю вывод, что и матлабовский оптимизатор (если он конечно есть, здесь я не спец) можно человеческим интеллектом обогнать, зная наперёд объёмы входных данных.

Я специально не упомянул матлаб и SAS выше, так как вопрос был о языках для написания отдельных (как я понял) программ. А не пруфа или единичной проги, работающей в организации.

Да, на матлабе и SAS много прототипов пишется даже для конечных программ (как пруф оф консепт), но потом то же самое, для конечного юзера, переписывается на C, C++, java. Нет SASа или матлаба у конечного юзера, и требовать их покупки невозможно (дорого!). Да это и невыгодно - когда заказчиков много (переписать на си и разослать тысячи копий проги, написанной на универсальном языке полюбому дешевле). Кстати, те же люди (по крайней мере некоторые), коих я упомянул выше, то же самое быстро набрасывают на матлабе, так как матлаб вроде учили все. Некоторые на SAS (тоже многие учили), и дают оттестированный код/алгоритм позже программерам для переписывания.

Забыл добавить к исходному посту: знаю людей ещё пишущих на openVMS для ускорителей. А также на EPICS, и на перле тоже пишут.

siberean
()
Ответ на: комментарий от siberean

но openVMS, как мне говорили уже «не модно» (это к исходному вопросу). Всё больше (там) входит EPICS.

siberean
()
Ответ на: комментарий от siberean

> матлаба у конечного юзера, и требовать их покупки невозможно (дорого!)

И не нужно. Есть redistributable MATLAB Runtime.

anonymous
()
Ответ на: комментарий от anonymous

В любом случае реализация стандартных алгоритмов в matlab по тем временам была на порядок быстрее любой ручной реализации этих же алгоритмов на c/c++, однозначно.

Вот, что сказано в документации:

MATLAB uses Basic Linear Algebra Subprograms (BLAS) for its vector inner product, matrix-vector product, matrix-matrix product, and triangular solvers in \. MATLAB also uses BLAS behind its core numerical linear algebra routines from Linear Algebra Package (LAPACK), which are used in functions like chol, lu, qr, and within the linear system solver \.

On some platforms, MATLAB continues to use ATLAS BLAS.

Поэтому использование BLAS в программе на C/C++ дало бы ту же скорость стандартных алгоритмов. Может криворукие программисты попались?

iVS ★★★★★
()
Ответ на: комментарий от siberean

> А если бы _Ваш_ алгоритм был переведён в си один к одному, и написан правильно - то было бы _гораздо_ менее получаса. Это я пишу для того, чтобы не было ложного впечатления, что матлаб быстрее си. Надо же сравнивать яблоки с яблоками, а не яблоки с апельсинами!

Да какие проблемы? Напишите реализации вычисления, например, определителя и обратной матрицы 91x91 на c/c++ и сравните скорости вычисления с matlab.

anonymous
()
Ответ на: комментарий от anonymous

реально 91x91, а 9100 на 9100 или ещё побольше? и писать нужно вручную и криво, или можно нормально использовав mkl или goto.

qnikst ★★★★★
()
Ответ на: комментарий от iVS

> Может криворукие программисты попались?

Может быть. Ревизию их кода и алгоритмов не проводил - у меня была своя конкретная задача, за которую платили конкретные деньги. Когда оказалось, что расчет реакции системы на управляющее воздействие будет длиться сутки-двое — вопрос встал ребром и оказалось проще забацать свой расчет той же системы, решив по-ходу дела и их проблемы.

anonymous
()
Ответ на: комментарий от qnikst

> реально 91x91, а 9100 на 9100 или ещё побольше? и писать нужно вручную и криво, или можно нормально использовав mkl или goto.

Честно говоря, подробности сейчас помню слабо - оно уже давно летает. Там было реальное ограничения matlab в размер сегмента памяти DOS на матрицу. А исходная для меня система, с достаточной детализацией, была где-то в 254 (если не ошибаюсь) уравнения.

anonymous
()
Ответ на: комментарий от anonymous

матриц размер-то какой, хотя бы порядок?

btw, я не поверю, что матлаб будет работать быстрее, чем математические библиотеке на фортран, написанные с учётом оптимизации под контретные процессоры и уже распараллеленные.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

> матриц размер-то какой, хотя бы порядок?

254 нелинейных уравнения с 254 неизвестными => 254x254

btw, я не поверю, что матлаб будет работать быстрее, чем математические библиотеке на фортран, написанные с учётом оптимизации под контретные процессоры и уже распараллеленные.

Кстати, забыл добавить, что было это в далеком 1996 году и, да, был изначально в проекте задействован и фортран, и с/c++, вот только какие библиотеки там использовались - ничего сейчас не могу сказать... :)

anonymous
()
Ответ на: комментарий от qnikst

Ларчик просто открывается. Аноним просит написать СВОЙ алгоритм по решению СЛАУ, нахождения определителя и т.д. в то время, как матлаб использует уже оптимизированные и оттестированые, проверенные временем библиотеки (BLAS,LAPACK). Если бы те неведомые программисты в далёком 1996 году использовали бы сами готовые библиотеки, а не использовали свои собственные велосипеды, код был бы гораздо быстрее. А если вспомнить, что аноним реализовал не их алгоритм, а свой модифицированный, то всё становится на свои места.

Rakot ★★
()
Ответ на: комментарий от anonymous

>> матриц размер-то какой, хотя бы порядок?

254 нелинейных уравнения с 254 неизвестными => 254x254

ты взрываешь мне мозг, я тоже хочу так научиться решать нелинейные уравнения..

ну а про некорректность сравнения уже заметили.

qnikst ★★★★★
()

python, если нужна совместимость с научным сообществом, хаскелл для себя.

Arkarar
()
Ответ на: комментарий от Macil

> Да и в биоинформатике CL, ИМХО, уважают.

В биоинформатике насколько я слышал от людей - уважают прежде всего перл, awk, скриптование. Ну и конечно Си, джаву. Геномы очень большие, как правило речь идёт о многих геномах, т.е. гигантских файлах, где в программе надо чётко задавать буфера обработки, как обрабатывать (императивно), ведь даже один геном не уместится в память, не говоря о популяции. А базу за каждым аллелем из триллионов дёргать - будем висеть на IO. Т.е. алгоритмы там рулят но и строгий контроль за памятью и как именно что обрабатывается, т.е. императивщина (от чего CL AFAIK абстрагирует).

Кстати, видел книги типа «перл для биоинформатиков», но не видел «CL для биоинформатиков».

siberean
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.