LINUX.ORG.RU

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

 , ,


3

4

2-го декабря 2018-го года Международная Организация по Стандартизации (ISO) опубликовала ISO/IEC 1539:2018, ранее известный под названием Fortran 2015.

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

  • Введён новый тип CFI_cdesc_t, содержащий информацию о типе элементов, ранге, размере передаваемого массива и способе выделения его памяти. Ранее на сторону программы, написанной на языке C, вместо массивов чисел можно было передать только «голые» указатели, и о соблюдении границ массивов приходилось заботиться вручную.
  • Введено понятие команды (team), позволяющее разделить выполняющуюся на кластере программу на несколько сравнительно независимых подмножеств процессов.
  • Появилась возможность обработки ошибок отдельных процессов кластера (fail image и аргумент stat= вызовов change team, end team, event post, form team, sync all, sync images, sync team).
  • Добавлены атомарные операции над переменными (atomic_add, atomic_and, atomic_or, atomic_xor, atomic_fetch_add, atomic_fetch_and, atomic_fetch_or, atomic_fetch_xor, atomic_cas).
  • Улучшена совместимость со стандартом ISO/IEC/IEEE 60559:2011 для чисел с плавающей запятой.

Следующая версия стандарта временно называется Fortran 202x.

Новые возможности Fortran 2018

Бесплатно доступный черновик стандарта

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от jamy

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

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

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

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

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

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

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

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

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

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

hdf5

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

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

skvitek ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

skvitek ()
Последнее исправление: skvitek (всего исправлений: 1)
Ответ на: комментарий от skvitek

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

skvitek ()
Последнее исправление: skvitek (всего исправлений: 2)
Ответ на: комментарий от dave

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aureliano15 ()
Последнее исправление: aureliano15 (всего исправлений: 1)
Ответ на: комментарий от dave

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aureliano15 ()