Fortran *

Продолжая исследовать проблему точности десятичных вычислений средствами двоичной арифметики, начатую в предыдущих постах [1,2,3,4], мне удалось разработать алгоритмы вычисления вещественных чисел, представленных в формате десятичных чисел с плавающей точкой, которые дают такой же точный результат, как если бы вычисления велись вручную.

Это история о том, как мы c mildly_parallel замедляли ускоряли расчеты на самом мощном суперкомпьютере в мире.

Фильтр анизотропной диффузии Перона и Малика — это сглаживающий цифровые изображения фильтр, ключевая особенность которого состоит в том, что при сглаживании он сохраняет и «усиливает» границы областей на изображении.

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


Крайнее левое изображение — оригинальное, справа от оригинального — фильтрованные с различными параметрами.

Как говорилось во всеми нами любимом фильме: «Налетай, торопись, покупай живопись». Последняя, конечно, тут ни при чем, а вот «налетать» на новую Бета версию компилятора уже пора. Сегодня я расскажу о том, что нового появилось в пакете Intel Parallel Studio XE 2018 Beta, и в частности, в компиляторной её составляющей. А там действительно много что добавилось, ведь стандарты не стоят на месте — C++14, C++17, Fortran 2008, 2015, OpenMP 4.5 и 5.0, а компилятор должен не только их поддерживать, но и генерировать совершенный, производительный и безопасный код. Кроме этого, новые наборы инструкций AVX512, позволяющие «снимать сливки» с последних процессоров Skylake и KNL, всё больше входят в арсенал современных компиляторов. Но а самое вкусное — новые ключи, которые позволяют получить ещё больше производительности «не напрягаясь». Итак, поехали!

Большое количество научных исследований используют код, написанный на языке Фортран. И, к великому сожалению, «научные» приложения тоже не застрахованы от банальных ошибок, таких как неинициализированные переменные. Стоит ли говорить, к чему могут приводить подобные вычисления? Иногда эффект от таких ошибок может довести до «серьёзных прорывов» в науке, или стать причиной действительно больших проблем – кто знает где полученные результаты могут быть использованы (но, мы догадываемся где)? Хотелось бы привести ряд простых и эффективных методов, которые позволят проверить существующий код на Фортране с помощью компилятора Intel и избежать подобных неприятностей.

Это статья про многомерные массивы. А ещё про ключевое слово restrict, до появления которого в C язык Fortran был быстрее C. Немного про то, зачем я это написал, см. в конце.

Многомерные массивы. Начну с многомерных массивов. Допустим, вам нужно максимально эффективно работать с большими квадратными матрицами в C++ (скажем, умножать их друг на друга). Причём размер матриц становится известен лишь в runtime. Что делать?

Всякие double a[n][n] и std::array<std::array<double, n>, n> не сработают, т. к. порядок матрицы (n) будет известен лишь в runtime. new double[n][n] не сработает по этой же причине (лишь первое измерение массива, создаваемого new, может быть runtime-выражением). Попробуем так:

double **a = new double *[n]; // Массив длины n указателей на double
for (int i = 0; i != n; ++i)
  {
    a[i] = new double[n];
  }

В 2017 году языку Fortran исполняется 60 лет. За это время язык несколько раз дорабатывался. «Современными» версиями считаются Fortran 90, 95, 2003 и 2008. Если изначально это был язык программирования высокого уровня с чисто структурной парадигмой, то в более поздних версиях появились средства поддержки ООП и параллельного программирования. На сегодняшний день Fortran реализован для большинства платформ.

До появления языка Fortran разработчики программировали, используя машинный код и ассемблер. Язык высокого уровня быстро набрал популярность, так как был прост в изучении и обеспечивал генерацию эффективного исполняемого кода. Это существенно упростило жизнь программистам.

Какой язык использовали для написания самых первых программ для самых первых компьютеров с хранимой программой?

Двоичный машинный язык, конечно.

Почему?

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

Насколько легче писать программы на ассемблере, чем на двоичном машинном языке?

Намного легче.

Можно цифру? Во сколько раз легче?

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

Экономия объёмов работы огромная.

Эта статья представляет собой формализованный ответ на публикацию на форуме IDZ. Проблема, которую описывал автор исходной публикации, заключалась в том, что производительность работы кода не увеличивалась в достаточной степени при использовании OpenMP на 8-ядерном процессоре E5-2650 V2 с 16 аппаратными потоками. Потребовалось некоторое время на форуме, чтобы помочь автору публикации и предоставить ему необходимые подсказки, однако времени для оптимизации кода было недостаточно. В этой статье описываются дальнейшие методики оптимизации в дополнение к описанным на форуме IDZ.

Как вы уже знаете, недавно вышла новая Intel Parallel Studio XE 2016, а с ней, как и полагается, новые версии всех тулов, в том числе, и Фортрановского компилятора. Он всё ещё «жив курилка», активно развивается, при это весьма востребован и используется множеством разработчиком, особенно в HPC и академической среде. Новая версия, как всегда, делает жизнь этих разработчиков чуточку легче, поддерживая новые стандарты и давая больше возможностей. Давайте посмотрим, что появилось в версии 16.0.

Среди большого количества цикловых оптимизаций, одной из наиболее эффективных является техника разделения цикла на блоки (loop blocking). Суть её заключается в изменении итерационного пространства с целью более оптимальной работы с памятью, то есть уменьшения промахов кэша. Для этих целей в последней версии компилятора появилась специальная директива, позволяющая контролировать эту оптимизацию. Но обо всём по порядку.

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

Сегодня мы поговорим о выравнивании данных, его влиянии на производительность и векторизацию и работу с ним в компиляторе, в частности. Очень подробно само понятие дается в этой статье, как и множество других нюансов. Но нас интересует влияние выравнивания при векторизации. Так вот, если вы прочитали статью или просто знаете, как происходит работа с памятью, то известие о том, что данные считываются блоками вас не удивит.

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

Что такое воспроизводимость? Да всё просто – мы хотим получать одну и ту же «хорошую цифирь» от запуска к запуску, потому что для нас это важно. Это критично во многих областях, где сейчас активно используются параллельные вычисления.

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

На языке Фортран написано огромное количество кода, отлаженного и работающего многие годы. Я не собираюсь поднимать вопрос «что лучше — Фортран или С?». У каждого языка есть свои сильные и слабые стороны. Но, учитывая большое распространение языка С, всё более популярными в определенных кругах становятся случаи «гибридных» приложений, когда часть кода пишется (скорее, уже написана) на языке Фортран, а другая – на С. Вот только у этих языков есть определенная специфика, про которую я частично уже говорил, и чтобы написанное нами приложение работало корректно, нужно учитывать много нюансов. Различия в типах данных, соглашениях о вызове (calling convention), именах (naming convention) делают задачу создания mixed language приложения далеко нетривиальной. Хорошо, что в стандарте Fortran 2003 появился целый набор средств, специально разработанный для решения задачи интероперабельности C и Фортрана. Кстати, не помню других языков, которые бы стандартизировали подобную работу — ещё один «плюсик» Фортрану за протянутую «руку дружбы».

Многие из нас, обучаясь программированию ещё в университетах или дома, делали это на языках С/С++. Конечно, всё зависит от времени, в которое начиналось наше знакомство с языками программирования. Скажем, кто-то начинал с Фортрана, другие — с Basic’a или Delphi, но стоит признать, что доля начавших свой тернистый путь программиста с С/С++ наибольшая. К чему я всё это? Когда перед нами стоит задача изучить новый язык и написать на нём код, мы часто основываемся на том, как бы я это написал на своём «базовом» языке. Сузим вопрос — если нужно написать что-то на Фортране, то мы вспоминаем, как бы это было реализовано на С и делаем по аналогии. Очередной раз столкнувшись с тонкостью языка, которая привела к абсолютно неработающему алгоритму и большой проблеме, эскалированной мне, я решил отыскать как можно больше нюансов языка Фортран (Fortran 90/95), по сравнению с С, с которыми столкнулся лично. Это своего рода «нежданчики», которые ты явно не планировал увидеть, а они бац – и всплыли!
Конечно, речь не пойдёт о синтаксисе — в каждом языке он свой. Я попробую рассказать о глобальных вещах, способных изменить всё «с ног на голову». Поехали!

Эта публикация для тех, кто вынужден по долгу службы пользоваться pgcpp компилятором или поддерживать совместимость кода с этим компилятором.

На днях я получил баг репорт, что мой код неправильно работает, если его скомпилировать при помощи pgcpp.

Начав разбираться, я нашел место, где происходит ошибка. Оказалось, что если код компилируется с O2 или O3 оптимизацией, то std::sort может начать дублировать часть вектора и заменять этими дубликатами другие части.

Вот простой C++ код, который поможет воссоздать это ужасное поведение (обратите внимание на число 3193 в выводе):

Когда-то давно я решил «потрогать» Fortran. Единственную задачу которую я придумал — генерация фракталов (заодно и OpenMP в Fortran'е можно было бы попробовать). В процессе написания я часто сталкивался с проблемами, решение которых приходилось додумывать самому (например в интернете не так много примеров использования чисел двойной точности или бинарной записи в файл). Но рано или поздно все проблемы решились, и я хочу написать этот текст, который возможно кому-нибудь поможет.

Писать я буду на диалекте Fortran 90, но с GNU расширениями (те же числа двойной точности).

Очень давно хотел написать о том, на какой стадии сейчас находится один из «прародителей» популярных сегодня языков программирования. Да, я говорю о Фортране. Попытаюсь разрушить стереотип, который существует в умах многих разработчиков – что Фортран древний язык без каких либо перспектив, и уж точно никто на нём уже не пишет. Наоборот, он очень активно эволюционирует и уже давно предлагает богатый набор различных функциональностей, закреплённых в стандартах, вполне, кстати, сопоставимых с тем же С/С++.
От «старого» 77-го Фортрана осталось уже не так и много… в 95 стандарте мы могли вполне себе создавать свои типы данных, динамически выделять и очищать память, работать с указателями, перегружать функции и операторы и много чего ещё. По сути, от С своим набором средств он отличается несильно. Тем не менее, я не хочу пытаться сравнивать языки – это вопрос философии. Скажу только, что фортрановский компилятор Intel пользуется очень большим спросом, и, собственно, приобретается даже активнее, чем тот же С++.
Цель же данного поста – рассказать о текущем состоянии дел. Собственно, Фортран на сегодняшний день — параллельный язык, и стал он таковым после принятия стандарта Fortran 2008, в котором появились Coarray’и.

Попробовать написать здесь свой первый пост меня подтолкнула статья о выборе первого языка программирования, где vt4a2h предлагает использовать для обучения C++. Да, на данную тему было сломано множество копий.

Я, как и наверное большинство школьников на просторах нашей необъятной Родины, начинал постигать азы через синий экран, но не смерти, а Turbo Pascal 7.0. Был конечно и Basic, с котором я впервые столкнулся в дошкольном возрасте на советском компьютере «Электроника». Тогда он казался странным текстовым редактором, ведь компьютер глазами ребенка создан для игр. Однако уже в институте я познакомился с языком Fortran, познав который, я до сих пор недоумеваю, почему он не используется для обучения.

Да, многие скажут, что язык мертвый, не соответствует современным реалиям, а учебники с названием, как на картинке, вызывают лишь улыбку. Я попробую объяснить, чем же так замечателен этот язык и почему я его рекомендую в качестве первого языка. Если заинтересовало, добро пожаловать под кат.

Как известно, в мире миллионы и миллионы строк легаси-кода. Первое место в легаси, разумеется, принадлежит Коболу, но и на долю Фортрана досталось немало. Причём, в основном, вычислительных модулей.

Не так давно мне принесли небольшую программку (менее 1000 строк, более четверти — комментарии и пустые строки) с задачей «сделать что-нибудь красивое, например, графики и интерфейс». Хоть программа и небольшая, а переделывать её не хотелось — дядька её ещё два месяца будет старательно обкатывать и вносить коррективы.

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