Предыстория и развитие событий:

- необходимость разработки генератора площадных зон на карте планеты;

- выбор ОС и среды программирования, с рвотным рефлексом;

- необходимость считать погрешность расчётов уравнений прямых с реверсивными вычислениями (оценка надёжности генератора);

- перенос наработок из прошлого проекта;

- определение погрешности расчёта при использовании long double для одного уравнения прямой, но с малой точностью (дискрет 1град при наклоне прямых);

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

Развитие событий привело к окончательному пониманию:

- без корректно работающей заготовки по параллелизму - невозможно выполнить задачу быстро и корректно (в т.ч. из-за забывания его тонкостей работы). Наработки прошлого проекта пришлось допиливать и выносить в отдельные файлы - именно для того, чтобы потом можно было их подключить к любому проекту, переименовать функции в соответствии с назначением и идти пить чай. И то, сейчас итоговый вариант еще не сделан: например, механизм слежения за потоками был полностью переписан - но недостаточно оптимизирован по разным критериям;

- создание приложения с параллелизмом - с нуля невозможно. Сначала должен быть написан однопоточный исходник, который с корректностью 100% что-то делает. Зацепившись за результаты работы однопоточного исходника (в данном случае, максимальное число k в уравнениях прямой и максимальная найденная погрешность) - исходник переписывается как многопоточный для каждого потока, с целью получить эти-самые числа за меньшее время;

- потоковый исходник отличается от однопоточного: негативно по критерию объёма кода и скорости работы. Имея работающий однопоточный исходник со временем работы 2080с, не удалось выжать из потокового исходника, работающего в одном потоке, менее 2140с. В свою очередь, в однопоточном исходнике время 2080с было получено путём многократной оптимизации, начиная со времени 6ч;

- как ни извращайся, родительский поток замедляет дочерние. В итоге, 2140с были уменьшены всего до 340с - не в теоретические 11 раз. Ещё совершаются попытки как-то уменьшить это влияние, но вероятность успеха уже низкая;

- никогда степень загрузки ЦП не является индикацией быстрых вычислений. Можно накодить так, что скорость окажется меньше однопоточного варианта (например, без ProcessMessages() в родительском потоке) - при загрузке ЦП 100%.

Тонкости, возникшие при разработке и тестировании:

- судя по диспетчеру задач, потоки с одним и тем же заданием (разница только в номиналах в первом цикле for - но при одинаковости количества итераций в нём) - выполняются за разное время (хотя предполагалось обратное: примерно одинаковое время). Полная хаотичность как номера потока, так и времени их работы (первый поток может кончаться на отметке 80-99% времени работы последнего). Изначально предполагалось, что более большие числа обрабатываются медленнее малых, - однако именно механизм слежения за потоками показал: и разбиение одной задачи на части для каждого потока корректное, и не в номинале чисел дело;

- к хаосу добавляется общее время выполнения всех потоков (всей задачи): плавает 270-410с - сами думайте, чем это вызвано на ПК, на котором нет ничего кроме голой ОС и дров, в которой ничего не запущено;

- формулам разбиения одной задачи на части, несмотря на их простоту, нужно уделить пристальное внимание. Дискрет работы однопоточного цикла было 360000, а потоков было 11, - нужно выводить уникальные числа для каждого потока, имитируя другое количество потоков, - проверяя их на полную корректность;

- изначально Terminate() потока работал корректно только внутри дочернего потока, не работая из массива потоков родительского потока. Удалось переломить ситуацию путём искусственного ограничения: исходный код дочернего потока никогда не будет выполнен до конца - while (true) Sleep(1000);

- со Sleep() очень неоднозначная ситуация (оптимальное число для родительского потока - 100). Она приводит к простою дочернего потока (нет нагрузки) - но не приводит к простою родительского (в диспетчере задач всегда 99-100% загрузки ЦП при загрузке всех потоков). Устраняет лаги родительского потока (форма перестаёт лагать) при работе механизма слежения за потоками (влияние дочерних потоков на родительский через свои переменные?!) - но никак не ускоряет дочерние потоки (думалось, что дочерние потоки влияют друг на друга, - однако разницы между Sleep() и сразу Terminate() нет);

- не исключено влияние всех потоков друг на друга, иначе как такой хаос со временами их выполнения объяснить (разницей частот потоков, постоянно плавающих и наблюдаемых в HWiNFO, - да не то пальто). Влияние, наверняка, нелинейное и хаотичное от запуска к запуску;

- запуск на разных ПК ещё больше путаницы вносит (при клонированной ОС и одинаковой по ТТХ и объёму RAM). ЦП i5-10400 отсасывает у i7-8700 и по частоте (-300МГц), и по разгону (-300МГц), и не имеет технологии TSX (направленной на ускорение параллелизма - какого хрена её из новых ЦП начали убирать: опять какая-нибудь охранота настояла?). Но при этом у i7-8700 время выполнения 400с против 340с у i5-10400. Тут точно что-то с настройками BIOS и тонкостями разгона связано (отключен может быть: у i5-10400 - разгон-подделка, одного ядра);

- сунулся в BIOS в настройки ЦП - отключение C1E, включение переопределения динамического коэффициента - практически сравняли скорости двух ЦП. Можно ли считать последнюю опцию алиасом TSX - непонятно. Реверсивные вычисления: отключаю переопределение - скорость увеличилась ещё больше - вообще ничего не понятно. Возможно, скорость меняется от перезагрузки, предпочтений винды и излучения планеты Нибиру (скорее всего, опять разброс скорости 21% играет роль - и первые замеры оценки скорости двух ЦП есть тупо совпадение);

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

Теперь пора запускать тест: для расчёта погрешности уравнений прямых выше точности 1град в 10 раз - 6мин. С учётом увеличения числа измерений в 10000 раз - результат будет получен где-то в августе (~40дн - а счёт за электричество при полной загрузке ЦП представляете?).

(добавлено 02.07.2026) Серверный E5-2696 V2 - в очередной раз ушатал i5-10400: 200с на ту же работу.

Потом было найдено решение, уменьшающее влияние родительского потока на дочерние. Sleep(100) и ProcessMessages() - надо писать не после цикла анализа состояния потоков, а непосредственно после анализа каждого потока (и 100 заменить на 10). Как только это произошло - i5-400 начал выдавать среднее значение 292с вместо 340с. Но это решение обнажило страшный баг, в очередной раз доказывающий: если хоть одна строчка при параллелизме неверна - всё идёт годзилле под хвост.

Время, затрачиваемое на вторую обработку вычислений, всегда стало сильно больше первой - процентов на 20-40. С помощью диспетчера задач выяснилось: потоки не освобождаются (перестала работать FreeOnTerminate = true). Какие только игры не делал с Free(), Terminate(), FreeOnTerminate, в родительском и дочернем потоках - либо потоки копятся (и разом, например, 55 потоков удаляются в диспетчере задач после выхода из ПО), либо Free() вызывает зависание исходников где-то внутри себя. Увеличенное время - первые дочерние 11 потоков, даже находясь после работы в покойном Sleep(квадриллион) и даже после Terminate(), - влияют на новые созданные 11. При этом, третий и последующие запуски не увеличивают время в прогрессии - оставляя его на том же уровне (с тем же разбросом - со средним 340с). Ужас и в том, что даже деструктор потока вызывает такое же зависание, как и Free(). То есть, добился ускорения только при первом нажатии на кнопку вычислений.

Невозможно проверить корректность Free() потока. Указатель на поток всё равно остаётся - а методов проверки вида IsFree(), IsTerminate() не существует. Может, Free работает нормально и всегда выполняется при Terminate() - просто есть ещё какой-то баг: что-то после этих потоков подчищать надо - и ОС тогда по подчищенному поймёт и удалит эти потоки окончательно.

(добавлено 03.07.2026) И проблема плавающего времени (погрешность стала <3%), и проблема Free() (корректное доудаление потоков) - были решены. Время заявить о себе как о гении, сравнимым с капитаном Джеком Воробьём, - однако параллелизм никогда не отступает: время выполнения вычислений на самом слабом ЦП стало самым малым (260с), а время на самом сильном стало вместо 200с - 296с. Это уже - полный сюр и дичь; что изменилось - совершенно непонятно. И надо рыть дальше.

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

(добавлено 03.07.2026) Сюр возвёлся в квадрат - поэтому именно данный материал надо заканчивать, отложив чистовую разработку модуля многопоточности на время. Выяснилось, что как ни играйся с элементами родительского потока - реакция разных ЦП на эти игры разные. Один ЦП ускорится, второй замедлится - причём полная алогичность: например, уменьшение нагрузки на родительский поток - приводит к увеличению времени выполнения дочерних. Что пробовалось:

- выставление приоритета реального времени для самого приложения - никаких изменений;

- проверка в цикле нового чекбокса на чекнутость - разная реакция ЦП;

- полное засыпание родительского потока - разная реакция ЦП;

- вообще не слежение за потоками в родительском (тупо запуск дочерних потоков и ожидание - потоки сами возвращают время своей работы) - разная реакция ЦП (причём 2 из 3 - в сторону замедления - полный абсурд);

- отключение именно визуального слежения за потоками (подкраска лабелов) - разная реакция ЦП.

Значит, и класс потока, и модуль работы с потоками требуют серьёзных доработок:

- обязательное введение сохранения времени работы каждого потока;

- создание функции именно внутри модуля, возвращающей массив данных: нулевой элемент (не все потоки остановлены как завершившие работу) и остальные (конкретный поток не остановлен). Создание функции именно внутри модуля, убивающей все потоки и очищающей память;

- создание теста времени Sleep() и частоты вызова ProcessMessages() в родительском потоке: если для каждого ЦП разное время выполнения и алогичность его поведения - измерять по факту на каждом ПК. Здесь можно зацепиться за 2 времени сразу, как факта корректности работы алгоритма: 260с на i5-10400 и 200с на E5-2696 V2;

- добавить булев параметр и счётчик количества вызова циклов внутри потока: облегчённая перепроверка самого себя на правильность распределения задачи между потоками. Добавить и тест, имитирующий количество потоков 1-N и выдающий количество итераций для начального цикла for (причём, не расчётные числа - а факт отработки цикла).

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

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

- чем больше потоков завершило обработку своей порции данных - тем больше неоптимальность использования ЦП получается;

- в случае прошлого проекта, вычисления простых чисел, проблема решалась просто: вычислил простое число - не останавливайся, считай следующее - пока общий счётчик простых чисел не достигнет N. В результате, прирост скорости был получен просто феноменальный;

- здесь же - нужно при условных 11 потоках: разбивать задачу на 100 частей, а не на 11 (ну не получается тут не разбивать задачу на части). И кормить следующую порцию данных остановившемуся потоку сразу же, как он остановился. Также возникнет вопрос: создавать новый поток или пытаться внутри текущего потока какой-нибудь goto mark_Begin реализовать;

- эту доработку нужно реализовывать последней из всех вышеуказанных и придумываемых в будущем.

А пока - просто скрин, как потоки хаотично завершаются (здесь всё началось с 9-го). В данном примере - максимальная погрешность уравнений прямых уже посчитана каким-то из завершившихся потоков. Остальные потоки - данную величину не превысят (это известно только потому, что данная величина известна заранее, - часами высчитанная на одном потоке). Ну и потратят на E5-2696 V2 332с вместо 200с.