![]() |
| ||
|
|
Новости |
Поиск |
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;
вид запуска то все работает без ошибок и глюков, но теряется параллелизм :(
oxffff (2007-06-07 16:36:00) [41]
> homm © (07.06.07 16:30) [15]
> > картинка бьется на ячейки и они не связаны.
>
> Физически? Логически? Автор придет, тогда поспоришь, любитель
> пофлудить.
И это все что можешь сказать?
тогда читай oxffff © (07.06.07 15:12) [7]
tesseract (2007-06-07 16:34:00) [42]
> Физически? Логически?
Если два ядра, то они явно будут разбросаны по памяти процессов/ядер, т.е физически.
homm (2007-06-07 16:30:00) [43]> картинка бьется на ячейки и они не связаны.
Физически? Логически? Автор придет, тогда поспоришь, любитель пофлудить.
oxffff (2007-06-07 16:22:00) [44]
> Это что по твоему, как не чтение?
картинка бьется на ячейкии они не связаны.
homm (2007-06-07 16:20:00) [45]> Внимательно читал?
Вполне. «каждой определяется доминирующий цвет». Это что по твоему, как не чтение?
oxffff (2007-06-07 16:20:00) [46]Это уже кандидат на многопоточный алгоритм.
А что там у автора не получается. Не известно.
oxffff (2007-06-07 16:17:00) [47]>Оброботка заключается в простом уменьшении разрешения - картинка >бьется на ячейки, в каждой определяется доминирующий цвет и на сжатой >картинке исходная картинка представляется уже одним пикселом
Внимательно читал?
homm (2007-06-07 16:11:00) [48]> 1. Читай про тенденции процессоростроения к многоядерность
Давай я тебе так намекну, без тенденций? Есть догадка, что автор пытается распаралелить процесс потому что он у него жутко торозит. А тормозит потому что Get\SetPixel. Сколько ядер тебе понадобиться, чтобы такой алгоритм работал хотя-бы со скоростью грамотно написаного для одного ядра на ассемблере? 128? 1024? Вперед, за тенденцией, удачи.
oxffff (2007-06-07 15:14:00) [49]Далее читать про разделяемый кэш и когерентность кэшей.
oxffff (2007-06-07 15:13:00) [50]Кэш-память
Кэш-память представляет собой быстродействующее ЗУ, размещенное на одном кристалле с ЦП или внешнее по отношению к ЦП. Кэш служит высокоскоростным буфером между ЦП и относительно медленной основной памятью. Идея кэш-памяти основана на прогнозировании наиболее вероятных обращений ЦП к оперативной памяти. В основу такого подхода положен принцип временной и пространственной локальности программы.
Если ЦП обратился к какому-либо объекту оперативной памяти, с высокой долей вероятности ЦП вскоре снова обратится к этому объекту. Примером этой ситуации может быть код или данные в циклах. Эта концепция описывается принципом временной локальности, в соответствии с которым часто используемые объекты оперативной памяти должны быть "ближе" к ЦП (в кэше).
Для согласования содержимого кэш-памяти и оперативной памяти используют три метода записи:
Сквозная запись (write through) - одновременно с кэш-памятью обновляется оперативная память.
Буферизованная сквозная запись (buffered write through) - информация задерживается в кэш-буфере перед записью в оперативную память и переписывается в оперативную память в те циклы, когда ЦП к ней не обращается.
Обратная запись (write back) - используется бит изменения в поле тега, и строка переписывается в оперативную память только в том случае, если бит изменения равен 1.
Как правило, все методы записи, кроме сквозной, позволяют для увеличения производительности откладывать и группировать операции записи в оперативную память.
oxffff (2007-06-07 15:12:00) [51]Tо homm
1. Читай про тенденции процессоростроения к многоядерность
2. Читать про кэш память
3. Думать перед ответом.
4. Не засорять форум. ;)
oxffff (2007-06-07 15:02:00) [52]
> homm © (07.06.07 14:40) [5]
> > Поясни свой ответ
>
> Мда… :)
>
> Распаралеливать нужно только когда все остальные способы
> увеличения производительности испробованы. К чему разносить
> на другой проц код, который делает лишнюю работу?
>Шишь он получит увеличение производительности на опирации
>интенсивной работы с памятью.
Не соозволите ли доказать сие свое утверждение?
homm (2007-06-07 14:40:00) [53]> Поясни свой ответ
Мда… :)
Распаралеливать нужно только когда все остальные способы увеличения производительности испробованы. К чему разносить на другой проц код, который делает лишнюю работу?
oxffff (2007-06-07 14:36:00) [54]
> homm © (07.06.07 13:59) [3]
> > Многоядерность?
>
> Шишь он получит увеличение производительности на опирации
> интенсивной работы с памятью. Только если у него кривой
> алгоритм, излишне нагружающий процессор. Но в этом случае
> действуют не распаралеливанием, а улучшением алгоритма.
Поясни свой ответ
homm (2007-06-07 13:59:00) [55]> Многоядерность?
Шишь он получит увеличение производительности на опирации интенсивной работы с памятью. Только если у него кривой алгоритм, излишне нагружающий процессор. Но в этом случае действуют не распаралеливанием, а улучшением алгоритма.
oxffff (2007-06-07 09:00:00) [56]
> ЮЮ © (07.06.07 08:03) [1]
> Чисто интереса ради, какого размера твой Bitmap, что для
> такого элементарного, по сути, преобразования потребовальсь
> доп.потоки, да ещё два?
Многоядерность?
ЮЮ (2007-06-07 08:03:00) [57]Чисто интереса ради, какого размера твой Bitmap, что для такого элементарного, по сути, преобразования потребовальсь доп.потоки, да ещё два?