TThread

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

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

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

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

← →
гнек (2016-07-06 23:09) [41]

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

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

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

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

← →
Германн © (2016-07-07 01:25) [43]

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

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

← →
tyui (2016-07-07 08:37) [44]

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

← →
Palladin © (2016-07-08 17:52) [45]

dmk где твой код то суперский, который беспрецендентно увеличивает производительность последовательной отрисовки в параллельных потоках?

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

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

← →
dmk © (2016-07-09 00:09) [46]

Для неверящих здесь есть EXE:
https://cloud.mail.ru/public/FoS7/vfD8TPKKh

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

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

← →
dmk © (2016-07-09 00:17) [47]

Больше всего меня удивляет хамство. Особенно от мастеров. А кол-во потоков действительно ускоряет. Еще Sapersky в разделе Media демку выкладывал. Она там еще не стерлась вроде.

← →
dmk © (2016-07-09 00:26) [48]

Чтобы уж точно убедится в ускорении поставьте 150 тысяч объектов и запустите.
У меня получилось 268.76 секунды в одном потоке и 45.22 секунды в 12-и потоках.

← →
Германн © (2016-07-09 00:41) [49]

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

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

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

← →
dmk © (2016-07-09 00:57) [50]

Алгоритм простой:

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

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

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

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

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

← →
dmk © (2016-07-09 01:08) [52]

Просто проблема, которую пытался здесь объяснить не корректно была описана.
Потоки рисуют друг за другом 1,2,3,4 и т.д. в первом цикле, а потом иногда перескакивают
в порядке и 5-й лезет вперед 4-го. Нарушается порядок наложения. Для резултата это не важно, а визуально выглядит как слой объектов "прыгает". Вот и хотел синхронизировать последовательность, чтобы потоки не забегали вперед друг-друга. Но дискуссия вылилась в глумление.

← →
Германн © (2016-07-09 01:15) [53]

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

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

← →
dmk © (2016-07-09 01:16) [54]

>Они идут параллельно-последовательно.
Именно так. Но иногда некоторые вырываются вперед или отстают. Тут от системы зависит.
Я и хотел, чтобы они шли в строго запущенном порядке. Приходится флагами их тормозить
и выполнять какое-нибудь действие в цикле ожидания, чтобы потом продолжить отрисовку.

← →
Германн © (2016-07-09 01:19) [55]

Тогда нафига они вообще нужны?

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

>Зачем они нужны?!
У меня файлы растровые по несколько гигабайт. Одним потоком долго обрабатываются.
Множеством - быстро. Линии - это просто замена расчетам. Туда что угодно можно вставить.
Подвернулись линии.

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

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

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

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

>то причем здесь отрисовка?
попрактиковаться

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

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