(решено) TTread - может я чего-то не так делаю?

[vitaly_l]

Всем хорошего дня и настоения!

Есть картинка 640 на 360 пх.
Cheb сказал, нужно её при обработке поделить на кусочки (32х32) и только тогда обрабатывать.
Я её поделил на кусочки по 32 пикселя и отправляю в TTread...
Процессор (все его ядра) - закипают и график показывает загруженность всех ядер 50% (а без деления Tread все ядра работают ~ 10%).
Но скорость обработки картинки после деления на кусочки падает в 5-10 раз...

Запускаю вот так:

Код: Выделить всё

    for y := 0 to Length(treads)-1 do
      begin
        treads[y] := TSomeThread.Create(true);
        treads[y].fTreadStart := y;
        treads[y].Start;
      end;


Может я слишком много Tread одновременно запускаю? ( Tread получается 7200, каждая обрабатывает по 32 пикселя )
Или может я их(Tread-ы) как-то не так запускаю?
Пробовал, делать 360 треад - на каждую стоку изображения своя триада ( результат - тот же, но чуть быстрее чем когда их 7200 ).
А без треад - работает нормально, однако загруженность процессора всего 10%, и любая дополнительная нагрузка тормозит обработку.

Или Cheb пошутил и делить картинку на кусочки по 32х32 ненужно ?
Или нужно как-то по-другому делить картинку на кусочки ?


.

[Pavia]

360 много. Время переключения потока порядка 5 мкс. Время обработки вашей картинки порядка 1 мс.
Пусть комфортная цифра наклонных расходов 10%.
99% - 10%
1 мс - х мс
x=1 мс*10/99=0.01 мс.=100 мкс
Откуда имеем максимальное число 20 потоков на ядро для вашей задачи.

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

По поводу слов Cheb, пусть он объясняет. Никто кроме него не знает о чём он думал.
Существует как бы два подхода:
- параллельность по данным;
- параллельность по рабочим.

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

[vitaly_l]

TTread - надо создавать по числу ядер.

Круто - верю. Спасибо! Я как раз СЛУЧАЙНО пришёл к этому числу и "время-мер" показывал лучшее время, а теперь Вы объяснили причину!

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

Деление на количество данных (так предлагал Cheb)... это мне сложно... у меня не получилось... вернее я поделил, но стало медленнее...
Нужно очень хорошо знать все процессы... пока у меня таких знаний нет.
А вот деление на кол-во процессоров - оч. хорошо работает. <=== БОЛЬШОЕ СПАСИБО за разъяснение!


.

[Pavia]

Пул потоков.
Не хочу лить воду. А в проектировании так всегда или почти всегда. Поэтому остановимся на конкретике.

Зачем он нужен?
Автоматизация управления потоками.
Разделение управления и обработчиков.
Повышение производительности.
Балансировка потоков.
Когда не следует использовать пул потоков?
Когда есть длинные задачи.
Приоритеты задач
Необходимо иметь стабильную идентификацию, сопоставленную с потоком, или назначить поток задаче.

Автоматизация. Пользователю пулом потоков не нужно заботиться о создание и уничтожении потоков.
Разделение управления и обработчиков. Пулом потоков за счёт инкапсуляции позволяет избежать досадных ошибок. Защищая данные передаваемые в поток и сами потоки от возможных случайных ссылок на уничтоженные объекты(потоки и данные).
Замечание ! Такой подход не означает, что вы можете забыть о безопасности данных. Просто он гарантирует целостность их на входе в задачу и на выходе из задачи. Но если вы будете их менять по ходу выполнения задачи, то вы сможете нарваться на неприятности.
Для коротких задач не требуется каждый раз создавать поток.
Балансировка потоков. Числом различных задач можно балансировать нагрузку. Ставя в очередь нужное количество задач мы можем получить нужный процентное соотношение.

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

Приоритеты задач. Пул потоков не предусматривает очерёдность исполнения задач.
Но если их ввести в модификацию, то возникнут трудности с повышением производительности. Но в принципе есть решения допускающее такой подход.
Необходимо иметь стабильную идентификацию, сопоставленную с потоком, или назначить поток задаче. Редкий случай, когда надо закрепить за потоком нужные данные.
Замечание! Фрагментация памяти. Во избежание фрагментации память должна выделяться до того как пул потоков начнёт работать. Либо же вы должны использовать сборку мусора и дефрагментатор.

Как пул потоков планирует работы потоков?
Поток опрашивает очередь в течении NonSleepTime. Если не находит задач то засыпает.
Если пул- потоков обнаруживает что потоки не используются более TimeLive=CoiffecienLive* NonSleepTime то поток уничтожается.

Новые потоки создаются если замечено нехватка рабочих потоков. Потоки не забрали ни одну задачу за WorkTime.
Если задач нет, то потоки либо засыпают, либо уничтожаются. Если потоков меньше минимума то они спят если больше уничтожаются.

http://embarcadero.newsgroups.archived. ... 26520.html

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683194(v=vs.85).aspx

http://msdn.microsoft.com/ru-ru/library/0ka9477y(v=vs.110).aspx

http://rsdn.ru/forum/delphi/1181461.all

Добавлено спустя 50 минут 27 секунд:
Единственная большая проблема с потоками это интеграция с приложением.
Дело в том что нужно правильно организовать работу.
1) Поток должен исполнять короткие задачи порядка 0,1-10 мс.
Это нужно что-бы нормально можно было его остановить, без заметных простоев.
2) Вопрос синхронизации. Нельзя блокировать основной поток, он должен обрабатывать сообщения для вывода и реагировать на кнопки. Но при этом он должен ждать завершения команд. Что явно носит событийный характер.

[vitaly_l]

Поток должен исполнять короткие задачи порядка 0,1-10 мс.

Это условие, сейчас, выполняется.

Пользователю пулом потоков не нужно заботиться о создание и уничтожении потоков. Для коротких задач не требуется каждый раз создавать поток. Во избежание фрагментации память должна выделяться до того как пул потоков начнёт работать. Если задач нет, то потоки либо засыпают...

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


Спасибо БОЛЬШОЕ!


.

[vada]

А я нашел для себя MTProcs

[hovadur]

А я нашел для себя MTProcs

Спасибо большое!

[vitaly_l]

А я нашел для себя MTProcs

Я так понял (методом тыка), что для разных задач нужно менять триаду и MTProcs, т.к. MTProcs в некоторых(моих) задачах работает медленнее, чем без распараллеливания или триада. Но "вгрызается" в процессор MTProcs, оч. сильно, процессор аж "дымиться" начинает. Мне MTProcs показывал раньше VirtUX, но я тогда не обратил на него внимание, а теперь оценил, у него безусловно возможности совсем другие. Спасибо БОЛЬШОЕ !

Вот здесь ещё описания из wiki, если кому понадобиться:
http://wiki.freepascal.org/Multithreaded_Application_Tutorial/ru
http://wiki.freepascal.org/Parallel_procedures

а вот OpenMP я так и не понял как подключать: http://wiki.freepascal.org/OpenMP_support
и вот это не запустилось: http://wiki.freepascal.org/ThreadEvent хотя вот тут есть богатый пример (ещё не пробовал): http://wiki.freepascal.org/thread_event_test_project_1


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


Добавлено спустя 9 часов 99 минуту 99 секунд:
Кстати, в описании есть строчка, что для лучшей работы можно подключить heaptrc в uses.
Однако после его подключения, при выходе из программы - всегда появляется сообщение об ошибке в куче(heap).
И указывается два разных числа с разницей в ~1000 и говориться что, эту 1000 нужно освободить...
А без heaptrc - всё работает. <= Это ошибка heaptrc или моя? (и например её не видно без heaptrc)

.

[Pavia]

Видимо heaptrc встроен отладчик вот он и информирует что кто-то, скорее всего вы забыли высвободить 1000. Хотя это может быть где-то в недрах лазариуса. Просто проверьте на пустом проекте. Лично для меня польза от heaptrc сомнительна.

OpneMP не работает. Вернее там работает только одна функция параллельный цикл. Это болезнь присуще всем библиотека для параллельности. Единственную нормальную что видел это встроенная в Delphi XE7.

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

Согласен на все 100%.
Сейчас сделал захват с камеры, хотел обойтись без параллельности. Придётся продумывать обработку.

PS. VFW захват почти доделал, осталось доработать обработку ошибок 3-х производителей. И приступлю к параллельности.

[vitaly_l]

VFW захват почти доделал, осталось доработать обработку ошибок 3-х производителей

А какие там ошибки?

.

[Pavia]

1)
// capDriverConnect не соединяется.
// Окно ещё не запустилось. Видимо не готов к приему сообщений.
// Заплатка, делаем паузу 1 секунду.
2)
// ICDecompress не поддерживает входной формат RGB;
// Заплатка, просто копируем
3)
// Неожиданная смены формата между кадрами;
// Заплатка, семь бед один ресет
4)
// Нулевой размер изображения.
// Заплатка, вычисляем корректный размером

Добавлено спустя 12 минут 7 секунд:
Ранее я давал ссылку на квадрокоптер немцев. Их код базируется на библиотеке PTAM
Parallel Tracking and Mapping.

Суть в том что библиотека использует кооперативную многозадачность. Параллельность сделана в неявном виде. Большие задачи разбиты на мелкие представлены функциями. И вызовы идут внутри других функций. Код выглядит как обычный в виде дерева функций и понять где там параллельность без документации трудно.
Думаю можно сделать это в явном виде.

[vitaly_l]

Неожиданная смены формата между кадрами;

Это нужно каждый раз обновлять. Кстати в DX - говорят этого нет.

Суть в том что библиотека использует кооперативную многозадачность. Параллельность сделана в неявном виде. Большие задачи разбиты на мелкие представлены функциями. И вызовы идут внутри других функций. Код выглядит как обычный в виде дерева функций и понять где там параллельность без документации трудно. Думаю можно сделать это в явном виде.

Я не видел код немецкого квадрокоптера. Кооперативную многозадачность? В чём секрет их многозадачности? В любых программах функции вызывают функции. Пример кода есть?, а то по словесному описанию сложно понять.

[Pavia]

Код немцев.
https://github.com/tum-vision/tum_ardrone
Он заимствует код англичан.
https://github.com/Oxford-PTAM/PTAM-GPL/tree/master/Src
Описание параллельности стр 4.
http://www.robots.ox.ac.uk/~gk/publicat ... 7ISMAR.pdf

Кооперативную многозадачность?

Есть вытесняющая многозадачность есть кооперативная. В вытесняющая многозадачность - это потоки. Ядро процессора может в любой момент прерваться выполнение потока и переключить на другое.
В кооперативной многозадачности переключение происходит с разрешения самой задачи.
Пусть есть большие макрозадачи. Программист разбивает их на маленькие подзадачи. Переключения между задачами идёт на границе этих подзадач.
Суть кооперативной многозадачность в том что макро задачи перемежаются между собой.
MT1-макро задача 1
MT1.ST1 - подзадача 1
Выполнение с чередованием макрозадач:
MT1.ST1 MT2.ST1 MT3.ST1 MT1.ST2 MT2.ST2 MT3.ST2 MT1.ST1 MT2.ST3 MT3.ST3
1.1 2.1 3.1 1.2 2.2 3.2 1.3 2.3 3.3
Последовательное выполнение задач:
MT1.ST1 MT1.ST2 MT1.ST3 MT2.ST1 MT2.ST2 MT2.ST3 MT3.ST1 MT3.ST2 MT3.ST3
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 3.3

В кооперативной задачи могут выполняться произвольно. Как программист за программирует. К примеру 60% времени процессор выполняет 1 марко задачу. А 20% и 20% вторую и третью.
А при использовании Thead этого трудно добиться. Плюс с синхронизацией нет проблем. Так как передача в кооперативной задачи происходит на границе работы подзадачи она имеет всегда предсказуемое состояние. Что это значит? А значит что нет надобности в синхронизации, блокировках.

Многозадачность<>параллельности.
Кооперативная многозадачность не ускоряет обработку в отличие от Thead которые могут работать на нескольких ядрах.
На самом деле ускорение в кооперативной многозадачности тоже возможно. В ходе работ можно спрогнозировать и из-ять из очереди задач лишние подзадачи, не актуальные.

В чем суть от обычного функционального и процедурного программирования? Просто это другой взгляд на решение или оформление программы.

При мнительно к 3D-реконструкции. Для решения задачи колибровки камеры и вычисления её места в мире применяется обработка большого числа точек около 300. Что приводит к решению системы уравнений 300х300. Решение такой задачи занимает несколько секунд 1-2. А за это время надо параллельно обработать от 10-120 кадров с камеры найти особые точки.
Что-бы отрабатывать в реальном времени эту систему уравнений надо оперативно менять. Вот и получается что задачи надо "комбинировать" перемешивать между собой.