LINUX.ORG.RU

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


0

3

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

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

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

> а вот какую-нибудь библиотеку на Фортран 90/95

Поэтому они не нужны, все их возможности полностью перекрываются C++, а legacy код 77 можно дернуть и так.

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

> К сожалению, только статически аллоцируемые, ну или одномерные — на стеке, но стеки в линуксе по-умолчанию маленькие.

А какой прок от массивов для расчётов? Я-то сгоряча про использование матриц подумал, что приводят как аргумент в пользу Фортрана.

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

> накой мне пихать в систему то, чего нет в репе?

Сейчас наоборот в Linux выпиливают LAPACK в пользу как раз clapack.

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

>> А какой прок от массивов для расчётов?

И этот человек мне говорит о знакомстве с чмами!

Очевидно же, что толк один - троллить на ЛОРе.

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

Сейчас наоборот в Linux выпиливают LAPACK в пользу как раз clapack.

«Сейчас» — это где и когда? Или ты там из 2020 года пишешь? Ни clapack, ни lapack++ еще нет в репах ни одного распространенного дистрибутива

CentOS:

========================================= Matched: lapack ==========================================
R-RScaLAPACK.x86_64 : An interface to perform parallel computation on linear algebra problems using
                    : ScaLAPACK
atlas.x86_64 : Automatically Tuned Linear Algebra Software
blas.i386 : The BLAS (Basic Linear Algebra Subprograms) library.
blas.x86_64 : The BLAS (Basic Linear Algebra Subprograms) library.
blas-devel.i386 : LAPACK development libraries
blas-devel.x86_64 : LAPACK development libraries
lapack.i386 : The LAPACK libraries for numerical linear algebra
lapack.x86_64 : The LAPACK libraries for numerical linear algebra
lapack-devel.i386 : LAPACK development libraries
lapack-devel.x86_64 : LAPACK development libraries
scalapack.i386 : A subset of LAPACK routines redesigned for heterogenous computing
scalapack.x86_64 : A subset of LAPACK routines redesigned for heterogenous computing
scalapack-devel.i386 : Development libraries for scalapack
scalapack-devel.x86_64 : Development libraries for scalapack

ни clapack, ни lapack++

Ubuntu 10.04

apt-file search lapack | grep 'clapack'
libatlas-headers: /usr/include/clapack.h
libsphinxbase-dev: /usr/include/sphinxbase/clapack_lite.h
python-scipy: /usr/lib/python2.5/site-packages/scipy/lib/lapack/clapack.so
python-scipy: /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so
python-scipy: /usr/lib/python2.6/dist-packages/scipy/lib/lapack/clapack.so
python-scipy: /usr/lib/python2.6/dist-packages/scipy/linalg/clapack.so

 apt-file search lapack | grep 'lapack[+][+]'

lapack++ отсутствует. Предлагаешь их таскать везде и всегда с собой? Вместо одного .h файла возить с собой всю либу?

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

> Очевидно же, что толк один - троллить на ЛОРе.

Самокритичненько.

unanimous ★★★★★
()

Тут главный вопрос в том, что конкретно нужно. Если реализовывать задачи в терминах теории групп, то GAP или Axiom. Если реализовывать произвольные рассчёты, то надо подобрать набор необходимых библиотек и смотреть в какие языки у них есть биндинги. Например начать отсюда: http://www.gnu.org/software/gmp/manual/html_node/Language-Bindings.html и не рассматривать языки, которых нет в списке.

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

> Ubuntu 10.04 и без LAPACK нормально себя ощущает, в самом дистрибутиве от него ничего не зависит.

Ты издеваешься? Репы ubuntu содержат и дебиановские проги (если multiverse & universe подключены, а они подключены), т.е. отсутствие clapack/lapack++ там означает их отсутствие и в Debian. Что имеем в итоге? В RHEL/CentOS нет, в Федоре нет (по крайней мере в 10, на которой я работаю), в Debian/Ubuntu нет. Что осталось? Одни красноглазые дистрибутивы вроде арча с гентой? Нет уж, вы с ними сами... возитесь.

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

В генте все собирается с gcc. Накой ляд нужно тащить ещё и gfortran? Ради сборки LAPACK? Зачем, если тот же clapack - просто сконвертированный в Си LAPACK и он прекрасно собирается и так? С учетом темпов развития gcc и gfortran, вариант с clapack выглядит предпочтительнее. Добавим сюда возможность сборки на многих платформах и выбора других компиляторов типа PCC, и выгоды данного решения очевидны.

iVS ★★★★★
()

Из тех областей, что знаю я, считают на фортране и C++. В пользу фортрана огромное число библиотек, которые уже лет 40 разрабатываются плюс очень удобно работать с матрицами без лишних телодвижений + MPI и openMP из коробки. В пользу C++ большая гибкость + поддержка openCL, openMP,MPI из коробки, у меня в инсте, помнится, переписывали старые фортрановские либы на C++. На python знакомый парень писал диплом по распределённым базам знания, но он с CS и к физике никакого отношения его работа не имеет.

Rakot ★★
()

Python Его в отличие от всяких CL, яв и прочих сишарпов можно юзать для написания приложений, юзающих openmpi и прочие средства распараллеливания.

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

>Фортран тоже изменился? man Fortran 2008, к примеру

Только вот в России ему не жить: мало кто о нём знает и компиляторы стоят приличных денег.

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

4.2

Intel поддерживает частично 2008, а линуксовая версия даётся бесплатно для некоммерческого использования (дома на попробовать) + скидки для академического использования. Не забываем, ekopath уже под GNU v.3. Так что с компиляторами всё в порядке.

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

А как же Gfortran? Или вы про полноценный Fortran 2008?

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

>Intel...

Не надо закидывать томатами, я это всё знаю. Но вот с кем ни разговаривал, мало кто знает что после F77 вообще что-то есть. Да и даже на академическую лицензию денег не дадут, удавятся, везде пиратские matlab и labview.

ekopath уже под GNU v.3

Вот как выйдет стабильный релиз, а не ночные сборки, тогда и можно будет говорить, но опять linux-only, что почти для всех ставит крест на его использовании.

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

> В пользу фортрана огромное число библиотек, которые уже лет 40 разрабатываются

Мне эта фраза непонятна. Речь идёт об олдскульщиках, 40 лет пишущих программы на Фортране, у которых накопилась куча legacy кода? Это их багаж и их проблемы, никого другого не касающиеся. Или речь идёт о таких монстрах как NAG Library. MKL, IMSL? Так попробуйте их использовать на кластере или где-то ещё - сколько придётся выложить за лицензию? Где это «огромное число библиотек»? Я бы не сказал, что на netlib у фортрана тотальное превосходство.

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

Тут не всё так просто. Многие научные группы имеют свой собственный код и я говорю в основном про это. Переписывание всего этого с 77 фортрана на C или любой другой язык просто ад. Приятель этим занимался - это жесть. Кто знает, на что похож F77, тот поймёт, что я имею ввиду. Для остальных скажу, что это такая лапша, которая использует goto для каждого чиха, и когда число меток зашкаливает за сотню, код разобрать очень и очень сложно. Если же воспользоваться транслятором в C, то очевидно, что читаемый код не получится. Насчёт IMSL, что греха таить, у нас в стране многие используют пиратские версии. Опять же, если проект был начат с нуля есть смысл с фортраном не связываться, хотя работа с массивами мне в нём очень и очень нравится.

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

Не «почти всех». Кто работает на кластере, наверняка использует линукс. Кто нет - ССЗБ.

А наличие хотя бы 3-х различных компиляторов (ifort,gfortran и pathf90) может помочь хотя бы на этапе отладки.

Rakot ★★
()

C или C++. Альтернатив нет и не предвидится.

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

> Не «почти всех». Кто работает на кластере, наверняка использует линукс. Кто нет - ССЗБ.

Отталкиваясь от Linux, я бы взял для нового проекта Си + GSL, альтернатив этому не вижу.

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

Для нового проекта, думаю, да, альтернатив немного. Всё-таки MPI,openMP,openCL в коробке значат очень многое для кластера.

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

А, ну , значит, с фотонными кристаллами работаешь, я как раз видел ссылку на труды 50-й конференции? Только в чём такая гиперсложность LRnLA? Никто до этого не смог осилить запрограммировать? Так я и на этот вопрос ответ знаю (я имею ввиду почему) :)

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

С фотонными да, не я, но коллеги.

Никто до этого не мог такое придумать (были робкие попытки, а автор LRnLA дошел до конца) + да, никто кроме автора не может закодить. Даже я не могу;-) Есть авторская библиотека, остальные ее юзают. Там очень много подводных камней «дьявол кроется в деталях»

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

Он энтузиаст и патриот в хорошем смысле этого слова, и если б не его личный пример я бы сейчас был просто программистом;-)

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

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

Да я вообще физфак заканчивал, сейчас в ИПМ и в долгопе был раз 5;-) Да, наверно незнакомы. Ладно, буду я отчет писать дальше «Проведение испытаний и корректировка технической документации по результатам проведенных испытаний» епрст...

AIv ★★★★★
()

fortran77 и более ранние с современными инкарнациями фортрана имеют общего чуть более, чем ничего, кроме названия. После знакомства с первым от самого слова фортран начинает тошнить и до изучения fortran90 и более поздних не доходит. И очень напрасно. После моего опыта работы c fortran95 идея писать численные программы на си или даже на с++ кажется полным бредом. Хотя занимался этим лет 5 до того.

А какой прок от массивов для расчётов?

Ну вы, блин, даете

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

А какой прок от массивов для расчётов?

Ну вы, блин, даете

В комментарии речь шла о Фортран77 и его массивах как некое преимущество перед Си. Какое-такое преимущество, когда весь код F77 запросто конвертируется f2c в сишный?

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

> Насчёт того, что конвертируется, то проблем нет, но вот изменить его будет очень тяжело.

Это понятно. Практически любая автоматическая конвертация приводит к усложнению.

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

>если проект был начат с нуля есть смысл с фортраном не связываться, хотя работа с массивами мне в нём очень и очень нравится.

Только вот если новый проект (и новый разработчик), то для фортрана новее 95-го даже нормальной литературы нет. Поэтому чувствуешь себя никому не нужным маргиналом и хочется всё бросить пока не поздно и перейти на c++. Но есть подозрения, что с приходом c++0x (или как его теперь зовут) всё будет также, как в f77 - f90.

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

>Кто работает на кластере, наверняка использует линукс.

Задачи не требуют кластеров, максимум пару ксеонов под столом. Да и их пока нет.

dinn ★★★★★
()

C, C++, java (на каждом из них знаю людей, которые наверное и в эти минуты пишут для академии)

siberean
()

Я сам пытался использовать Коммон Лисп для научных расчётов, сразу огрёб кучу проблем. Отсутсвие поддержки 64-битных целых, ограничение на 512К эллементов в массиве, нетривиальная работа с нативными массивами и так далее. После этого понял что в числодробилке лиспу не место... Там, где я пытался пробывать Лисп, до сих пор пишут на С++ и все довольны, это обработка и статистический анализ огромных изображений

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