OberonCore

Я вам дал пример, что дальше?

Только что прогнал Вашу программу на Julia и программу выше на A2. Результаты удручающие:

Julia:
1024: 2,1 с
2048: 8,6 с

Active Oberon:
1024: 33 с
2048: 4 мин. 30 с

Дальше проверять не стал — слишком долго ждать. Кто сколько ядер загружал, я не знаю, но у меня их всего два.

Наверняка, если разобраться, выяснится, что Julia использует под капотом LAPACK на Фортране.

А не хотите попробовать cm3 Modula-3 ?

Есть LLVM13 ( на Debian точно).

Есть утилита m3swig.

Да, и готовый пример подключения откомпиллированного кода на Fortran

Она в теории может и на GPU считать. Всё же Julia и создана для такой работы, было бы удивительно, если бы низкобюджетный Оберон её бы обогнал на этом. Возможно, что на других видах задач Оберон будет быстрее за счёт прямой компиляции в маш.код и статической типизации. В задачах типа отрисовки пользовательских интерфейсов Ява выглядит бледно: написанная на яве IDEA гораздо медленнее по ощущениям, чем VSCode, в котором Электрон, в котором сразу генерируется машкод. И это несмотря на то, что в Яве тоже есть JIT, т.е. по способу ускорения выполнения кода они с Julia похожи друг на друга. А Javascript также динамически типизирован. Правда, в движке v8 тоже есть JIT и код дальше ускоряется, что усложняет картину.

Новые замеры.

Численное интегрирование 360 секунд эволюции системы уравнений химической кинетики (взаимодействие цепочек РНК), состоящей из 19 уравнений. Правые части квадратичны по переменным. Решение проводится явным методом Рунге-Кутты 45 с адаптивным шагом (производится согласованный расчёт методом 4го и 5го порядка, и из их разницы получается оценка на ошибку). Особая сложность состоит в том, что в одном из режимов (with heating) происходит кратковременная (меньше 10 секунд) смена температуры, переводящая систему в сильно жёсткий режим.

Алгоритмы либо одинаковы (обероновские версии с моей собственной реализацией РК45), либо являются почти дословным переводом обероновских версий с использованием специализированных библиотек для численного интегрирования. Все параметры, включая ограничения по абсолютной и относительной ошибкам, одинаковы для всех реализаций. Простая питоновская реализация использует метод RK45 из scipy.integrate в цикле. Рализация через solve_ivp использует у себя внутри тот же самый метод RK45, но уже без моего цикла. Реализации в Джулии DP5 и Tsit5 — это, как я понял, просто два разных варианта метода РК45 (разные выборы коэффициентов для промежуточных шагов). При этом при переходе в режим жёсткой системы Джулия ругается и предлагает использовать неявные методы. Реализация через AutoTsit5(Rosenbrock23()) как раз это и делает: она использует неявный метод РК45 до тех пор, пока не зафиксирует высокую степень жёсткости системы, после чего переключается на метод Розенброка (один из неявных методов Рунге-Кутты), и наоборот.

ББ и A2 работали с полным GUIем. Всё запускалось на Arch Linux 64x на одном ядре процессора (там, где это от меня зависело, но у меня их в любом случае только два на этой машине). При компиляции Офронт+ом не были выключены ни проверки (вывозил за диапазон и т. п.) ни сборщик мусора, дальнейшее компилирование в машинный код проводились при помощи gcc с флагом оптимизации -Os.

Вот результаты замеров:

Что можно сказать? Офронт — чемпион. ББ неожиданно (для меня) держится неплохо, всего вдвое уступая по скорости. A2 заметно тормознее и уступает Офронту в 5–6 раз. Джулия на том же алгоритме ведёт себя на уровне ББ на сложной задаче, очень сильно теряя в производительности на простой (скорость хуже, чем у A2). На более оптимальном алгоритме Джулия показывает лучший результат в случае жёсткой системы, тогда как результат посредственный в простом случае. Более того, видно, что переключение на неявную схему позволяет легко преодолеть этот жёсткий участок, а основное время выполнения при этом набирается на простом участке (времена выполнения почти одинаковы без и с нагреванием). Про Питон помолчим. Грешно смеяться над больными языками.

Ещё замечу, что за время подготовки этих тестов A2 однажды намертво подвесила мою систему при перетаскивании мыши. ББ демонстрировал тормозючесть при промотке больших документов вверх (например, в отчёте по языку КП), а некоторые порты (окошки) изредка (пару раз было) переставали отвечать и закрашивались толстой полупрозрачной штриховокой.

Всем этим тестам я обязан настойчивым просьбам начальства переписать свои программы с Оберона на что-нибудь другое.

А где реализацию тестов посмотреть? Если Вы в АО использовали математические массивы, но как обычные - с поэлементным доступом, то производительности нет стоит ждать - там не прямой доступ, а через процедуры. В таком случае, нужно использовать обычные массивы.

Это нельзя считать корректными тестами. Просто хотел поделиться однократными наблюдениями. Но если действительно интересно, могу прикрепить архив с исходными текстами (файлы слишком большие, чтобы вываливать их содержимое в текст сообщения). В АО я матмассивы не использовал. Реализация является копией реализации на Обероне-2 с обычными открытыми массивами.

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

если не использовать real'ы — то ящик в среднем (по больнице ;-) проигрывает сишечке процентов на двадцать всего. при том, что CP2 не умеет даже в простейший CSE.

p.s.: кстати, у меня есть ещё такое подозрение, что можно чуть-чуть ускорить обращение к массивам, если инвертировать сторожей. потому что предсказатель на x86 по-умолчанию считает, что branch is not taken. из недостаков — трап покажет куда-то в космос вместо правильного места (потому что все трапы придётся собрать где-нибудь в конце процедуры).

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

Как видно, не всем это помогает в одинаковой степени. Но раз так, то надо бы указать тип процессора. Вот что выплёвывает /proc/cpuinfo:

Кстати, реализация на Julia не была вполне эквивалентной остальным реализациям. На участках с постоянной температурой в остальных реализациях вычисление кинетических констант не проводилось на каждом цикле, тогда как на Джулии именно это и происходило (16 величин с плавающей запятой через линейные комбинации, деления и взятие экспоненты). Все мои наивные попытки предотвратить это путём заведения глобальных переменных или передачи массива предвычисленных величин через параметр только ухудшали производительность. Вот теперь наконец разобрался, как это делать менее наивно и более эффективно. Привожу результаты замеров с новой реализацией для Джулии: Отмена. Программа что-то не то считает. Значит, логика нарушена. Буду разбираться.

Нет, не разобрался. Получается только ухудшить, но никак — улучшить.

с FPU всегда будет всё плохо: там куча load/store, которые довольно тормозные. те же load/store с обычными регистрами быстрее. предполагается, что современные компиляторы используют SSE-регистры, и общение с памятью оптимайзят. ящику, впрочем, никакой SSE без векторизатора не поможет. оптимизирующий компилятор на SSA мог бы — но это много возни ради довольно мизерного профита.

а вот почему Fox так отстал — непонятно. он — в теории — получше CP2 должен быть.

Да, интересно

Пожалуйста! Инструкция внутри.

Я мельком глянул файлы RK.Mod для АО и КП - и они делают немного разное. В КП просто копируются указатели, а в АО создается копия данных. Кроме того, в обоих файлах в GenerateK есть строки NEW(y0,L); y0 := Copy(ds.state), но в Copy снова создается массив в куче и затем присваивается y0.
В конце этой процедуры для КП строка ds.state := y0;, а для АО ds.state := Copy(y0).
Не знаю, насколько это влияет на производительность в целом.

D MutualLigationContT.Md разные типы. Я пока не могу запустить тесты, так как нет компа под рукой. Но в коде АО используется SIGNED64, а в КП - INTEGER (32 бит).
Так же есть различия в передаче параметров - для одного языка стоит VAR, для другого - нет. Не существенно, но код разный.

Справедливые замечания. Специально для прояснения этого вопроса заменил в файлах для блэкбокса INTEGER на LONGINT повсеместно, где это возможно (оставил INTEGER только в параметрах вывода). Заменил тип переменной DynamicalSystem с указателя на запись на просто запись, как это реализовано в АО, везде в связанных процедурах, соответственно, переменная передаётся с флагом VAR, а создание записи через NEW удалено. Само это отличие было порождено тем, что Fox на меня выругался и не дал использовать указатель на запись при переносе программы с Оберона-2. И последнее, заменил строку ds.state := y0 на бывшее ds.state := Copy(y0), как это осталось в АО. Такая непоследовательность связана с тем, что я когда-то намучился, да так до конца и не разобрался, когда в разных Оберонах можно присваивать массивы напрямую, а когда нет. Отсюда вообще и появилась функция Copy. Но оказывается, в КП и сначала в Обероне-2 я в этом месте попробовал прямое копирование, и оно сработало, а я об этом забыл и не распространил везде в последовательной манере. В любом случае, теперь программы совсем эквивалентны. Блэкбокс с новым текстом выдал следующие результаты:

То есть эти различия никак не влияли на производительность.

На на самом деле там есть ещё одно отличие. Коррекция шага на КП и Обероне-2 происходит путём взятия степени 1/8 от квадрата отношения заданной ошибки к её оценки через функцию Math.Pow, тогда как в АО берётся степень 1/4 через двойной вызов Math.Sqrt (я не нашёл функцию степени произвольного показателя). Но это примерно вдвое снижает производительность. К тому же это ошибка, так как степень не та. Если в ББ заменить Math.Pow(…,0.125) на Math.Sqrt(Math.Sqrt(…)), то получаем:

Скажите мне, как посчитать степень в АО, и я переделаю замеры.

Кстати, если будете запускать программу Офронта+ и Питона через run…, не забудьте в теле этих run… поменять в последней строчке $program на ./$program, а то скрипт не найдёт исполняемый файл. Я забыл это поменять.

В реализации для АО поменял всюду SIGNED64 на SIGNED32, убрал Copy из указанной выше строчки и заменил на прямое присвоение, и, самое главное, заменил реализацию возведения в неправильную степени 1/4 через sqrt(sqrt(x)) на реализацию возведения в правильную степень 1/8 через exp(0.125*ln(x)) (так реализована, например, функция Power в модуле MathRe в A2). Результат, действительно, улучшился. Теперь табличка выглядит вот так (заменены времена только для A2):


Теперь A2 лишь в полтора или менее раза отстаёт от ББ.

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

Небольшое дополнение. Используя библиотеку Lib Роберта Кэмпбелла (из которой, по большому счёту, мне нужны были только два алгоритма: разложение матриц на верхне и нижнетреугольную и решение линейных уравнений с помощью этого разложения), реализовал вчера метод Розенброка (адаптивный неявный метод Рунге-Кутты порядка 2–3). Этот то, что Джулия в моих примерах использовала на жёстких участках. Как реализовать детектирование жёсткости, пока не знаю (исходники в Джулии — это какой-то кромешный ад, описание тоже не нашёл). Так вот, первая реализация была для Блэкбокса. Затем перенёс её на Офронт+ (благо, он поддерживает КП, так что адаптация была легче, чем с Оберона-2 в Блэкбокс). Сделал измерение времени на той же задаче, но с использованием неявного метода на участке с высокой температурой (при этом нагрев и охлаждения обрабатывались старым явным методом). Заодно проверил, как работает компиляция Офронтом+ без оптимизации (ключ оптимизации -O0).

В табличке ниже (являющейся обновлением табличек выше) меткой IRK отмечены реализации с неявной схемой, меткой -O0 — без оптимизации gcc.

Как видно, с сишной оптимизацией удалось догнать Джулию на сложной задаче (на простой Джулия делает непонятно что). Производительность Блэкбокса стабильно в два раза отстаёт от Офронта+ с оптимизацией, почти не отставая от него же, но без оптимизации.

Затея с отключением оптимизации посетила меня после созерцания 8 секунд работы gcc по компиляции/линковке моей программы (так как не просто переписал нужные мне два алгоритма, а портировал с потерями LibVectors, LibIVectors, LibMatcices, LibIntegers, LibLongInts, LibReals) на фоне мгновенной компиляции в Блэкбоксе. Без оптимизации компиляция шла, действительно, быстрее, раз в пять. Но всё равно заметно.

(А меня всё равно настойчиво просят переписать всё на другой язык.)

В фоксе сейчас нет оптимизации. Проблема, скорее всего, не в оптимизации, а в том, что в цикле производится вывод данных и в варианте для а2 используется медленная реалищъзация.