Столкнулся с задачей (кодирование видео), сильно грузящей как винт, так и процессор.
Точнее, есть основной поток, который делает всякие полезные вещи, его не трогаем.
Из этого потока получаются данные для обработки в больших количествах и лопатятся в другом потоке.
Рассматриваем ситуацию с неодноядерной (-процессорной) системой.
Возникают 2 проблемы:
1. Если винт не очень быстрый, то в определенный момент возникает bottleneck в производительности винта
2. Если винт быстрый, то в определенный момент возникнет ситуация, что второй поток не будет успевать за первым.

Что я думаю:
В случае с двумя ядрами (процами) все ясно и ничего (кроме оптимизации алгоритмов) не сделаешь.
Что будет с 3+ ядрами?
1. Вынести запись на диск в отдельный поток. Вопрос синхронизации и прочее не стоит. Меня интересует будет ли все так же тормозить или нет? Предполагается, что когда я пишу на диск инфу, больше никому диск не нужен. Другими словами — будут ли спокойно работать остальные потоки, пока "пишущий" сбрасывает на диск информацию?
2. Разделение на потоки алгоритма кодека. Тут, конечно, вопрос больше в "алгоритмы", но все же. Кодеки бывают разные, в данный момент меня интересует JPEG. Я в деталях алгоритма не шарю, у меня есть сорцы и знаю, что он кусками кодирует. Есть ли там зависимость линий друг от друга? То есть, можно ли спокойно разделить кадр на 2,3... потока?

Надеюсь, объяснил популярно А то вроде уже получил хорошие результаты, но клиенты хотят еще больше и лучше

Здравствуйте, CyberDemon, Вы писали:


CD>Что я думаю:
CD>В случае с двумя ядрами (процами) все ясно и ничего (кроме оптимизации алгоритмов) не сделаешь.
CD>Что будет с 3+ ядрами?
CD>1. Вынести запись на диск в отдельный поток. Вопрос синхронизации и прочее не стоит. Меня интересует будет ли все так же тормозить или нет? Предполагается, что когда я пишу на диск инфу, больше никому диск не нужен. Другими словами — будут ли спокойно работать остальные потоки, пока "пишущий" сбрасывает на диск информацию?
Условно да. Когда ты вызываешь WriteFile запись на диск на самом деле не производится, а производится запись в буфер, который асинхронно сбрасывается на диск. Тут возможно имеет смысл воспользоваться функциями асинхронного I/O (WriteFileEx и иже с ней)
На практике все не так радужно обычно, поскольку если например другой поток обратился к памяти, которая в свопе, то диск не раздвоится и оба получат пенальти по производительности. Еще многое зависит от интеллектуальности соответствующего контроллера в чипсете и/или его дров.

CD>2. Разделение на потоки алгоритма кодека. Тут, конечно, вопрос больше в "алгоритмы", но все же. Кодеки бывают разные, в данный момент меня интересует JPEG. Я в деталях алгоритма не шарю, у меня есть сорцы и знаю, что он кусками кодирует. Есть ли там зависимость линий друг от друга? То есть, можно ли спокойно разделить кадр на 2,3... потока?

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

Здравствуйте, CyberDemon, Вы писали:

CD>Столкнулся с задачей (кодирование видео), сильно грузящей как винт, так и процессор.
CD>1. Вынести запись на диск в отдельный поток. Вопрос синхронизации и прочее не стоит. Меня интересует будет ли все так же тормозить или нет? Предполагается, что когда я пишу на диск инфу, больше никому диск не нужен. Другими словами — будут ли спокойно работать остальные потоки, пока "пишущий" сбрасывает на диск информацию?

Согласен с ответом Sergey Chadov

CD>2. Разделение на потоки алгоритма кодека. Тут, конечно, вопрос больше в "алгоритмы", но все же. Кодеки бывают разные, в данный момент меня интересует JPEG. Я в деталях алгоритма не шарю, у меня есть сорцы и знаю, что он кусками кодирует. Есть ли там зависимость линий друг от друга? То есть, можно ли спокойно разделить кадр на 2,3... потока?

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я не понял связи JPEG с кодированием видео. Если имеется в виду, что отдельные кадры видео переводятся в JPEG, то, может, вместо того, чтобы распараллеливать кодирование в JPEG, имеет смысл распараллелить разные кадры ?
Тот же MotionJPEG — каждый кадр есть картинка JPEG. Параллелить кадры смысла и возможности нет, потому что я заранее не знаю, когда поступит следующий кадр. Точнее, знаю, но он еще не существует. То есть, надо один кадр "растягивать".