РОС - программа расчёта оптики телескопов

[ekvi]

ошибка access violation at address

Такое обычно идёт при отладке программы.
Попробуйте отключить параллелизм (снять флажок в чек-боксе parCalcing на странице "Тест"), повторите оптимизацию и сравните время и число тестирований (в редакционном окне Ntst - в правом нижним углу Главного окна программы). По окончании оптимизации РОС выдаёт эти данные сам:
На илл. : Оптимизация проведена без применения параллельных потоков. Скорость счёта: 35000/144 = 243 теста/сек или время 4.12 мс на 1 тест.
parCakcAlgo.txt - подборка кода для работы с пар. потоками

[ekvi]

В обсуждении принимают участие очень осведомлённые специалисты. Как Вы думаете:
1. можно ли во время остановки потока обращаться к потоковым переменным не по псевдонимам, которые объявляются в разделе Свойства (property), а напрямую: t = Thread(i).t - ?
Вопрос вызван тем, что отдельным переменным легко присвоить псевдонимы, но как быть с массивами? - их три: R, L, E - до 20 в каждом!

2. Есть ли у кого-нибудь из вас Справочник команд для процессора Intel core i7   ?

3. Измерение времени ожидания окончания работы всех потоков на четырёх ПК, имеющих разную конфигурацию, составило ОДНО время = 4 мс.  Так допотопно скомпилирована программа или это - задержка моста (точнее "парома") между шинами при записи результатов из потоков в память?

[xd]

1. Да, если область видимости позволяет (public)
2. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf

[ekvi]

Спаси бо!

[ekvi]

Ввёл в программу высокоточный таймер https://yadi.sk/d/vviS6jkzxqKq4 для отсечки времени выполнения одного тестирования ОС (на приведённой илл. - окно t1tst).
Проведённый тайминг обнадёживает: ускорение пропорционально числу потоков!? - можете сами сопоставить времена счёта в 1- и во многопоточном режимах.

Из этого следует (из формулы Амдала для коэффициента ускорения K = N/(1+(n-1)*f, N - число потоков), что при оптимизации доля f остальных вычислений, производимых в  последовательном режиме, составляет не 10%, как интуитивно предполагалось, а более 25%, т.е. есть над чем дальше работать.

[ekvi]

Последняя версия РОС: https://yadi.sk/d/vviS6jkzxqKq4
Снова "залез" в Эмбаркадеро 64 бит (это такая навороченная Дельфя - как и во времена Борландов, слитно с VC++): может на 64bit загрузка пойдёт быстрей, а весь мой арсенал нужно сдать в утиль?!

Как и всегда в таких случаях - до сих пор паутину с ушей смахиваю: едва выкарабкался из хвалёных дебрей.
Кроме того, все "ускорители" работают на "выровненных" double (8 байт) вместо extended (10 байт), что даёт потерю 4 - 5  десятичных знаков (15 против 20), а, значит, мелко пашут. Для оптимизации такая потеря точности  принципиальна: ~30%.
 
А достаточно было просто разделить процессы: сначала загрузить все потоки и только после этого запустить их одновременно. Тогда потоки не перепутываются в мозгах изумлённой операционки и она сопровождает их стройными (параллельными) рядами.
Проведение аккуратных замеров показало, что время загрузки всех потоков обновлёнными параметрами занимает не более 10 мкс (при ftakt = 2.2 ГГц), что составляет менее 1% от параллельной работы потоков. Действительно, не стоит переводить с 32 на 64-б память.
Теперь зачищаю модули от лишних опций и мусора ...

[xd]

Хотите сказать что относительная погрешность представления данных \(\varepsilon = 2^{-53} \approx 10^{-16} \) - это мало?
У Вас настолько неустойчивый метод?

[ekvi]

Хотите сказать

Я и говорю: в 1980-90-е отказался от С по причине того, что сишникам вообще, кроме колбасы, ничего считать не надо: корень квадратный они извлекают в 2 раза (!?) дольше. Как у них сейчас с этим - не знаю, не проверял - их проблемы.
В С++ 2^53 - предел мечтаний. При такой глубине оптимизатор, как поплавок болтается, дна не чует.
Зато Паскаль сначала заточен на инженерные расчёты: 2^80 (на что способен сопроцессор) - и пашет, пока не остановишь.

[xd]

Вы что-то явно мифологическое утверждаете.

Формат типа float и double в C/C++ полностью соответствует стандарту IEEE-754 - вещественные числа одинарной и двойной точности.
См https://ru.wikipedia.org/wiki/IEEE_754-2008.
Мантисса числа двойной точности имеет 53 двоичных знака и этим определяется погрешность его представления.
Это стандартные типы, которые используются для представления вещественных чисел и с ними работают вычисления во всех современных процессорах.
Компилятор из Delphi под типом extended понимает формат представления чисел в сопроцессоре i387, хранящиеся в стековых регистрах данных FPx, но есть и другие типы: Single, Double (аналоги float и double соответственно)
Кроме того, есть ещё тип Currency, который соответствует типу с десятичным порядком (против двоичного порядка в остальных) - но он не имеет аппаратной поддержки в x86 и поэтому программно эмулируется, но позволяет вести точные вычисления в десятичных числах для операций сложения, вычитания и умножения до тех пор, пока не возникает переполнения и необходимости отбрасывать младшие десятичные разряды.
http://www.delphibasics.co.uk/Article.asp?Name=Numbers

Что касается расширенного формата, то он имеет по сравнению с двойной точностью 64 бита мантиссы против 53 (но не имеет виртуальной единицы, поэтому речь идёт о 63 полезных битах), и 15 бит экспоненты против 11 бит у double.
Это значит, то точность представления - плюс 3 десятичных знака, и диапазон значений в 16 раз шире как в сторону больших, так и в сторону малых чисел.
Однако тип extended "тратит" один бит на представление денормализованных чисел и не-чисел (zero, nan, inf).
Цена такого расширения вот уже последние 20 лет, начиная с появления набора инструкций SSE2 (Pentium 4 - вышел в конце 2000 года) и далее - быстродействие. Вернее оно продолжает расти с частотой процессора, но всё равно оказывается медленнее менее специализированных решений для вычислений. Кроме того, данные в памяти будут не выровнены, что сокращает эффективность работы с памятью.
Вы с одной стороны используете архаичный компилятор 15-летней давности, с другой стороны используете его по канонам тех времён. И пока Вы гоняете типы в формате x87, у Вас будет генерироваться код для x87 на любом компиляторе.
Я выше приводил ссылку на перечень инструкций процессора - в следующем сообщении я опубликую таблицу сравнения быстродействия некоторых инструкций 387 и SSE2 для реализации аналогичного функционала.
А что касается точности 64/80 бит, то ещё надо бы доказать, что для данного класса вычислительных задач именно точность представления и/или накопление ошибок влияет на результаты расчётов, а не качество методов.

Теперь скажу за C++: я тоже к этому языку имею ряд претензий, однако они находятся вне обсуждаемой плоскости. Однако есть ряд техник, которые позволяют писать код куда более лаконично на пользовательских типах данных, чем Delphi хотя бы в силу наличия возможности определять собственные реализации арифметических операторов и писать шаблонный код. Попробуйте реализовать преобразование Фурье на Delphi: получится жуткая мешанина данных и функций, а алгоритм будет записан в гораздо менее ествественном виде.
Сравните разные варианты программного интерфейса модуля сложения чего-то похожего на числа (комплексные числа, кватернионы, вектора, матрицы и т.п.): Add(x1, x2), x1.Add(x2), x1 + x2.
Delphi до 7 версии включительно принципиально не умеет последний вариант, который является абсолютной нормой на любом си-подобном языке, включая C++, Java, C# и многие другие, а также во многих других языках. Не знаю точно когда определение операторов было введено в Delphi, но точно знаю что оно сейчас есть, но после Delphi7.

[xd]

Привожу данные на основе таблиц https://www.agner.org/optimize/instruction_tables.pdf для архитектур Pentium 4 EM64T (Prescott Intel Core i7 7 поколения (SkylakeX) 3-летней давности.
Уже на P4 видно, что SSE2 чуть-чуть быстрее FPU кроме операции загрузки целого числа (FILD -> CVTSI2SD)
Для SkylakeX быстрее стали как FPU, так и SSE-инструкции, однако для SSE-инструкций ускорение выше.
Поясню что тут написано:
instr - опкод
args - если быстродействие зависит от аргументов, то указан какой используется (m32, m64 - word, dword memory; m80 - extended memory, m - memory, x - SIMD register)
lat - минимальная задержка от начала выполнения инструкции до получения её результата. Фактическая задержка может быть выше из-за непопадания в кэш и другим причинам.
thr - минимальная задержка между началом выполнением текущей инструкции и началом выполнения следующей инструкции, если не было зависимости по данным или вычислительным узлам.

Прямой реализации тригонометрических вычислений на SIMD-расширениях нет, однако есть материалы, сравнивающие программную реализацию на SSE2 против x87: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.396&rep=rep1&type=pdf
Получили примерно того же порядка быстродействие.
На P4 FPU делает тригонометрию примерно за 200 тактов, в то время как операция умножения стоит 8 тактов, а сложение - 6 таков, то есть надо уложить программную реализацию примерно в 25 операций умножения/сложения на P4 и ~20 для i7 - это сделать довольно просто. Другое дело что накладные расходы на загрузку кэша инструкций будет выше чем выполнение 1 опкода, но это другой вопрос.

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

[ekvi]

Стоило Дмитрию Александровичу посетовать ... - аж два развёрнутых экскурса!
По всем вопросам в процессорных технологиях мы с А.Г. Водянком ещё в 2008м обменялись мнениями. Тогда он апробировал идею Д. Маколкина ускорения расчёта оптики на видеокартах (Нвидеакуда). В 2017м и я клюнул на эту приманку (результаты см. в теме).
Самое забавное то, что Линзик Водяника на моём 1-ядерном ноуте считал в 3 раза быстрее, чем мои самоделки. Вот тут я с Вами соглашусь: такое "ускорение", достигнутое профессиональными программистами за счёт рационального использования памяти, и есть заслуга компилятора, осведомлённого во всех закоулках процессора и операционки. Всё это понятно. Собственно, это понуждает постоянно вступать то в партию, то в г:  в Линюкс, и Питон, и ОС/2, С++, С# ... Вспомнишь - содрогнёшься. Одни заманухи. Теперь вот мультишредистой явой угрожают ...
Ввиду жёсткой монополии в вычислительной технике, нам никогда даже не "догнать" монополистов, понудивших полную информацию об аппарате предоставлять только им. Как-то читал один учебник по ассемблеру, и автор, касаясь клавиатуры, как раз об этом речь ведёт.  В его таблицах были приведены скан-коды 45% клавиш. Я попытался извлечь скан-коды остальных клавиш и ... обломался: автор оставил их нам в качестве доказательства своего наблюдения
Что касается чисел 8 против 10 байтов. Тут просто нужно привести ряд примеров оптимизации в разных глубинах. Уже оскома в мозках и мозоль на языке по этому поводу. Нужно программу переводить на 8б-режим. Сделать это элементарно: задать float = double вместо extended. Основная трудность - согласовать загрузку-выгрузку систем. Или врукопашную ввести сравниваемые системы. Короче, целое исследование. Придётся поверить на слово, либо ждать случая, который убедит сомневающихся.
Оптики пользуются формулами Федера, которые обходятся без син-косинусов. В них-то как раз и используются 2 извлечения кв. корня, о которых выше зашла речь. Дело однажды дошло до абсурда: в ПЗУ Спектрума  К. Синклера была зашита п/п извлечения корня через логарифм и экспоненту - считался он более 1 сек (!?) - как тут снова не вспомнить про колбасу. Но стоил Спектрум 100$ - почти в 10х дешевле IBM. Потому его и не стало ...

[ekvi]

В приложении - двумерное БПФ на паскале. Оно написано французским программистом Jean Debord. Использую его уже лет 20.
Если предложите целочисленную, более эффективную альтернативу, поставлю 10+.
Сейчас Кш по спектру вычисляется в 4 раза быстрее. Решение простое: вместо сетки 256х256 применил 64х64 (Г.Г. Слюсарев допускал 32х32).

[xd]

https://www.centerspace.net/doc/NMathSuite/ref/html/N_CenterSpace_NMath_Core.htm
Как собираетесь тестировать производительность?

[ekvi]

https://www.centerspace.net/doc/NMathSuite/ref/html/N_CenterSpace_NMath_Core.htm

В ответ на выложенный код БПФ толкнули меня в какой-то лабиринт?!

Как собираетесь тестировать производительность?

В РОС БПФ используется при преобразовании зрачковой функции в массив данных для построения ФРТ, ЧКХ и Кш.
Сейчас наиболее долгий тест - вычисление Кш по рабочему спектру. График Кш = f(Lam) в РОС можно построить двумя путями: открыв в левом блокноте одноимённую страницу или, уже будучи на странице "Кш", нажав кнопку "Расчёт Кш". Первый способ расчёта использую для засечки времени счёта основным методом, второй - альтернативным. Так вчера отлаживал поточный метод. Как уже докладывал, решение пришло путём исключения альтернативы -  снижением трудоёмкости за счёт уменьшения частоты расчётной сетки.

[xd]

https://www.centerspace.net/doc/NMathSuite/ref/html/N_CenterSpace_NMath_Core.htm

В ответ на выложенный код БПФ толкнули меня в какой-то лабиринт?!

Я дал ссылку на реализацию преобразования Фурье в уже готовой библиотеке для платформы .NET.

Как собираетесь тестировать производительность?

В РОС БПФ используется при преобразовании зрачковой функции в массив данных для построения ФРТ, ЧКХ и Кш.
Сейчас наиболее долгий тест - вычисление Кш по рабочему спектру. График Кш = f(Lam) в РОС можно построить двумя путями: открыв в левом блокноте одноимённую страницу или, уже будучи на странице "Кш", нажав кнопку "Расчёт Кш". Первый способ расчёта использую для засечки времени счёта основным методом, второй - альтернативным. Так вчера отлаживал поточный метод. Как уже докладывал, решение пришло путём исключения альтернативы -  снижением трудоёмкости за счёт уменьшения частоты расчётной сетки.

Ещё раз: Вы хотите объективной картины для конкретных вычислительных алгоритмов? Судя по всему - нет.


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

[ekvi]

преобразования Фурье в уже готовой библиотеке

- подобная библиотека (FFTW), "весом" более 1.5 Мб, мне известна ещё со времён Линзика (2008). Сторонние разработки - кот в мешке.

Попробуйте реализовать преобразование Фурье на Delphi: получится жуткая мешанина данных и функций

БПФ приведена на паскале в порядке иллюстрации в ответ на это утверждение. Изящный код, занимающий чуть более 100 строк.

[Дмитрий Серегин]

БПФ приведена на паскале в порядке иллюстрации в ответ на это утверждение. Изящный код, занимающий чуть более 100 строк.

Если я правильно помню, то в Demos и Interf, разработанных в ГОИ им. С.И.Вавилова, код очень близок.

[xd]

Измерять продуктивность программирования подсчетом строк кода — это так же, как оценивать постройку самолета по его весу.
— Bill Gates

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

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

[Дмитрий Серегин]

C Модератором спорить сложно, или надо менять раздел, или форум где общаться. ИМХО.

[xd]

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