какая выгода от 2-х процессоров (ядер)?

man mencoder | grep threads

далеко не все кодеки поддерживают многопоточность.

один из универсальных методов - запускать два mencodera параллельно.

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

Преимущества от нескольких ядер ощутимы только в следующих ситуациях: 1. Несколько процессов требуют ресурсов ЦПУ - тогда они распределяются на разные ядра и обрабатываются быстрее, чем на одном ядре. 2. Софт написан с использованием потоков. Тогда потоки распределяются по ядрам и получается то же преимущество.

спасибо. про потоки у менкодера с кодеком по-умолчанию, толку всё равно нету, что с -ovc lavc -lavcopts threads=1, что с threads=2(4,8) одинаковое кол-во кадров пережатия. причём загрузка процесса в top не превышает 100-103% и следовательно общая загрузка системы не превышает 60-70%. блин, хочется реально увидеть хоть где-нибудь практическую востребованность 2х ядер у пользователя десктопа, может кто знает реальное приложение, которое сможет утилизовать cpu? сгодятся даже ссылки на скриншоты где будет видно, как один процесс утилизует около 200% в top.

запусти сборку ядра с параметром make -j4

p7zip (только сжатие, распаковка идет на 1 ядре)

в принципе еще есть pbzip2 , bzip2 компрессор, правда оно стандартный вход не сжимает ...

в общем - программа должна поддерживать поточность, если не поддерживает - получите работу на 1 ядре, утилизация 2 и более ядер будет возможна только для других процессов, ну и для компиляции - make -j2 (и более)

>>спасибо. про потоки у менкодера с кодеком по-умолчанию, толку всё равно нету, что с -ovc lavc -lavcopts threads=1, что с threads=2(4,8) одинаковое кол-во кадров пережатия.

какой кодек? Я жму с помощью x264, на Athlon 3800+ - все отлично распаралеливается. Да и vcodec=mpeg4 тоже вроде держит распаралеливание. Может просто сам mplayer собран криво, например использует *.so от ffmpeg, которые собраны без pthreads? :)

А игры используют многоядерность?

> А игры используют многоядерность?

А это наверное надо у разработчиков игр спрашивать...:) Реальное положение дел в том, что очень немногие разработчики пишут многопоточные приложения. Им так проще и дешевле :)

> А игры используют многоядерность?

Млять, ну сколько можно рождать подобные вопросы.

- петька, приборы?
- 20.
- че 20?
- а че приборы?

> сгодятся даже ссылки на скриншоты где будет видно, как один процесс утилизует около 200% в top.

http://www.koptev.ru/ramozhor.jpg ;)

http://www.koptev.ru/mencoder.jpg - вот mencoder перегоняет видео.

>Вообще программы должны быть написаны так, чтобы их можно было паралелить. А вообща, даже если проги это не поддерживают, то прелесть хотя бы в том, что можно всякие системные процессики фоновые скинуть на другое ядро, а первое будет обсчитывать то, с чем ты работаешь.

легко сказать, да не легко сделать. Так как языки типа C или Паскаля в своей сущности не "ориентированы" на распараллеливание. С помощью них можно его реализовать, теоретически. Но это во многих случаях невероятно трудно.

Уже много раз обсуждалось, что с приходом многоядерных процессоров, функциональные языки вырвутся на первое место.

PS

>запусти сборку ядра с параметром make -j4

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

xvid держит, но салируемость у него пока еще слабая. x264 хорошо многопоточность держит.

>>блин, хочется реально увидеть хоть где-нибудь практическую
>>востребованность 2х ядер у пользователя десктопа

запусти while(1);
это один проц, а второй рисует курсор мышки. удобно

спасибо большое, увлекательные скрины!

проигрывать видео и музыку лучше на 2-х ядерном процесоре. другие процессоры любял иногда отожрать всё что им дадут. только видео будет без рывков и звук без прерываний.