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

[ROVIAN]

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

Сборку под себя пытался собрать, но ... так можно и забыть, зачем пришёл. Речь шла о среднестатистическом пользователе.
А Вы полагаете, что МС с каждой новой версией винды облегчает жизнь программирующему инженеру?

Для среднестатистического просто делается сборка, когда ставится голая винда и потом уже предлагается выбор программ, все кучей многим не нужны. Потом остаётся только обновить дрова. Ну если кому чего надо отдельно, то поставить не проблема.
Ну про облегчение жизни речь то не идёт, развивается железо, появляется новая периферия, соответственно развивается и ПО.
Да и кто тут спрашивает инженера или пользователя... это коммерческий продукт, нельзя делать раз и навсегда. Понятно, что будут выпускать железо, которое не совместимо с "старым" ПО. Ну и втюхивать под него "новое".  Как говорится...бизнес...ничего личного. 

[ekvi]

бизнес...ничего личного

Об этом "ожирении" (от слова жировать) мы и говорим.

[ekvi]

Под W10 при запуске одной задачи - илл. 1 - нагрузка равномерно распределяется (по 50%) на каждое ядро; при запуске второй задачи оба ядра загружены на 100%.
Значит, может?! Может, да не хочет!

бизнес...ничего личного

-

[xd]

Мда... Расчёт идёт в один поток, и планировщик потоков операционной системы его перемещает с одного ядра процессора на другое, в итоге среднее время работы на каждом из ядер - 50%. Было бы 4 ядра - было бы по 25%.
Когда добавляется вторая единица работы, то загрузка ядер становится по 2 задачи*100%/2 ядра = 100%. Опять-таки, было бы 4 ядра - было бы по 50%.

[ekvi]

Распараллеливание расчётов требует перестройки всего мышления. Когда запускаются несколько вычислительных потоков, они должны иметь дело с разными, информационно не пересекающимися объектами. А у нас ОДИН объект - ОС.
Можно из-ся и найти в алгоритме участки, информационно не пересекающиеся, - есть такое направление; но это надо быть о 7 пядей.
Целесообразно сначала организовать несколько проекций ОС на каждый параметр и таким образом, пожертвовав ресурсами ПК, достичь ускорения в вычислениях. Такой путь я проходил на старой машине и под старой Виндой с 1.7х эффектом ускорения. Имеет смысл повторить этот опыт в новых условиях: ускорение сулит быть пропорциональным тактовой частоте и числу ядер процессора пользователя (видеокарта в этом не задействована - только CPU).

[xd]

Без комментариев...

[Алексей Юдин]

Распараллеливание расчётов требует перестройки всего мышления. Когда запускаются несколько вычислительных потоков, они должны иметь дело с разными, информационно не пересекающимися объектами. А у нас ОДИН объект - ОС.

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

[ekvi]

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

Тестовый пример (см. приложение к данному сообщению) показывает:
1. Распараллеливание инженерных вычислений не нуждается ни в видеокартах, ни в наворотах Эмбаркадеро, ни блуждания по сетям: достаточно Дельфи7лайт с простой синхронизацией чтения/записи из основного потока.
2. Ускорение пропорционально только числу параллельных потоков: целесообразно прогон каждого луча через ОС запускать в отдельном потоке.
3. Многоядерность для задач, типа оптической,  излишня: современный процессор её решает в полусонном состоянии, т.к. в основном спит (sleep(0)). Требуется только современная операционка (Пример сделан под W10_32b) и такой же процессор.

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

Работает на одном ядре.
У меня на 2-м см. приложение.

[ekvi]

Работает на одном ядре.

28% - 3% берёт "контролёр" и 30 потоков (6 углов на 5 линий).
Все эти контролёры имеют период ~ 1c, а время отработки потока - единицы мкс. Процессор постоянно спит, о чём и сообщает контролёр:
при линейном счёте каждый тест ~ 300 мкс, партест проходит за 300/(6*5) = 10 мкс
При лучевом распараллеливании потоков будет несколько тысяч - ядрам спать некогда будет.

[ekvi]

Уточняю: операционка W10_64b, optThread - 32b.
Ядра пусть обслуживают шпионские программы. Для нас главное - ускорение нашей программы! А оно составляет в некоторых случаях 150х.
Этого я не ожидал.
Получевое распараллеливание пока откладывается: пример капризничает и плохо переносится в РОС.

[ekvi]

Пар.потоки подключены к оптимизатору (на скриншоте - мониторинг работы программы на 2х-ядерном процессоре).
В текстовом файле приведены все ключевые моменты: модуль tubes.pas, запуск оптимизатора, вызов подпрограммы параллельных вычислений. Страждущие могут использовать это решение для своих задач.
Вот ссылка на РОС для пользователей: https://yadi.sk/d/vviS6jkzxqKq4.
После распаковки архива файл ROS#.ros переименуйте в ROS#.exe.
Успехов!

[ekvi]

Реальное ускорение оказалось пропорциональным не числу потоков, а числу ядер процессора. Причём даже не числу потоков процессора, а именно числу физических ядер. На самом деле всё сложнее...
Я уже думаю, что напрасно авансом распараллелил на 15 - 30 потоков - это только усложняет Windows обслуживание РОС. Надо попробовать ограничиться 3-5 потоками: одно ядро всё равно будет занято главным потоком (самой программой РОС), а остальные (1 - 3) смогут реально заняться ускорением вычислений.

[xd]

Ох уж эти эвристики...

[ekvi]

https://yadi.sk/d/vviS6jkzxqKq4 - последняя, рабочая версия РОС.
На иллюстрации - мониторинг 4х-ядерного процессора.

[AP]

https://yadi.sk/d/vviS6jkzxqKq4 - последняя, рабочая версия РОС.

На процессоре с 24 потоками загрузка 62%. У вас какое-то ограничение стоит?

[ekvi]

У меня самое большое - 4GOOD - 4 физических ядра, и они грузятся под завязку. Но у 2х-ядерного 4-х поточного 2 - загружены на 100%, а 2 (видимо, потока) - на 85% (см. илл. в сообщении #794). Поскольку потоками заведует операционка, думаю, Ваш вопрос нужно адресовать к ней.
 Со своей стороны могу предположить, что сама оптическая задача даёт для мощного процессора ничтожную нагрузку, и он не утруждает себя. В алгоритме убраны все sleep(0), рекомендуемые многими идеологами параллельных вычислений, так, что, я надеюсь, что устранил все препятствия для наискорейшего счёта. Скорей всего, ошибаюсь - для меня эта стезя - в самом начале.
Ещё могу добавить следующие наблюдения.
1. Разные процессоры по разному считают - и в смысле результатов по цифрам, и в смысле глубины оптимизации.
2. Рекламные "параллельные" потоки практически не дают ускорения. Но и это зависит от процессора и его производителя.
Эти замечания - в порядке расшифровки упомянутой выше "сложности" самого вопроса ускорения. Для 2х-ядерного получилось всего 1.7х ускорение. Кстати, полноценный параллелизм заработал только после сокращения числа потоков с 20 до 5 и перенесения вычисления почти всех обновлений внутрь самих потоков. Догадываюсь, что этим самым были сняты поводы для возникновения пересылочных ошибок (а "почтальоном" в них выступает операционка - её порядки мне плохо известны).
При оптимизации на SimplexNM по кривизнам последовательный алгоритм считает в 5 раз быстрее параллельного - парадоксы, оказывается, присущи не только оптике.

[ekvi]

У вас какое-то ограничение стоит?

Да, число потоков было ограничено 9.
Сейчас снял все ограничения - и по числу углов, и по линиям  спектра, и по лучевым зонам на ВЗ.
По той же ссылке скачайте новую версию РОС.

[AP]

Да, число потоков было ограничено 9.
Сейчас снял все ограничения - и по числу углов, и по линиям  спектра, и по лучевым зонам на ВЗ.
По той же ссылке скачайте новую версию РОС.

Загрузка практически не изменилась (64-67%).

[ekvi]

Загрузка практически не изменилась (64-67%).

Поддайте ему жару: установите число углов (=stars на стр. МПО) равным, например, 40. Установите число линий спектра nnSpLns (на странице "Стёкла"), например, 17. Но тогда на стр. "Тест"измените № рабочей линии на 8, и загните число Zon (стр. МПО), например, до 30.
Если, конечно, ядра у Вашего процессора реально физические, а не рекламно-поточные...