![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Обработка Bitmap двумя Thread [D7, WinXP]
Igor_K_A © (2007-06-07 05:21:00)Помогите решить проблему: есть Bitmap определенный в главном потоке программы и два дополнительных потока TThread, которые должны обрабатывать битмап парраллельно. Оброботка заключается в простом уменьшении разрешения - картинка бьется на ячейки, в каждой определяется доминирующий цвет и на сжатой картинке исходная картинка представляется уже одним пикселом. Замечен следующий баг: иногда выходная картинка закрашивается черным цветом на произвольную величину..а после этого выпадает "out of system resources". если использовать
MyThread1.Resume;
MyThread1.WaitFor;
MyThread2.Resume;
MyThread2.WaitFor;
вид запуска то все работает без ошибок и глюков, но теряется параллелизм :(
DVM (2007-06-11 00:10:00) [1]
> Pavia © (10.06.07 02:53) [52]
> Дельфи генерирует безобразный код
> Так, что если я перепишу на асм то программа будет работать
> быстрее в большинстве случиев
А если я твой пост перепишу на нормальном русском языке и без ошибок, то прочтя его, ты сам, может быть, поймешь, что ты не совсем прав насчет безобразного кода, который генерит Делфи.
homm (2007-06-11 00:07:00) [2]> [55] Vovan Real
Рад тебя снова видеть.
Vovan Real (2007-06-10 23:57:00) [3]Удалено модератором
Примечание: в зеркало посмотри
Strate (2007-06-10 21:55:00) [4]А можно разбить битмап на 2 битмапа, на каждый зафигачить поток который уменьшит его и потом соединить :)
Но наврено это глупо, т.к. разбивка и склеивание долго буту работать
Германн (2007-06-10 03:01:00) [5]а
> Pavia © (10.06.07 02:53) [52]
Вань. Лучше не позорься! Такое количество грамматических ошибок - явный перебор!
Pavia (2007-06-10 02:53:00) [6]На самом деле надо понять как работают паролельные процессы. Тогда все станет ясно. При работе с паролельными процессами важна синхронизация. Но так как в данном контексте процессы работуют каждый со своими данными, то все должно работать и без нее. Остается только правельно синхронизовать момент старта и остановки процессов.
Как программист со средним знанием асм скажу следующее. Дельфи генерирует безобразный код. Так, что если я перепишу на асм то программа будет работать быстрее в большинстве случиев. А если уж и использовать mmx, то точно прирост будет значительный.
homm (2007-06-08 00:18:00) [7]> чем на свой страх и риск блокировать участки памяти.
Зачем? Все проще. Делим попалам, один поток — один половину, другой — другую.
Eraser (2007-06-08 00:03:00) [8]> чем «проще».
чем на свой страх и риск блокировать участки памяти.
oxffff (2007-06-07 23:27:00) [9]to Igor_K_A
Вы нас всех хоть в соавторах диплома упомините.
Хотя больше на практическое задание смахивает.
oxffff (2007-06-07 23:17:00) [10]Книгу естественно.
oxffff (2007-06-07 23:16:00) [11]Купить?
homm (2007-06-07 23:14:00) [12]> [45] Eraser
процедуру склейки не распаралелишь, к тому-же не понятно, чем «проще».
Eraser (2007-06-07 23:05:00) [13]> [43] oxffff © (07.06.07 22:31)
судя по задаче, автору проще создать 2 отдельных битмапа, а после обработки в отдельных потоках просто склеить их..
oxffff (2007-06-07 22:33:00) [14]
> Поскольку этот буфер статичен (только чтение, используется
> как источник), то обращение к нему НЕ влечет за собой нагрузки
> на когерентность кэша при многоядерности и многосокетности.
>
oxffff (2007-06-07 22:31:00) [15]
> а по-другому никак, GDI функции не потокобезопасны.
Ему нужно просто выдернуть весь буфер.
Поскольку этот буфер статичен (только чтение, используется как источник), то обращение к нему бы влечет за собой нагрузки на когерентность кэша при многоядерности и многосокетности.
homm (2007-06-07 22:30:00) [16]> а толк будет, при условии, что один поток постоянно работает
> с битмапом, а другой, к примеру, только время от времени
> занимается прорисовкой этого битмапа на форме.
Можно не использовать GDI функции для обработки. См. [39]
Eraser (2007-06-07 22:26:00) [17]> [36] DVM © (07.06.07 21:53)
> Только вот толку от многопоточности не будет никакой ибо
> пока один поток залочил битмап, другой будет ждать.
а по-другому никак, GDI функции не потокобезопасны.
а толк будет, при условии, что один поток постоянно работает с битмапом, а другой, к примеру, только время от времени занимается прорисовкой этого битмапа на форме.
homm (2007-06-07 22:23:00) [18]> Как показывает практика можно и без асма сделать не хуже.
> А то и лучше. Ибо оптимизатор делфи генерит код очень хитро
> и лучше чем большинство программеров среднего уровня на
> асме.
Приятно знать, что я не «программер среднего уровня» в этом вопросе. Хотя, признать, без использования MMX как-то увеличить скорость грамотного(!) кода достаточно трудно.
oxffff (2007-06-07 22:07:00) [19]
> Igor_K_A (07.06.07 21:32) [35]
> Eraser, вы гуру! Мой вам респект! Коротко и ясно! Всем остальным
> тоже спасибо... алгоритм обязательно оптимизирую и убиру
> медленные куски
Читать про GetDIBits
DVM (2007-06-07 22:06:00) [20]
> Был бы я на месте преподов, вообще бы оценку не ставил пока
> на ассемблере с использованием mmx бы не реализовал
Как показывает практика можно и без асма сделать не хуже. А то и лучше. Ибо оптимизатор делфи генерит код очень хитро и лучше чем большинство программеров среднего уровня на асме.
> Igor_K_A (07.06.07 18:27) [25]
Код хуже не бывает.
> Bit.Canvas.Pixels[i,j]),
Это чудовищно медленно. Можно написать раз в 100 быстрее работающее.