Навіщо у 2021 році вчити Fortran

Привіт, Я Саша Каленюк, працюю в компанії Materialise. Разом з командою алгоритмістів у Києві створюємо алгоритми для роботи із 3D-зображеннями, геометричними моделями, а також для підготовки моделей до друку тощо.

Сьогодні хочу розказати про явище, яке обговорюють здебільшого у вузьких колах. Можливо, ви про це чули, але не сприймали серйозно. Про відродження, або, як зараз модно казати, ренесанс Fortran.

Про це буде цікаво почитати тим, хто вважає, що High Performance Computing — це про статичний поліморфізм. Тим, хто думає, що С++ конкурує лише з C# і Java. Тим, хто впевнений, що історія починається з Altair 8800, а все що було раніше — перший дубль, незграбний і нецікавий нікому, крім купки істориків з археологами.

Це буде точно корисно почитати тому, хто навіть не уявляє собі, що одна і та ж історія може починатися двічі.

До ренесансу

Дуже-дуже давно, ще у 2017 році, NASA оголосило програмістський конкурс. Умови були прості: програміст подає заявку, NASA дає доступ до свого коду, фахівець його оптимізує, а хто зробив це найкраще — той і переможець. Просто? Еге ж.

Але є кілька нюансів. По-перше, оскільки агентство все ж американське і фінансується з американських податків, доступ до коду воно може надавати тільки американським громадянам. По-друге, код, який їм хотілося б оптимізувати — це чисельний розв’язок рівнянь Нав’є — Стокса. Це та математика, що стоїть за симуляцією повітряних потоків, така собі аеродинамічна труба у суперкомп’ютері. По-третє, код цей написаний на Fortran.

Коли про цей конкурс дізналися на Reddit, багато хто подумав, що це жарт. Хто ж пише на Fortran у 2017 році? Та ще й усілякі чисельні методи. Ну, в самій NASA може хтось і пише, але на волі? У відкритому плаванні? Навіщо?

Вважали, що конкурс приречений, що в усіх Штатах не знайдеться і кількох учасників, аби змагання набуло сенсу. І справді його зрештою скасували. Але не через брак учасників, а навпаки — через те, що кандидатів подалося забагато. Майже дві тисячі програмістів надіслали свої заявки, і агентство здалося. В NASA просто не встигли б надати всім охочим доступ згідно зі своєю стандартною процедурою. Бюрократія і в Штатах бюрократія.

Суперкомп’ютер Pleiades, Marco Librero, NASA Ames Research Center, Public domain, via Wikimedia Commons. Джерело

Але це ще не все. Насправді це ще навіть не початок.

Ренесанс

У 2018-му для Fortran затвердили новий стандарт: ISO/IEC 1539-1:2018. У 2019 році розпочали роботу над новою стандартною бібліотекою. Тоді ж додали пакетний менеджер. 2020-го запустили вебсайт і провели конференцію FortranCon 2020. Нарешті у 2021 році Google заніс Fortran до переліку офіційних мов Google Summer of Code. Якщо це не визнання, то що тоді?

То що ж коїться? Як так сталося, що Fortran, про який вже всі встигли забути, раптом прокинувся, розпихав багатоперспективну молодь, обігнав Rust, D, Julia, Dart і Haskell та заскочив у двадцятку найпопулярніших мов за версією TIOBE?

А сталося те, що поки всі інші мови застрягли у дев’яностих роках і наввипередки розв’язують проблеми дев’яностих років, Fortran ніколи не вибирався з шістдесятих. Він не був популярним в епоху десктопу, і всю ту цукрову вату, які сучасні програмісти вважають за необхідне: святу трійцю наслідування-інкапсуляції-поліморфізм, патерн-матчинг, варіантні типи, контрваріантні конструктори і, прости, Господи, варіадичні шаблони — він просто пропустив повз.

Але чому дев’яності — такий небезпечний час, щоб у ньому залишатися? Та тому, що домінантною платформою тоі був звичайний одноядерний персональний комп’ютер. Один процесор, один тип пам’яті, один модем, якщо пощастить, навіть монітор — і той один.

У шістдесятих все було не так. Усі варті уваги обчислення виконувалися на суперкомп’ютерах — багатоплатних, багатопроцесорних, які ще й часто працювали в кластері. Ну не було тоді таких потужних процесорів, які б самотужки розв’язували рівняння Нав’є — Стокса. Доводилось викручуватись.

Тепер такі процесори є, але незаперечна річ: два процесори працюватимуть швидше за один. Понад те, тисячі спеціалізованих процесорів на одній платі працюватимуть ще швидше. Власне, сучасні обчислювальні системи з таких плат і будують.

Технологічний ландшафт

GPGPU, або графічні обчислювальні пристрої загального призначення, — це концепт, з яким NVIDIA вийшла на ринок 2006 року. За два роки NVIDIA з’їла свого єдиного на той час конкурента з позаграфічної сфери Ageia. Ageia спеціалізувалася на PPU — фізичних обчислювальних пристроях, тобто спеціалізованих процесорах для фізичної симуляції, за що і поплатилася.

Акселератор на базі PPU Ageia. Mohawkade, Public domain, via Wikimedia Commons. Джерело

У NVIDIA чудово розуміють, що майбутнє не за універсальними однопроцесорними системами. Закон Мура напоровся на фізичні закони: довжину хвилі, розсіювання тепла, розмір атома. Не можна просто брати й додавати в один процесор все більше й більше транзисторів. А от процесорів на плату — можна. Хоча для цього їх доведеться дещо спростити, а значить спеціалізувати.

Отже, сьогодні найбільше біткоїнів майниться не на процесорах для персоналок, а на графічних картках. Хоча які вони вже графічні? GP переміг GPU. І чи могло бути інакше?

Усі ці роки NVIDIA розвивала не графічні картки. А спеціалізовані пристрої для гетерогенного програмування. Але продавала картки. Бо без підживлення з власного головного бізнесу їх, як і Ageia свого часу, теж хтось би давно викупив і знищив. І ми всі з вами здогадуємось, хто саме.

У 2016 році Google, який так нічого вартого і не викупив, випустив свою власну спеціалізовану багатопроцесорну плату TPU — тензорний обчислювальний пристрій. Дуже спеціалізований. Дуже швидкий. Все, що він вміє робити, — це тензорні обчислення. Простіше кажучи, множити матриці, щоб вираховувати вагу для нейросіток. Це такий високоспеціалізований акселератор для штучного інтелекту.

Google TPU версії 3.0. Zinskauf, CC BY-SA 4.0, via Wikimedia Commons. Джерело

NVIDIA вирішала не відставати й 2020 року вивела на ринок своє нове дітище DPU — обчислювальний пристрій для обробки даних. Теж швидкий, теж спеціалізований. Матриці рахувати можна і на GPGPU, а от байти ганяти — ні. Для цього є спеціальний продукт. Навіть у Google такого немає.

Але гонитва технологій — це одна з тих ігор, де завжди переможе той, хто перший принесе штопор. У 2021 році маловідома компанія Lightmatter з Массачусетсу вже випускає на ринок фотонний акселератор для того ж самого штучного інтелекту.

Фотонний комп’ютер не упирається в закон Мура, він живе за власним законом — фотонним. Хіба що впирається в неспроможність робити бранчинг. Обчислювати може, а от запускати програми в класичному сенсі з «іфами» і «форами» уже ні. Що було б гігантською проблемою для декстопу, але не для гетерогенної системи. Не може в програму? Гаразд. Програмою буде займатися транзисторний комп’ютер, а фотонний буде тупо множити матриці. Тупо, але в сто разів швидше, наприклад, за TPU від Google або GPGPU від NVIDIA.

Що далі

Отже, повернемось до Fortran. Поки інші мови виплачували архітектурні борги дев’яностих, Fortran лишився тим, чим він завжди був — простим компілятором для швидких обчислень. Паралельних, конкурентних і гетерогенних. Простота означає, що для кожної нової архітектури, чи то GPU, TPU, чи то фотонний акселератор, компілятор може бути портований одним з перших. «Паралельних» означає, що він готовий для масивного паралелізму спеціалізованих комп’ютерів, «конкурентних» — що він готовий перескочити з кластерів 60-х у клауд 2020-х, а «гетерогенних» — ну, це радше наслідок простоти.

Fortran не прив’язаний до жодних сучасних архітектурних рішень. Він проспав унікодні війни, домінування Intel з його 2n суперскалярами. Якщо якийсь спеціалізований процесор має 7-бітні слова і 49-бітні числа з плаваючою точкою, бо так виходить дешевше і швидше, Fortran може з цим працювати. С++ вже ні. Rust чи навіть Julia теж.

До речі, Fortran — одна з трьох мов, яку CUDA (GPGPU фреймворк від NVIDIA) підтримує «з коробки». Решта — це С і С++. Якщо це не визнання, то що тоді?

Отже, популярність С і С++ невпевнено спадає, а Fortran навпаки — зростає несподіваними темпами. Чи може він у недалекому майбутньому витиснути з гетерогенного, а значить і мейнстримного програмування всіх конкурентів? Чи може знову, як колись, стати мовою № 1, беззаперечним лідером у науковому та інженерному програмуванні?

Може. Якщо його не зупинить Python. Але це герой зовсім іншого епосу.

👍НравитсяПонравилось42
В избранноеВ избранном8
LinkedIn

Лучшие комментарии пропустить

В случае если кого то заинтересует изучение этого замечательного языка, то могу предложить цикл видеолекций на моем канале (как говорится полностью бесплатно и постоянно обновляется). Ссылка на первую лекцию — youtu.be/I4aSHLS0pIA. Прошу простить за элемент саморекламы.

Доу образовательный. Хорошая интересная статья. Спасибо!

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

www.cnews.ru/...​j_yazyk_programmirovaniya

За 18 лет существования рейтинга Fortran поднимался в нем максимум до 10 места. Этот личный рекорд он поставил в марте 2002 г., 19 лет назад, после чего его популярность стала падать. В 2005 г. был зафиксирован кратковременный рост интереса к нему, но затем вплоть до 2015 г. он держался примерно на одном уровне. С 2015 по 2017 гг. популярность Fortran вновь подскочила и затем снова рухнула. Не исключено, что новый рывок этого языка окажется началом следующего длительного периода роста его востребованности.

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

Несмотря на свой почтенный возраст, Fortran по-прежнему востребован в ряде сфер, включая инженерные вычисления. Его разработка продолжается, и на момент публикации материала самой актуальной его версией была Fortran 2018 (ISO/IEC 1539-1:2018), вышедшая в конце ноября 2018 г.

В общем посмотрим, к чему приведет данный всплеск популярности фортрана по версии TIOBE. :-)
Язык же все-таки нишевый (ИМХО).

Чисельні методи треба вчити. І принципи роботи заліза на низькому рівні.

Fortran (власне мова) вчиться за пару днів, і майже ніколи не є проблемою.
Проблема завжди в тому, що на ньому пишуть. Алгоритми точних обчислень.

В практичному сенсі Fortran це асемблер без жорсткої прив’язки до архітектури.

Я писал первую курсовую на фортране, т.к. учился на отделении астрофизики, то очень много астрономического софта по традиции было написано и продолжало писаться на фортране, помню, что мне он понравился.. К старшим курсам перешел на С++ и дипломную работу писал на нем. А на галеру устроился на С#.

Деградація?) Fortran -> C++ -> C#

Таки декілька зауважень.

> і всю ту цукрову вату, які сучасні програмісти вважають за необхідне: святу трійцю наслідування-інкапсуляції-поліморфізм, патерн-матчинг, варіантні типи, контрваріантні конструктори і, прости, Господи, варіадичні шаблони — він просто пропустив повз.

Деякі елементи, аж до наслідування, в Фортрані є. І поліморфізм (статичний) є: наприклад, для усяких max() вибирається реалізація згідно типа аргументу. Але, так, висоти ООП в ньому не намагались брати.

В 60-х на ньому намагались писати все. Навіть обробку текстів. Я бачив це — ну, жах, але не жах-жах ©. Працює, але за сучасними мірками супроводжувати таке тяжкувато. Тому задачі такого роду ушли від нього і не повертались.
А ще його значно підбили проблеми синтаксису. Сучасний freeform це вже пізне досягнення (82/90).
В результаті, залишилась мова, якою краще всього писати тільки математику.

> У шістдесятих все було не так. Усі варті уваги обчислення виконувалися на суперкомп’ютерах — багатоплатних, багатопроцесорних, які ще й часто працювали в кластері. Ну не було тоді таких потужних процесорів, які б самотужки розв’язували рівняння Нав’є — Стокса. Доводилось викручуватись.

Це перебільшення. Реальних кластерів тоді не було. Навіть двухпроцесорні системи були рідкими. Кластери пішли десь починаючи з робот Cray, а це вже 70-ті, друга половина, а в СРСР — з дуже спеціалізованих систем, в яких фактично були періферійні процесори для обчислень.

> GPGPU

А ось тут вже пішло цікаве. Справді, будь-яка програма, в якій фактично запис щось на зразок множення матриць не пишеться як цикл в циклі в циклі (хоча б і в підпрограмі), а задається напряму, може бути перекладений на MPI/OpenMP/GPGPU/etc. без допоміжної роботи по розпізнаванню, що це саме множення матриць. Аналогічно і з іншими операціями. Цінність Фортрану в том, що в ньому такі вказівки на рівні мови — навіть не бібліотеки, як було б для будь-якої іншої мови більш сучасного типу (C/C++/Java/etc.) => компілятор може сам вирішити, що робити, без допомоги.
(Хоча в 90-х придумали intrinsics в інших мовах, і таким чином дають інформацію, що саме діється і компілятор може це перехватити.)

> Fortran не прив’язаний до жодних сучасних архітектурних рішень.

> Якщо якийсь спеціалізований процесор має 7-бітні слова і 49-бітні числа з плаваючою точкою, бо так виходить дешевше і швидше, Fortran може з цим працювати. С++ вже ні. Rust чи навіть Julia теж.

А тут вже інший аспект. Ніхто реально з такою апаратурою працювати за межами якихось ну дуже спеціалізованих установок (для космосу, наприклад) не буде. Чому — а тому що IEEE754 вводився не тому, що хотілось покерувати, а тому, що без єдиного стандарту не було взагалі можливости порівняти і відтворити результати обчислень. І зараз середовище без нього просто приречене на забуття зі старту.
Не буде «49-бітні числа з плаваючою точкою», буде 32 і 64, з двійковою базою... коротше, дивіться в стандарт.

І ще одно — ви в стандарти дивились? Як це ні образливо, підтримка UCS-4 записана у сучасних стандартах (опціонально, але рекомендовано). А ще є там такі дивні вимоги, як:

> ICHAR (’ ’) < ICHAR (’0’) < ICHAR (’9’) < ICHAR (’A’) or ICHAR (’ ’) < ICHAR (’A’) < ICHAR (’Z’) < ICHAR (’0’).

ASCII і EBCDIC відповідають цьому. Довільне інше кодування — вже ні. Тобто, не все настільки вільне...

> До речі, Fortran — одна з трьох мов, яку CUDA (GPGPU фреймворк від NVIDIA) підтримує «з коробки». Решта — це С і С++. Якщо це не визнання, то що тоді?

Не дивно, що фреймворк чисельного використання підтримує мову для обробки чисел :)

> Отже, популярність С і С++ невпевнено спадає, а Fortran навпаки — зростає несподіваними темпами. Чи може він у недалекому майбутньому витиснути з гетерогенного, а значить і мейнстримного програмування всіх конкурентів?

Ні. Не може.
Тому що ~99% гетерогенного, конкурентного, паралельного програмування це не якісь операції з матрицями в міліард розміром, а роботи з гетерогеними _даними_. Від баз даних до веб-сайтів. І це ниша, де Fortran майже безсилий: написати на ньому можна, але він буде тут гірше C, Pascal, десятків інших схожих. Все вручну.
А ті 1% де він залишається — так, це HPC однорідного характеру. Тут ніхто його і не хоче помітно зсувати, бо не виправдається.

PS: Fortran був моєю першою мовою програмування. Ностальгія є, і слідкую. Але — дивлюсь в очі реальності.

Поки читав статтю, чомусь згадав sega dreamcast, де графічний чіп займався обробкою сигналів з геймпадів, а «центральний» процесор генерував флоати для графічного чіпа.

Це все цікаво, але ж Навіщо у 2021 році вчити Fortran?

@Олексій: якраз у п’ятницю розмовляв із теор фізиком, який кодить на Фортрані, він казав, що наразі високопродуктивні обчислення або на С або на Фортран. Такий тренд, і не в академічному, а в бізнес середовищі.

Цікаво, чи читав цю статтю хтось з JS кодерів

Им некогда — они работают как шахтеры в рудниках. Куда там до белой кости — которые правят строку легаси когда после месячных дебатов.

А шо так можно? о_О

Конечно. Иногда тебе аккаунт в гит тупо могут пол-года выдавать.

ось він, я.
так, читав. так, зрозумів більшість термінів.
статистику збираєте?

А що, сьогодні є не JS кодери?)

Я дуже переживаю, що пройде небагато часу і JS почнуть використовувати в медичній галузі чи атомній енергетиці і не тільки для інтерфейсів

Справедливості ради — гавнокод можна і на інших мовах написати. Ракети/літаки падали не через код на JS :)

Фортран стал бессмысленен сразу с появлением С. И тогда же благополучно умер.

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

Учтем твое мнение, братишка с самым длинным отпуском!

Вижу у тебя благоговение перед инфантильными бомжами из ЦЕРНа — бесполезно протиратающими свои штаны, за нищенские крохи с грантов.

Рекомендую уйти в отпуск и привести голову в порядок. :)

P.S. Фортран умер? Умер.
И в чём я неправ?

Не трогай труп!

И у Маска работают бомжи за жалкие 120К, и Меркель бомжиха, в руководстве четвертой экономикой мира около 250К получала. И Байден бомж, тоже примерно столько же получает, руководя первой экономикой мира. Одни только украинские программисты у нас самые умные и не-бомжи, элита йопта.

Меркель с Байденом — ни дня не работавшие паразиты на госбабле, угробившие экономики своих стран.

А Маск тут к чему? Он тоже из бесполезных госбюджетных протирателей штанов (т.н. «учёных») или не Фортране пишет?

У Байдена сын чОткий- мутит без помощи родаков в странах третьего мира и помогает папке финансово.

Як ви погано відзивається про військових, які втратили життя

Чи ви купились на той вкид від рфінців про іншого сина?

Хантер Баден , бурисма и это вот все

Тобто повелись на цю рфіянську липу яку презентувало тіло дубінського?

omfg

Фортран стал бессмысленен сразу с появлением С.

Уж сколько раз его отменяли... :))

И тогда же благополучно умер.

В математике вполне живой. И имеет ряд мелких, но существенных преимуществ. Хотя куча моментов в нём топорны, безусловно.

В математике вполне живой.

В математике... Это же тупые протиратели штанов (т.н. «учёные»), неспособные выучить элементарный C. Оттого и полужив ещё, лишь там.

У этих тупых даже пайтон (тормознутый пайтон!!!) пользуется для написания мат-моделей и прочих распознаваний образов/нейронных сетей. На фоне пайтона да, фортран должен даже рулить. :)

В математике... Это же тупые протиратели штанов (т.н. «учёные»), неспособные выучить элементарный C. Оттого и полужив ещё, лишь там.

Это вам так кажется, что C «элементарный». А на самом деле, например, концепция указателя — это то, чему нужно умно учить. Или же просто случайность играет и одним могут дать, а другим нет. Когда-то Joel Spolsky даже писал, что одним дано, а другим нет, и это разница в структуре мозга:) Я не согласен, но вижу, что одним таки комфортно думать о таких вещах, а другим нет.

С другой стороны, они способны решить сложнейшую теорему и изобрести новую концепцию в математике, а вы — нет. И вопрос ещё, кого считать «тупым протирателем штанов» — учёного, который хотя бы сделал микрошаг в разборе какой-то топологической проблемы, или хама типа вас. (Или меня, который неплохой инженер, без излишней скромности, но вот изобрести какой-нибудь SSA и довести его до рабочего состояния, ещё и доказав корректность, меня бы точно не хватило. Да даже простые AVL-деревья я бы не придумал, работая на технике 50-х.)

Фортран хорош тем, что про указатели там просто не нужно думать. (Ну или думать по минимуму.) Любой DSL ценен не столько тем, сколько он нового даёт, а тем, что он ограничивает, что не даёт делать. Язык, который не даёт расстреливать память, в этом плане ценнее того, где малейшая ошибка приводит к порче стека, кучи, чужих данных и так далее.

У этих тупых даже пайтон (тормознутый пайтон!!!) пользуется для написания мат-моделей и прочих распознаваний образов/нейронных сетей.

Вы написали обобщение «космического масштаба и космической же глупости» ©.
Python используется как безопасная запускалка всяких numpy/scipy/etc, не более того. Повторюсь: он не даёт скрыто портить данные. В этом его основная ценность. А 99.9% всей реальной работы выполняется в хорошо оптимизированном компилированном коде.
А вот дальше — показываю фокус: берём стандартную себе Ubuntu 20.04 и scipy из базовой поставки. И что мы видим?

$ find . -name ’*.so’ | grep blas
./linalg/_fblas.cpython-38-x86_64-linux-gnu.so

SciPy опирается на BLAS, написанный... на фортране. Заглянув, видны характерные следы в виде названий, структуры кода и т.п. Исходники свободны, можно тоже изучать (попробуйте, может, поможет).
А почему? А потому, что «работает — не трожь». Код вылизан десятилетиями на основании тысяч человеко-лет опыта типа «вот такие вот уравнения лучше всего решаются верхним методом Зейделя».
Итого, в этом режиме от C только клеевой слой (Python->C->Fortran и Fortran->libc).

На фоне пайтона да, фортран должен даже рулить. :)

Продолжайте показывать свою глупость, только добавите в копилку (где уже много).

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

Считать «тупым протирателем штанов» т.н. «учёного», разумеется. Т.к. 90% из них — бесполезный баласт, годный лишь на генерацию никому не нужных статей. И 100% из них — содержится за баблос налогоплательщиков (т.е. мой и твой, в том числе).

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

Т.е. паразиты «учёные» не просто бесполезны, а вредны.

Т.е. паразиты «учёные» не просто бесполезны, а вредны.

Если ты немедленно сейчас не выключишь комп и весь свет в доме и не пойдёшь копать землю максимум на лошади — паразит и лицемер тут конкретно ты.
Жду ответа (твёрдого обещания перед выключением).

Как то, использование пайтона для высокопроизводительных моделирований, рассказам о хорошести социализма-коммуняцтва, шариковщине уровня «отнять и поделить»

Глупость продолжается. Что ж, ожидаемо.

Python используется как безопасная запускалка всяких numpy/scipy/etc, не более того.

Безопасная запускалка, вполне себе опасного кода, написанного на C. Прекрасная безопасность. :)

Если бы ты меньше сабатиковал, а больше ходил на профильные конференции в Киеве по функциональному программированию, или хотя бы следил за темами докладов, ты был бы вкурсе, что группировка Киев Лямбда приглашала Вадима Заливу, доктора CMU, который рассказывал как для системы SPIRAL с помощью системы доказательства теорем Coq доказывалась не только корректность векторизированного ассемблерного кода под все платформы для алгоритмов линейной алгебры, но и их максимальную эффективность (загрузку по всем конвеерам). Этот код и есть грааль верифицированной линейной алгебры, который входит в интринсинки фортрана. Именно поэтому все считается на фортрановском BLAS, и в CERN, и в Tesla, и в NASA. А это базовые знания рынка, ты уже даже на собеседование считай не попал со своим видением мира.

профильные конференции в Киеве по функциональному программированию

 А можно подробнее?

А это базовые знания рынка, ты уже даже на собеседование считай не попал со своим видением мира.

Перестань писать херню, о каком-то узкоспециализированном решении, как «базовом знании».

Да и то, которое скорее всего, является лишь «одним из». Bозможно и не самым эффективным на рынке (несмотря на маркетиноговый трёп чела, которого ты послушал на конференции в стране 3-го мира).

Именно поэтому все считается на фортрановском BLAS

„Basic Linear Algebra Subprograms (BLAS) is a specification
en.wikipedia.org/...​inear_Algebra_Subprograms

„They are the de facto standard low-level routines for linear algebra libraries; the routines have bindings for both C (‚CBLAS interface’) and Fortran (‚BLAS interface’).”

В общем, код написанный на ассемблере — с возможностями вызова как из Фортрана, так и из С.
И причём тут какой-то мифический „фортрановский BLAS”?

Похоже, ты провалил своё собеседование.:)

В общем, код написанный на ассемблере

О как.

И причём тут какой-то мифический «фортрановский BLAS»?

Хорошая была трава. Поделись поставщиком.
(Я вообще-то исходники читал)

Зачем кормить тролля? Циники уже наказаны тем, как им видится мир, им можно только посочувствовать.

С такими я разговариваю формально обращаясь к ним, но на самом деле — для прочей аудитории. Если так не получается — молчу. Кормить действительно смысла нет.

Все правильно, мы общаемся не с тролями, а друг с другом!

Циники уже наказаны тем, как им видится мир, им можно только посочувствовать.

Циники распродавали своё рашко-имущество сразу, после революции 1905 года. Переводили баблос в зарубежи и по окончании распродаж сваливали к баблосу сами.

Рассказать, что получилось с идеалистиками, 10-ю годами позже?

И кому тут посочувствовать?

Любой DSL ценен не столько тем, сколько он нового даёт, а тем, что он ограничивает, что не даёт делать. Язык, который не даёт расстреливать память, в этом плане ценнее того, где малейшая ошибка приводит к порче стека, кучи, чужих данных и так далее.

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

SciPy опирается на BLAS, написанный... на фортране. Заглянув, видны характерные следы в виде названий, структуры кода и т.п. Исходники свободны, можно тоже изучать
(попробуйте, может, поможет).

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

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

Да. Но сравнение в этой подветке было не с этими другими языками, а с C.

Но что это меняет в 21м веке. Модифицировать этот код и вносить новые баги никто не даст.

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

Фортран стал бессмысленен сразу с появлением С.

Ну, не совсем так. В Фортране есть вещи, которых нет в C. Например, комплексные числа как встроенный тип. Очень удобно, например, для радиофизических расчетов. Гораздо приятнее писать

x = a*b + c

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

x = cadd(cmult(a, b), c);

Ну, не совсем так. В Фортране есть вещи, которых нет в C. Например, комплексные числа как встроенный тип.

Сейчас (начиная с C99), к слову, комплексные числа есть. К реализации не обязательны, но много где такое таки сделано.
Но на момент порождения C их действительно не было.

Вопрос: где за это платят и сколько?

В Швейцарии в CERN, но ты туда никогда не попадёшь!

Зачем мне в страну, где я не буду получать как десять средних граждан?

А, прости, если для тебя то на атомных станциях в России платят норм, как раз будет в среднем выше чем 10 клининг менеджеров из Брянска. Там тоже есть FORTRAN, туда можешь ехать! Там вы полюбите друг друга на почве ГОСТ-ов из СССР. И украинский учить не надо будет. Удобно.

на атомных станциях в России платят норм

Подозреваю, что при переезде и в Брянск и в Церн моя покупательная способность уменьшится. Тут же вопрос не в том, сколько денег на руки, а что я могу купить на них. Так вот, на Украине ПОКА соотношение доходы/затраты наивысшее.

Ты просто настоящий сталкер выживания!

Кожаєв зараз почне кінджалами махати. Чи трубою металевою.

В мене є відео, де Кожаєв махає тренувальними резиновими ножами з якимись тренувальними мотузками в офісі Лінкс Кепітал. Виглядало приблизно як перша доповідь Олександра Соловйова: www.instagram.com/p/CUxMFPnh8IW

майстер ножового бою перекваліфікувався

Насправді дуже цікаво.
В мене ще десь лежать перфокарти ))

Пішов шукати пачку перфокарт з курсачем :).

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

Добрий день, наведіть будь ласка приклад формули, яку вдалось так обчислити і чи взагалі це можливо?

return C ? A : B;
return (C==0) *B + (1 — (C==0)) * A;

На некоторых компиляторах `(C==0)` приводит к брэнчингу, например:
godbolt.org/z/6xzP9K69v
..в связи с этим (C==0) тоже надо расписывать без брэнчинга, но направление мысли хорошее )

Вероятно потому что компиляторы не ограничены условием «без ветвления», и не все ISA имеют аналог x86 setz инструкции? По условиям задачи не имеем права использовать оператор ветвления мы, на high level language, руки оптимизирующего компилятора при этом развязаны.

В условии не сказано, что язык должен быть С, а архитектура x86. Но даже на «high level language» можно использовать настолько низкоуровневые операторы, что ни один респектабельный компилятор не добавит брэнчинг в машинный код.

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

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

// returns `a` if `condition == 0` or `b` otherwise
fn iif(condition: u64, a: u64, b: u64) -> u64 {
    // if `condition` not equal to 0, then either high bit of `condition` is set to 1
    // or high bit of `0-condition` is set to 1.
    //
    // sign_flag == 0 if condition == 0
    // sign_flag == 1 if condition != 0
    let condition_not_equal_to_0 = (condition | (0_u64.wrapping_sub(condition))) >> 63;

    println!("condition_not_equal_to_0 {:#b}", condition_not_equal_to_0);

    // 0 - 0 == 0
    // 0 - 1 == -1 == 0b_1111111111111111....111111111
    let b_mask = 0_u64.wrapping_sub(condition_not_equal_to_0);
    

    let a_mask = !b_mask;
    
    a & a_mask | b & b_mask 
}

К сожалению, не знаю Rust, но основная идея в том, что операторы сравнения и сложения — это по сути булевские функции. Надо это понимать и уметь их реализовывать на самом низком уровне.

Современный умный компилятор (типа clang) эти ваши формулы может перевернуть по своему настроению как угодно.
Он может C?A:B превратить в cmov или (на ARM) cset. А может и наоборот, добавить ветвление туда, где пишешь что-то вроде C*A + (1-C)*B при условии C ∈ (0,1).
Судя по тайтлу, вы всё это знаете, но для других я таки оставлю комментарий. Кстати, зачем вы выбрали msvc без оптимизации? Это же ужас. Хм, я даже не менял код и что получилось... :) А можно то же самое и компилятор не меняя получить, только /Ox добавить... :))
Инсайты дело важное, но пример должен быть устойчивым. Вон Горчак как-то рисовал задачки — мне кажется, они устойчивее к таким флуктуациям параметров компиляции.

Перший рядок — те саме «вєтвлєніє», вигляд збоку. Другий рядок — дотепно.

Перший рядок — псевдокод
Другий рядок — тривіальна трансформація

Але навіть псевдокод з першого рядка може as is бути скомпільований в трійку інструкцій
cmp C, 0
mov rax, A
setz rax, B
без «вєтвлєнія», просто це радше заслуга компілятора а не нас.

без «вєтвлєнія», просто це радше заслуга компілятора а не нас.

Ну вот интересно, что современный gcc даже с подсказками не смог упростить в такой вид, а древний clang — смог. Подсказки — в смысле !C*A + !!C*B, он всё равно превращает во что-то страшное с двумя imul. И unsigned не помог.
Зато он хорош в чём-то другом (в тестах есть масса примеров, где обгоняет clang).

Иногда это не просто «дотепно», но и быстрее. Была задача, когда избавление от брэнчинга приводило к 10% ускорению на CPU, что экономило дни на длинных вычислениях. А ещё брэнчинг убивает производительность шейдеров на GPU, поскольку вынужден считать все ветки вычислений и потом отбрасывать ненужную, поэтому этот трюк ускоряет вычисления шейдеров в разы.

та любая нейронная сеть по-факту.

Концептуально — да, самые практичные функции активации в нейронных сетях — это по сути «аналоговый if»

Гарна та цікава стаття!
Особливо тішить, шо стаття написана державною мовою.
Дякую за чудову роботу. Пишіть ще!

Доу образовательный. Хорошая интересная статья. Спасибо!

Якщо його не зупинить Python.

Лол

А так статья крутая.

А что насчет перспектив COBOL?

Познавательно получилось)

Сьогодні я став трохи ближчий до Фортрана:

❯ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure —prefix=/usr/local/Cellar/gcc/11.2.0 —libdir=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11 —disable-nls —enable-checking=release —enable-languages=c,c++,objc,obj-c++,fortran,d —program-suffix=-11 —with-gmp=/usr/local/opt/gmp —with-mpfr=/usr/local/opt/mpfr —with-mpc=/usr/local/opt/libmpc —with-isl=/usr/local/opt/isl —with-zstd=/usr/local/opt/zstd —with-pkgversion=’Homebrew GCC 11.2.0′ —with-bugurl=github.com/...​brew/homebrew-core/issues —enable-libphobos —build=x86_64-apple-darwin20 —with-system-zlib —disable-multilib —without-build-config —with-native-system-header-dir=/usr/include —with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0)

В случае если кого то заинтересует изучение этого замечательного языка, то могу предложить цикл видеолекций на моем канале (как говорится полностью бесплатно и постоянно обновляется). Ссылка на первую лекцию — youtu.be/I4aSHLS0pIA. Прошу простить за элемент саморекламы.

Ще в під час навчання в універі портував існуючий код на FORTRAN і BASIC на ObjectPascal (Delphi) і потім С++. У FORTRAN нема дуже багато того — до чого ви звикли у сучасних мовах програмування, навідь примітивних речей наприклад switch. Про reflection, aspects, mixines взагалі не йдеться. В цілому сенс FORTRAN у сучасних умовах — використати раніше розроблений код як то NASTRAN у нових розробках, не портуючи його на іньшу мову програмування. Тобто задля математики визивати функціі із DLL чи SO які сворені на FORTRAN, все іньше зробити на чомусь сучаснішому. Наприклад C++ із якоюсь бібліотекою як то wxWidgets, QT тощо, або — Java, C#, Node.

switch как раз есть:
select case ([expression])
case ([expression 1])
[block statements 1]
case ([expression 2])
[block statements 2]
...
case ([expression n])
[block statements n]
case default
[block statements default]
end select

С++ може бути занадто low-level. Java з прісними — повільними через свої віртуальні машини. Фортран насправді реально заточений під обчислювання, не дурно він FORmula TRANslation.
Свого часу, на початку 90-х я навіть мав справу з DSL який транслювався в фортран препроцессором написаним на фортрані. При всій незручності процессингу тексту на фортрані :).

Как раз на прошлой неделе я заинтересовался Фортраном и начал учить его на FutureLearn и по книжке Рыжикова, а оказывается вот оно как.

Ні-ні, тільки книжка під редакцією Є.Л.Ющенко. Тільки хардкор!

Подписаться на комментарии