Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TThread

Страницы: 1 2 3 4 >
dmk © (2016-07-05 22:15:00)
Всем привет, подскажите пожалуйста, возможно ли заставить выполнить потоки в строгой последовательности и в то же время, чтобы простоев (ожиданий) не было.
В данный момент неизвестно, какой поток придет первый, а какой последний.
Delphi XE6.

dmk (2016-07-09 10:25:00) [1]
Германн © (09.07.16 01:40) [58]
Выше ссылка на EXE, который работает и ускоряет. Если у вас хотя бы 2 и более реальных ядра. Хотя на 2-х ядрах ускорение минимально.

dmk (2016-07-09 10:18:00) [2]
>то причем здесь отрисовка?
попрактиковаться

Kilkennycat (2016-07-09 07:36:00) [3]

> dmk © (09.07.16 01:22) [57]

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

Германн (2016-07-09 01:40:00) [4]

> dmk © (09.07.16 01:22) [57]
>
> >Зачем они нужны?!
> У меня файлы растровые по несколько гигабайт. Одним потоком
> долго обрабатываются.
> Множеством - быстро.

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

dmk (2016-07-09 01:22:00) [5]
>Зачем они нужны?!
У меня файлы растровые по несколько гигабайт. Одним потоком долго обрабатываются.
Множеством - быстро. Линии - это просто замена расчетам. Туда что угодно можно вставить.
Подвернулись линии.

Германн (2016-07-09 01:19:00) [6]
Тогда нафига они вообще нужны?

dmk (2016-07-09 01:19:00) [7]
>Имхо, алгоритм был придуман/реализован неправильно.
Он работает.

dmk (2016-07-09 01:16:00) [8]
>Они идут параллельно-последовательно.
Именно так. Но иногда некоторые вырываются вперед или отстают. Тут от системы зависит.
Я и хотел, чтобы они шли в строго запущенном порядке. Приходится флагами их тормозить
и выполнять какое-нибудь действие в цикле ожидания, чтобы потом продолжить отрисовку.

Германн (2016-07-09 01:15:00) [9]

> dmk © (09.07.16 01:08) [52]
>
> Просто проблема, которую пытался здесь объяснить не корректно
> была описана.

Имхо, алгоритм был придуман/реализован неправильно.

dmk (2016-07-09 01:08:00) [10]
Просто проблема, которую пытался здесь объяснить не корректно была описана.
Потоки рисуют друг за другом 1,2,3,4 и т.д. в первом цикле, а потом иногда перескакивают
в порядке и 5-й лезет вперед 4-го. Нарушается порядок наложения. Для резултата это не важно, а визуально выглядит как слой объектов "прыгает". Вот и хотел синхронизировать последовательность, чтобы потоки не забегали вперед друг-друга. Но дискуссия вылилась в глумление.

Германн (2016-07-09 01:06:00) [11]

> Поскольку потоки идут параллельно

Кто сказал что потоки идут параллельно?
Они идут параллельно-последовательно. На двухпроцессорной системе два потока могут идти параллельно, если правильно написать код. А вот три потока уже никак!
Ну разве что ОС обеспечит некую "псевдопараллельность". Но на скорость это уже либо не повлияет, либо изменит в некую сторону, но незначительно.

dmk (2016-07-09 00:57:00) [12]
Алгоритм простой:

1. Распределяем отрисовку между потоками (1-й - 0.99, 2-й 100-199 и т.д.)
2. Создаем и запускаем потоки
3. В Execute цикл 0..359.
4. Выполняем первую отрисовку и ждем флага True об окончании отрисовки всеми потоками
5. Сбрасываем флаги
6. Идем рисовать дальше по циклу

Поскольку потоки идут параллельно, то ожидание флага минимально.
На маленьком кол-ве объектов скорость увеличивается всего в 1,5-2 раза. На большом кол-ве скорость увеличивается практически до кол-ва реальных ядер.

Германн (2016-07-09 00:41:00) [13]

> Чтобы уж точно убедится в ускорении

Да никто в общем-то и не сомневается, что использование доппотоков способно увеличить именно скорость выполнения неких алгоритмов при использовании многопроцессорных/многоядерных систем. Вопросы только к самому алгоритму. А его не видно без кода.
Ну и
> tyui (07.07.16 08:37) [44]
>
> чего сразу юмор?

А с чего 120 потоков будет быстрее чем 12?

dmk (2016-07-09 00:26:00) [14]
Чтобы уж точно убедится в ускорении поставьте 150 тысяч объектов и запустите.
У меня получилось 268.76 секунды в одном потоке и 45.22 секунды в 12-и потоках.

dmk (2016-07-09 00:17:00) [15]
Больше всего меня удивляет хамство. Особенно от мастеров. А кол-во потоков действительно ускоряет. Еще Sapersky в разделе Media демку выкладывал. Она там еще не стерлась вроде.

dmk (2016-07-09 00:09:00) [16]
Для неверящих здесь есть EXE:
https://cloud.mail.ru/public/FoS7/vfD8TPKKh

Поставьте кол-во линий 15-25 тысяч и запустите сначала в одном потоке, потом в множестве. Там есть 2 кнопочки (360°). Включите прозрачность, чтобы текст лучше видеть.
Немного не допилено, но в целом работает.

>Palladin © (08.07.16 17:52) [45]
А код вам зачем? Вы же мастер!

Palladin (2016-07-08 17:52:00) [17]
dmk где твой код то суперский, который беспрецендентно увеличивает производительность последовательной отрисовки в параллельных потоках?

и необходимо еще привести последовательный код, с которым было сравнение

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

tyui (2016-07-07 08:37:00) [18]
чего сразу юмор?
линий будет меньше, перекрываться они не будут.
рисовать любую можно никого не дожидаясь

Германн (2016-07-07 01:25:00) [19]

> С какого перепуга быстрее?
>

Пардон. Понял юмор про 120 потоков.. :)

Германн (2016-07-07 01:22:00) [20]

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

С какого перепуга быстрее?

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »