Fortran 2018: новый стандарт языка

хватает и простых списков

В том-то и дело, что совершенно не хватает. Ебл* со списками - это не сильно лучше for/while loops лесенок. Требуются векторные операции, причём как количественно (наличия всяких масочных операций типа merge над матрицами, поэлементных операций, срезов, декомпозиций и разложений), так и качественно (чтобы это работало по крайней мере не убийственно медленно).

На самом деле я сильно люблю SML, но в теме про HPC его упоминать - расписываться в своей очень низкой компетенции.

Под него дохрена либ. Лично наваял в своё время с пяток математических и физических либ.

А сколько у вас обычно задачи считаются?

Неделями, иногда месяцами на нескольких тысячах ЦПУ ядер. Некоторые можно и на GPU считать, но далеко не все, потому как памяти требуют много.

Какая IDE лучше подходит для Фортрана и какая поддержит фичи 2018?

Emacs. Некоторые vim используют. Никогда не слышал, чтобы кто-то что-то другое использовал.

hdf5

Откройте для себя мир без студенческих поделок.

Когда нужно сохранять действительно большие объёмы данных, я уж лучше буду использовать что-нибудь вроде hbook или root-файлов.

Попробуйте использовать память.

Да просто динозаврам от науки лень учить что то современное, тот же С++ вот и используют доисторическое гавно мамонта, что учили когда то в юности

на нескольких тысячах ЦПУ ядер. Некоторые можно и на GPU считать.

«Везуха» . А для распараллеливания кода на питоне что используете? Cython.parallel?

Попробуйте использовать память.

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

Вас попросили подтвердить ваши утверждения о мегабыстром I/O в Фортране конкретикой.

Вы ожидаемо промолчали.

Осталось только предполагать, как вы можете использовать I/O в том же C++, чтобы иметь проблемы со скоростью I/O.

На это предположение вы ответили идиотским и бесполезным комментарием.

Что лишний раз убеждает, что в вашем лице мы имеем дело с высокообразованным идиотом от науки.

Я говорю, используй память, что-нибудь в районе хотя бы 1 МБ, и получишь примерно то, что я пытался использовать.

man ROOT.

К сожалению сейчас все вынуждены пересесть на это.

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

Студент, не ленись и напиши сам свой лучший вариант чтения такого файла:

Заголовок события: (1X,F9.4, 3(1X,I15))
Тело (350-2000 строк): (1x,7(1XF9.4),1XI3,1XE12.4)

Хотя бы 1 миллион событий.

А потом вообще добавь перестановку событий внутри файла.

Cython.parallel?

OpenMP на тысяче ядер. Мальчик, ты совсем дурак?

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

Вы неоднократно говорили, что I/O в Фортране сильно быстрее такового в C++. На основании каких данных вы это утверждаете?

Можете ли вы показать примеры бенчмарков, которые подтверждают ваши слова?

У меня была одна задачка на 60 суток на кластере --- 40 ядер, маленький такой кластер. Я тогда сделал кусок кода на Фортране, 2 недели парился, с помощью f2py его приделал и время сократилось до 5 суток.

В вообще типично от нескольких секунд до нескольких суток на обычном ПК с распараллеливанием. Там много переборов, например, стартовых догадок для нелинейного МНК.

Именно чтение выходит медленно? А можно тогда сишный код, которым это читали? Хорошо и фортрановский, хотя я его всё равно не знаю, но может кто-то сможет сравнить.

Навскидку, если это C++ и используется форматированное чтение из потока, то оно заведомо медленное. Сишный fscanf тоже скорее всего неоптимален. Если используете read, то он максимально быстрый, значит парсинг медленный. Если читаются только куски файла, то может быть лучше mmap.

Первородный FORTRAN IV — вот идеал совершенства!!! Всё остальное — навороты :)

Именно чтение выходит медленно?

Пара задач из кухни HEP:
1) Переформатировать файл - т.е. чтение и запись в один и тот же файл с перестановкой блоков таблиц, причём размеры блоков (строк) могут отличаться на порядок (как их выгоднее хранить в C/C++?).
2) Форматированное чтение N значений подряд из строк переменной длины, т.е. в случае когда произвольная часть значений может переноситься на следующую строку.

Медленный I/O (и, возможно, хранение таблиц в фортране) проявился на первой задаче, удобство работы с ASCII - во втором, т.к. фортран позволяет читать формат не парясь про конец строки - сам переходит на следующую и продолжает читать.

И да, оба случая я пытался написать в том числе и на C, но первый так и не приблизился к скорости фортрана (лучшая попытка с чтением в/из буфера), а второй знатно потрепал мне нервы и by design на C не мог быть оптимальным. И да, я не мартышка-программист, я - научный сотрудник и я использую подходящие для работы инструменты: параллельно с ASCII мы постоянно используем и ROOT формат, и там проще использовать C++, а для быстрого предварительного анализа в ASCII - о боже, R!

Ну т.е. объективных замеров не будет?

Осталось только предполагать, как вы можете использовать I/O в том же C++, чтобы иметь проблемы со скоростью I/O.

Ты предлагаешь нс-ам вместо свой непосредственной работы заняться изучением и практикой в крестах до такой степени, чтобы они могли легко обходить встроенные средства в фортране (если допустить, что это возможно)? Может проще дустом эти институты обдать?

Или это ты так прорабатываешь своё будущее в плане работы?.. ))

Вы не поверите, но мне интересно было узнать о разрыве в производительности штатного I/O в Фортране и в C++. И, мне показалось, что когда человек надувает щеки так уверено говорит о разрыве в скорости, то у него есть конкретные цифры.

Но, к сожалению, все свелось к банальному «я не смог написать на C», «я не знаю, как читать данные в C++». И даже «я не знаю, чем отличается C от C++».

Так не интересно.

PS. При этом у меня нет и мысли утверждать, что штатный istream в C++ шустрый.

Ну так ты напишешь программу на c/c++? У меня нет на это времени, так что it's up to you.

Формат данных я тебе предоставил, но можешь использовать и какой-нибудь OSCAR: https://karman.physics.purdue.edu/OSCAR-old/docs/file/cascade_output_format/i...

Ну так ты напишешь программу на c/c++?

Нет такого языка, как «с/c++».

У меня нет на это времени

Вы думаете, что у меня оно есть?

Но ведь это не я говорил о разрыве в скорости. Раз вы типа научный работник, то должны понимать, что словам верить не принято. Хотелось бы видеть результаты замеров, на основании которых вы пришли к такому выводу.

А для питона встречаются коммерческие библиотеки, например, для научных исследований, для решения оптимизационных задач, моделирования и т.п.? Или почти все опен-сорс?

(мартышкам-программистам тоже хочется кушать)

Тебе уже два формата дали - напиши хоть что-нибудь.

чтение и запись в один и тот же файл с перестановкой блоков таблиц

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

2) Форматированное чтение N значений подряд из строк переменной длины, т.е. в случае когда произвольная часть значений может переноситься на следующую строку.

Без проблем. Читаем read, потом сами парсим. Или сразу fscanf, но она опаснее. В общем, тут может можно говорить об удобстве и безопасности, но никак не о скорости.

И ещё: я совсем не пытаюсь агитировать отказаться от фортрана в пользу си или крестов. Я просто утверждаю, что мнение о том, что на си ввод/вывод медленнее, чем на фортране, основан на ложных предпосылках. Правильнее сказать, что его можно реализовать медленнее. Так же, как можно и на фортране реализовать медленно, если толком не владеть этим языком.

А в плане удобств и скорости написания кода, си действительно не торт. Многое надо делать самому. А при использовании крестовых библиотек действительно может просесть скорость. Но если писать хорошо и знать, какой инструмент в каких случаях следует использовать, а в каких — нет, то с сишкой не сравнится ничто. Ну, может, фортран по скорости вычислений её и переплюнет. Но только вычислений, и не более.

Во-первых, позвольте еще раз сказать: вместо очередного подтверждения вашего идиотизма, я бы хотел увидеть результаты бенчмарков, на основании которых _вы_ говорите о высокой скорости I/O в Фортране.

Во-вторых, если вы думаете, что для постороннего человека вот это вот:

Заголовок события: (1X,F9.4, 3(1X,I15))
Тело (350-2000 строк): (1x,7(1XF9.4),1XI3,1XE12.4)

является полноценным описанием формата, то вы еще больший идиот, чем можно было предположить.

Поэтому специально для вас поясню: людям, очень далеким от Фортрана и ваших прикладных задач, может быть совершенно непонятно, что означают 1X, 1x, I15, 1XI3 и пр.

Поэтому, если вы пребываете в счастливой уверенности, что что-то кому-то рассказали, то нет. Лишь еще раз окрасили себя...

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

А потом следующая программа в цепочке будет делать свой анализ - так не пойдёт.

Читаем read, потом сами парсим.

Именно так. Но куда проще сразу использовать фортрановское форматированное чтение.

Вы меня, конечно, извините, но:

(1X,F9.4, 3(1X,I15))
(1x,7(1XF9.4),1XI3,1XE12.4)

- это уже довольно подробно и понятно.

Как вы вообще оказались рядом с программированием, если не можете понять базовые, в общем-то, вещи?

Т.е. вы сливаетесь вообще по всем пунктам?

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

И да, я не собираюсь откапывать свой старый код просто потому, что не собираюсь. Мне достаточно своего опыта, опыта работы своих коллег, чтобы понять, что c/c++ для ASCII - это очень неудобно и медленно. Даже если ноунейм студент из интернета в этом сомневается.

Молодой человек, все, что я хотел сказать по теме предметно, я уже сказал здесь: Fortran 2018: новый стандарт языка (комментарий)

Но вы можете продолжать демонстрировать свой идиотизм и дальше.

Это действительно непонятно, не только студентам и «веб-макакам». Программисты в общем случае такой нотации никогда не видят.

Ну а теперь возьми и напиши код. Хорошо и быстро напишешь - возьму в команду на оклад. Подумай.

А для питона встречаются коммерческие библиотеки, например, для научных исследований, для решения оптимизационных задач, моделирования и т.п.? Или почти все опен-сорс?

gurobi, cplex, сотни их, на самом деле.

Эмм...

В МИФИ вроде бы даже этому учат: http://www.accel.ru/abitur/inform/programming/fortran-pr2013/index.php?fname=...

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

На самом деле проблема в том, что ты и как работает cython.parallel понятия не имеешь.

Спасибо! Просто есть одна задумка.

Так это фортрановская специфика, а тут больше сишники набежали...

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

www.linux.org.ru/images/16134/original.jpg

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

А потом следующая программа в цепочке будет делать свой анализ - так не пойдёт.

Конечно, любая задача (я говорю о задаче в широком смысле, а не об отдельной программе, которая может быть только частью общей задачи) имеет свою специфику. Но СУБД обычно неплохо справляются с сортировкой индексов, поиском по ним и фильтрацией. Думаю, что имеет смысл потестировать, как с такой задачей справится СУБД, и, думаю, в целом она справится лучше, чем собственный велосипед, сортирующий огромные записи вместо ключей. Разумеется, все программы должны работать с этой базой данных, а не с файлом, а значит, их все придётся переписать. В качестве временного варианта можно генерить из БД старый отсортированный файл. Но только временно, т. к. в таком случае выигрыша в общей скорости скорее всего не будет (хоть и замедления, думаю, тоже не будет). И ещё: есть разные СУБД. И перед переходом их тоже стоит сравнить применительно к конкретной задаче. Может, лучше подойдёт postgresql, а может — mysql, или вообще sqlite либо даже dbm.

Читаем read, потом сами парсим.

Но куда проще сразу использовать фортрановское форматированное чтение.

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

Хорошо и быстро напишешь - возьму в команду на оклад.

тыц

Встречаются, но мартышкам это не поможет. Сначала попробуйте написать что-то получше scipy.optimize хотя бы, чтобы было быстрее, удобнее, точнее и т.д. Боюсь, что не выйдет. А ещё нужно это поддерживать в актуальном состоянии.

Думаю, что имеет смысл потестировать, как с такой задачей справится СУБД

Нет, нет и ещё раз нет. Хотя бы просто потому, что это неудобно + нужно дополнительно тестировать часть с доступом к БД... На самом деле просто никто в своём уме не будет тратить на это своё время. Опять же, есть формат ROOT-деревьев и там такие операции производятся на уровне индексов, но (!) не всем и не всегда это нужно.

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

Самокритичный студент - это, на самом деле, уже неплохо. Сейчас таких мало, каждый думает, что он-то всё знает лучше всяких там старпёров и как придёт сейчас со своим ручным питоном да как всё напишет...

Заголовок события: (1X,F9.4, 3(1X,I15))
Тело (350-2000 строк): (1x,7(1XF9.4),1XI3,1XE12.4)

У меня вопрос к вменяемым фортранщикам в этой теме. Правильно ли я понимаю, что описанный таким образом заголовок — это, по сути:

<space><float><space><int><space><int><space><int>

и не более того? Без всяких круглых скобок и запятых во входном потоке?

обеспечивать воспроизводимость результатов где бы вы их не обсчитывали.

dbm существует со времён первых unix-систем и скорее всего по умолчанию уже включена в linux, а если нет, то устанавливается в любой unix и linux из стандартных реп. Для windows тоже имеется порт. Так что с универсальностью тут проблем нет. С обкаткой тоже: с 79 года, слава богу, всё уже обкатано по максимуму. Единственно, это не совсем полноценная СУБД и имеет ряд ограничений.

Посмотрел я сюда: https://mariadb.org/fortran-and-mariadb/
И нет, здесь все эти сложности с БД не нужны.