TThread

← →
dmk © (2016-07-05 22:15) [0]

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

← →
iop © (2016-07-05 22:22) [1]

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

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

← →
iop © (2016-07-05 22:24) [2]

а еще может прийти понимание того, что потоки это средство распараллелить вычисления, но не средство структурировать код

для структурирования кода придуманы модули и процедуры/функции

← →
Kilkennycat © (2016-07-05 22:24) [3]

Насколько строгой? Что бы за один такт совершилось две операции (по одной в каждом потоке) ?
Теоретически, на многоядерном процессоре возможно.
А практически, почему не считать завершение последнего завершением и первого?

> неизвестно, какой поток придет первый, а какой последний.

Это как? Потоки вообще-то могут общаться и с собой, и с третьим.

← →
DVM © (2016-07-05 22:42) [4]

> возможно ли заставить выполнить потоки в строгой последовательности
> и в то же время, чтобы простоев (ожиданий) не было.

можно, надо лишь отказаться от доп потоков и делать все в одном потоке последовательно.

← →
dmk © (2016-07-05 23:10) [5]

>можно сделать любую бессмыслицу
Хочу!!!!

На самом деле в потоках рисуется десятки тысяч линий по одним и тем же координатам (объекты). В одном потоке это очень медленная операция. Нужно чтобы линии рисовались последовательно, но множеством потоков. Иначе получается так, что некоторые линии рисуются после тех которые должны быть поверх. Меняется очередность линий и получается легкое мерцание и неправильная картинка.
У меня есть например 12 потоков. 1-й рисует скажем первую сотню или тысячу линий. Второй рисует вторую. Но в массиве это лежит все в строгой последовательности и в нужном порядке наложения. Вот и хотелось бы сохранить этот порядок. Сейчас все рисуется как получится именно из-за непоследовательного выполнения потоков. Понимаю, что задача не очень продумана, но все же ... Скорость отрисовки в 6 раз выше. Мне это нравится.
Есть мысли по этому поводу?

← →
dmk © (2016-07-05 23:13) [6]

Усе, понял. Надо сделать на каждый поток отдельный буфер. Т.е. порезать экран вертикально или горизонтально. Только проблемы с отсечением. Из-за параллельности отсечени не всегда срабатывает. Или не во-время срабатывает. Будем думать.

← →
iop © (2016-07-05 23:18) [7]

Удалено модератором

← →
iop © (2016-07-05 23:19) [8]

две гайки - два завода!

логично же

← →
dmk © (2016-07-05 23:21) [9]

>а еще может прийти понимание того,
>что потоки это средство распараллелить вычисления,
>но не средство структурировать код

А я вот 3 дня долбал TThread и научился рисовать в потоках на экране.
Практически все получается вывести, кроме линий. И главное скорость в разы больше.
А иначе зачем TThread вообще нужен.

← →
dmk © (2016-07-05 23:22) [10]

Удалено модератором

← →
iop © (2016-07-05 23:29) [11]

еще раз для астрофизиков на досуге.

если какие потоки должны рисовать последовательно, то это значит что поток должен быть один.

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

← →
dmk © (2016-07-05 23:30) [12]

iop © (05.07.16 23:18) [7]
Я вашу логику понимаю. Так работают потоки. Но я немножечко обошел логику эту с помощью рисования в буфере. По частям. Вот и решение.

← →
dmk © (2016-07-05 23:37) [13]

Меня тоже поражает логика многих программистов. Конечно она безупречна с точки зрения самой логики, но есть и не логичные варианты. Они тоже ведь подходят. Чего ругаться то сразу :)

← →
Германн © (2016-07-06 01:22) [14]

> dmk © (05.07.16 23:21) [9]
>
> >а еще может прийти понимание того,
> >что потоки это средство распараллелить вычисления,
> >но не средство структурировать код
>
> А я вот 3 дня долбал TThread и научился рисовать в потоках
> на экране.
> Практически все получается вывести, кроме линий. И главное
> скорость в разы больше.
> А иначе зачем TThread вообще нужен.

> dmk © (05.07.16 23:30) [12]
>
> iop © (05.07.16 23:18) [7]
> Я вашу логику понимаю. Так работают потоки. Но я немножечко
> обошел логику эту с помощью рисования в буфере. По частям.
> Вот и решение.

А рисование в буфере без доппотоков не дало бы тоже самое решение?

<OFFTOP>
P.S. Я вот не понимаю чем использование доппотоков может увеличить скорость выполнения программ в разы, кроме распределения этих потоков на разные ядра процессора. Конечно Винда таки их распределяет, но с учётом в первую очередь своих интересов.
</OFFTOP>

← →
dmk © (2016-07-06 02:47) [15]

>А рисование в буфере без доппотоков не дало бы тоже самое решение?
Решение тоже самое, но в 6 раз медленнее.

← →
Rouse_ © (2016-07-06 07:25) [16]

Удалено модератором

← →
sdf (2016-07-06 08:43) [17]

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

← →
Kilkennycat © (2016-07-06 09:32) [18]

> рисуется десятки тысяч линий по одним и тем же координатам (объекты)

> и получается легкое мерцание и неправильная картинка.

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

← →
dmk © (2016-07-06 14:12) [19]

>не могут два потока работающих друг за другом
>выполнить работу быстрее чем один поток.

Хе-хе. Я сделал. И как оказалось может.

>да и последовательно проблемно.
Не проблемно. Сделал логический семафор.

Итого:
6000 линий в одном потоке — 16.3 секунды за оборот в 360°
6000 линий в 12-и потоках — 4.25 секунды за оборот в 360°

Выполняется одно и то же действие. Последовательность соблюдена!!!
А говорите нельзя :)

Вопрос закрыт!

← →
dmk © (2016-07-06 14:21) [20]

Семафор позволяет выполнять в нужной последовательности / очередности (например, как запущены потоки).

← →
vgf (2016-07-06 14:46) [21]

Удалено модератором

← →
dmk © (2016-07-06 14:48) [22]

Удалено модератором

← →
vgf (2016-07-06 14:50) [23]

Удалено модератором

← →
Ринсвинд © (2016-07-06 15:09) [24]

Теоретически, если есть цепочки операторов A и B, то они могут выполниться быстрее в двух последовательно запускаемых потоках, чем в одном потоке в том случае, если этот один поток - главный, и во время операций A и B идет переключение на обработку потока сообщений приложения (Application->ProcessMessages) и эта обработка занимает много времени. Если вспомогательные потоки лишены вызовов Application->ProcessMessages (не знаю, допустимы ли они там вообще, и, скорее всего, даже если допустимы, то сообщения все равно будут обрабатываться в главном потоке), то они могут отработать быстрее.

> vgf (06.07.16 14:50) [23]

Если вы не в состоянии предположить описанный мною вариант, то стоит ли ругаться, да еще выбирая из богатого русского мата такие примитивные выражения?

← →
vgf (2016-07-06 15:47) [25]

Удалено модератором

← →
dmk © (2016-07-06 16:27) [26]

>и будет это ВСЕГДА МЕДЛЕННЕЕ чем если бы поток был один

Странно. Вот результаты:

1 поток - 1200 точек - 3.8 сек.
12 потоков - 1200 точек - 2.02 сек.
Ускорение = 1.8

1 поток - 6000 точек - 16.44 сек.
12 потоков - 6000 точек - 3.84 сек.
Ускорение = 4.28

1 поток - 12000 точек - 32.36 сек.
12 потоков - 12000 точек - 5.89 сек.
Ускорение = 5.49

1 поток - 24000 точек - 63.76 сек.
12 потоков - 24000 точек - 10.34 сек.
Ускорение = 6.16

1 поток - 60000 точек - 158.39 сек.
12 потоков - 60000 точек - 23.94 сек.
Ускорение = 6.61

← →
vgf (2016-07-06 16:36) [27]

это не результаты а фигня.
так как не видно что эн потоков работали ПОСЛЕДОВАТЕЛЬНО

← →
vgf (2016-07-06 16:40) [28]

два потока естествеено нарисуют мазанину быстрее чем один поток.
ЕСЛИ БУДУТ РАБОТАТЬ ПАРАЛЛЕЛЬНО не ожидая друг друга каждый свою половину мазанины.

но если запустить их последовательно то один единственный нарисует бысьрее чем два

Мне их вообще то запускать в определенной последовательности надо, а не последовательно работать один за другим. Работают они параллельно, но с задержкой запуска примерно в 1 мс. Собственно мне это и нужно было. Все нормально. Алгоритм специфический. Подходит не для всех условий. Для другой отрисовки нужно пересматривать алгоритм. Я же не гуру по потокам и не выпендриваюсь, что нашел универсальное решение. Вы что то перепутали. Тут просто опытом обмениваются и идеями.

← →
vgf (2016-07-06 17:23) [30]

Удалено модератором

> dmk © Странно.

Лишние кал-лории в коде + HyperThreading.

> Меняется очередность линий и получается легкое мерцание и неправильная картинка.

Ну да, ну да, - слова очередь (синхронизация) и буфер (экрана) ещё ждут своего глубинного познания. )

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

Но я все равно не понимаю, зачем рисовать одну линию поверх другой да еще тыщу штук?

← →
гне (2016-07-06 18:58) [33]

Удалено модератором

NoUser © (06.07.16 17:25) [31]
Уже все синхронизировано. Не переживайте.

Kilkennycat © (06.07.16 18:43) [32]
Математики гораздо меньше — 1-2% максимум. Остальное отрисовка. Специально замерял.

Откуда столько желчи форумчане? Вроде читаешь посты - все адекватные, а тут на тебе.
Как веслом по голове и почти ни одного дельного совета или намека.

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

> Вы когда нибудь векторные программы видели? Тогда не должно
> быть вопросов.

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

> Математики гораздо меньше — 1-2% максимум. Остальное отрисовка.

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

>Так что (и совершенно без желчи) спрошу тоже:
>Вы когда-нибудь векторные программы видели?
Работаю в множестве векторных программ и пишу свою.

На самом деле мне нужна вся мощь процессора для растеризации.
У адобе также сделано.

У адобе чего? фотошопа? там по-другому. Иллюстратора? там тоже по-другому. Да и не процессор занимается растеризацией.
Впрочем, мне похрен.

>Впрочем, мне похрен.
Зачем влезли и пометили территорию тогда?

← →
tyui (2016-07-06 23:04) [40]

некоторые линии рисуются после тех которые должны быть поверх.

в массиве это лежит все в строгой последовательности и в нужном порядке наложения.

из массива нужно убрать все линии которые не должны быть поверх.
после этого можно сделать не 12, а 120 потоков, которые нарисуют все не в 6 а в 600 раз быстрее. и синхронизировать их не потребуется.

TThread Найти похожие ветки