Это смотря какие треды.

Трэды рулят. Пусть не на 300%, но рулят.

Дык чего стало-то? В чем + а в чем - сего разделения? Какой MPLayer лучьше будет?

повышает качество скорости воспроизведения

Наверно это поможет на P200MMX крутить все фильмы DivX (в Linux под mplayer), а не только те, что в низком разрешении идут.

А так - не знаю, Arpi вроде гордился, что нету buggy threads в mplayer.

А фраза в subj смешная до безобразия...

А что такое "качество скорости воспроизведения" ?

А что такое "качество скорости воспроизведения" ?

Интерсное заявление: качество скорости воспроизведения... Разве у скорости есть качество? :)

2Saper (*) (2002-03-19 13:45:36.0)

>А фраза в subj смешная до безобразия...

А как бы ты посмотрел на формулировку "повышает скорость воспроизведения на 300%" ?

Мне например, плеер который в 3 раза быстрее чем нужно проигрывает фильм на..р не нужен! :)

Попробовал собрать (Celeron 433, 256 Mb, X 4.1, ATI Rage128, Spring слегда обезображенный Сизифом) вот некоторые наблюдения...
Гуевина не собирается. Ну да ладно, я и без нее проживу.
Далее, компиляция слетает на драйвере drx3, тоже лечится отключением в конфиге (но уже насторяживает).
Потом, при конфигурации была заявлено, что есть поддержка xvidix (согласно документации, threads работают на нем и на xv), на деле оказалость, что с xvidix облом, но есть работа с vx. Уменьшение загрузки камня таки наблюдалось, приблизительно процентов на 10.
С sdl облом и с dga облом. При всем этом mplayer 0.60 работает с этими драйверами на ура.

Вот и замечательно .. Долго ждал , когда же наконец кто-нибудь форкнет Mplayer . А когда этим "кто-то" оказался Ник -- в двойне радостно .. Да ещё и с эксклюзивной фичей ... Остаётся только пожелать удачи ...

ОЧЕНЬ надеюсь , что у MplayerXP не будет глупых ограничений на распространение бинарников и мы сможем в скорости лицезреть этот проект в наших любимых дистрибутивах .Так же очень хотелось бы , дабы вокруг этого проекта создалось доброжелательное и спокойное community , где бы не было места хамству и Манечке Величечко аля Арпад , Капучино и ко .

Удачи , Ник !

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

> ОЧЕНЬ надеюсь , что у MplayerXP не будет глупых ограничений на распространение бинарников

Дык зря радуешься. Данный форк не решает той проблемы. Абсолютно не решает.
Чтобы ее решить нужно не фичи добавлять, а переписывать все лиценцированные места
для начала придумав свои алгоритмы, а потом повесить на них GPL-совместимую лицензию.

У Ника - каша в голове!

http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006213.html

Nick Kurshev mplayer-dev-eng@mplayerhq.hu
Sat, 16 Mar 2002 22:19:18 +0300

...
> Yes! I found out that threading core provides UNREAL performance.
> Yes! I watched 540x288@25fps DivX-MPEG4 movie without frame dropping
> (real-timely) on Cel1-266 with simultaneously working gcc.
> (vidix+ffdivx+xp+double).
...
> I know mplayerxp is buggy for now and won't work on SMP.
...
Что называется, no comments...

С др. стороны, поражает реакция Arpi:
http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006232.html
> We disagree here.
> Let's make MPlayerXP, and show people that your idea works and is better
> than mine.
...
> of course you can use mplayerhq cvs, just use another module name than
> 'main'. let's import as mplayerxp:
...
> I'm not against your project - i like it. But I don't accept threads in
> 'old' mplayer.
...
> evolution is simple.
> make mplayerxp. if it will be really better, both users and other developers
> will move to mplayerxp and probably i'll also follow them.
> but currently we don't believe in threaded player.

Согласитесь, не многие лидеры проектов способны на такую...

> Эти господа нелюбители ниток как-то забывают, что в машине может быть не один быстрый процессор,

Есть другая категория господ, которые забывают, что на фрюниксах нет ни одной
программы, которая использовала бы threads и в тоже время обладала той же надежностью, что
и проги без threads. Использование threads на фрюниксах при кажущейся простоте и удобности
сразу добавляет ей 1) нестабильность и капризность 2) повышенное потребление памяти и проца.

Я допускаю, что ситуация может измениться с принятием ngpt за стандарт, но тогда
пропадет главный аргумент - масштабируемость на несколько процессоров ;)
Вот и вся любовь...

2anonymous (*) (2002-03-19 17:35:51.0)


>Есть другая категория господ, которые забывают, что на фрюниксах нет ни >одной программы, которая использовала бы threads и в тоже время обладала >той же надежностью, что и проги без threads. Использование threads на >фрюниксах при кажущейся простоте и удобности сразу добавляет ей 1) >нестабильность и капризность 2) повышенное потребление памяти и проца.

Вы видимо наслушались криков Ирси на плохие нити в линуксе. И видимо никогда не слышали о apache 2.x. Кстати как использование нитей отражается на стабильности программы ? Вы это где-то прочитали, или определили экспирементально ? Поделитель плз. с общественностью.

> Вы видимо наслушались криков Ирси на плохие нити в линуксе.

Плохой пример. Тот человек понятия не имеет ни об нитях, ни о линуксе.

> И видимо никогда не слышали о apache 2.x.

Слышал и ключевое слово здесь - опять же "слышал";) Я говорю о реально работающих
(production quality) программах. У Вас есть опыт реальной эксплуатации apache-2
на реальном сервере?

> Кстати как использование нитей отражается на стабильности программы ?

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

Вот интересный момент, вернее пример улучшений от автора форка:

"I can run gcc simultaneously with mplayerxp and have realtime playback"

Почему он меня заинтересовал - да потому, что mplayer и так на данный момент
является самым быстрым и самым качественым плейером на линуксе, и, я бы смело
добавил - вообще на всех платформах быстрее его нет.

Так вот, разрешите описать свой опыт. Я пускаю на линуксе кодирование DVD -> mp4
и при этом синхронно в реальном времени проигрываю в стандартном mplayer'e записываемый
фильм, контроллируя качество записи... При этом ни одного фрэймдропа, ни одного
"застывания" кадров или прерывания звука. По-моему лучшей рекламы его скорости не найти...
Спрашивается, что им еще нужно?

2anonymous (*) (2002-03-19 19:04:01.0)

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

PS 2All а разьве oracle не юзает нити ???

А что апач 1х не на нитках? да и большинство фтп серверов тоже на нитках. Незнаю как с mplayer но в серверных прогах работающих одновременно со многими клиентами использование threads дает очевидные преймущества даже на одном проце. Так что не надо поднимать вой зачем threads нужны вообще. Вопрос в другом нужны ли они в mplayer?
То что threads могут повысить скорость в 3 раза на одном проце не верю, на трех может быть.

2anonymous (*) (2002-03-19 19:51:36.0):
Насчет Апача:
1. Никто еще не юзал всерьез второго Апача. Мне кажется, что под фрюниксами он
НЕ прозвучит.
2. Апач на Винде всю жизнь нитчатый, потому что там нельзя иначе. В принципе,
переход на нити как попытка унификации различных платформ может в таком случае
даже уменьшить гемморой разработчикам.
3. ВЕБ-сервер - один из немногих примеров, когда применение ниток оправдано.

Ник же запысал кипятком, получив на ОДНОПРОЦЕССОРНОМ Целероне прирост
производительности от ниток на 300 % ! Более того, его патч ВООБЩЕ НЕ ИДЕТ на SMP!!

Ему указали, что 1) он неправ; 2) просто у него слишком слабая машина, и он мог бы
добиться бОльшего прироста, поиграв параметрами алгоритма.

И пожелали удачи.

Почитай дискуссию, начатую сообщением
http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006255.html

> А что апач 1х не на нитках?

Я рад, что ты наконец сделал для себя это открытие ;(

> да и большинство фтп серверов тоже на нитках.

О, дает, чувак. Врет и не краснеет.

> но в серверных прогах [...] threads дает очевидные преймущества

Да шел бы ты лесом, а вернее назвал бы хоть одну такую серверную прогу.

> 3. ВЕБ-сервер - один из немногих примеров, когда применение ниток оправдано.

Ой, не согласен. Сервера построенные на простой модели select/poll делают
нитяных по всем параметрам. Устойчивость нитяных - ниже всяких критериев,
потребление ресурсов - наоборот, на высоте ;)

это все пурга! а вот кто нить собрал этот xp? Ругается при сборке на синтаксические ошибки :(((

2anonymous (*) (2002-03-19 20:32:54.0):
>> 3. ВЕБ-сервер - один из немногих примеров, когда применение ниток оправдано.
>
> Ой, не согласен. Сервера построенные на простой модели select/poll делают
> нитяных по всем параметрам.

Что это за "простая модель"? Т.е. процесс спит на селекте, после чего
форкается?

Судя по всему имеется в виду конечный автомат на select/poll. Т.е. получаем "нити" без нитей. Извините, не умей сказать красиво.

_Кажется_, быстрее этого ещё ничего не придумали (за исключением платформозависимых решений типа KEVENT у FreeBSD). Поправьте, если ошибаюсь.

Losiki

to: anonymous (*) (2002-03-19 20:29:13.0)

squid ??

2anonymous (*) (2002-03-19 22:21:15.0) aka Losiki
> конечный автомат на select/poll.
Каждое слово в отдельности понятно, а вместе - нет.
Очевидно, имеется в виду реализация юзеровских ниток через конечный автомат.

> Т.е. получаем "нити" без нитей.
"нити" без нитей получить нельзя, если только речь идет не о юзеровских нитях.
Юзеровские нити, действительно, быстрее ядерных - если речь не идет об SMP.

Собственно, я об этом и говорю - Ник ухитрился получить бенефит в 300%
от ядерных ниток на однопроцессорной тачке. Ясно, что он плохо понимает, что делает.

> > конечный автомат на select/poll.

> Каждое слово в отдельности понятно, а вместе - нет.

Я думаю речь идет о реализации серверов по однопроцессной схеме без тредов. Хороший пример - thttpd, обрабатывающий все запросы в одном процессе, и при этом обгоняющий апач по производительности. Сервер ожидает траффика на соединениях через select и хранит в памяти состояние каждого соединения. Другое дело что по такой схеме можно реализовать очень ограниченное число задач.

2anonymous (*) (2002-03-19 17:35:51.0) Гм... Вообще у меня (по Вашим меркам) очень слабая машина. И старая. Но с 2-мя процессорами (наследие прошлого). И проиграть на ней фильм в layer4 просто на одном проце (PPro200) кажется малореальным. А на 2 уже можно попробовать... Хотя неподдержка SMP (о чем написал сам Ник) останавливает. Подождем - посмотрим...

Вдогонку к моему предыдущему письму - я малость не понял ситуевину (стоило почитать переписку поподробнее - спасибо Die-hard за ссылки) а потом уж ругаться. В общем, был не совсем прав, кажись...

2maxcom (*) (2002-03-19 23:11:02.0):
>Я думаю речь идет о реализации серверов по однопроцессной схеме без тредов.
Ну да, я тоже так понял. Я это и имел в виду под "реализацией юзеровских
ниток".

> Другое дело что по такой схеме можно реализовать очень ограниченное число задач.
Почему? Не вижу принципиальной разницы, вызывать ли функцию в процессе, или
оборачивать вызов в pthread_create. Первое даже проще, не надо о синхронизации
заботиться...

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

2anonymous, который говорит что thread тормозит и жрет память.

fork () создает полную копию процесса в памяти !!! (выделил 100 мегов, форкнулся - выдели еще 100 (для тех кто в танке)) отличаются процессы PID, PPID, возвращаемым fork'ом значением.

Нити в свою очередь гораздо более гибкий инструмент, который позволяет избежать повторного выделения памяти, отличный механизм IPC (или ITC :))

Гопода, неужто никто из вас не учился на ВМиК ?

2Dimai (*) (2002-03-19 23:42:21.0):

> Но с 2-мя процессорами (наследие прошлого). И проиграть на ней фильм в layer4 просто на
> одном проце (PPro200) кажется малореальным. А на 2 уже можно попробовать...

Немного оффтопик - но, все же, SMP и нитки не связаны напрямую. Под любым Юниксом
будем чувствовать себя гораздо более сухо и комфортно с процессами/форками,
IMHO. Под Win32, извините - форка нету...

Попрошу воздержаться от ответа флеймеров/дураков.

2anonymous (*) (2002-03-20 00:09:02.0)
А кто тебе сказал, что при fork() _сразу_ будет создаваться 100% копия приложения???? Неужели в ВМиК этому учат 8-[]

Хотел бы послушать матерные слова про Oops, и про то, какой он был бы рулез, если бы не треды.

2anonymous (*) (2002-03-20 00:09:02.0):
Пока писАл предыд. свою мессагу, твоя прилетела...

> который говорит что thread тормозит и жрет память.
Он противопоставлял thread'ы НЕ процессам, а локальным процедурам, или
просто longjump'ам.

> Гопода, неужто никто из вас не учился на ВМиК ?
В каком году ты учился? А я-то думал, на ВМиК людям классику хотя бы читали...

Хошь, завтра пообщаемся (домой мне пора)?. Тема process vs. threads меня сейчас
опять живо заинтересовала.

Какие на фиг серверы?!? SMP - чтоб числодробильней заниматься. А всякий лузерский отстой навроде веб-серверов и файлопомоек на SMP крутить - извращение.

Неужто теперь на ВМиК так хуёво учат, что даже забывают рассказат про copy-on-write? До чего страну дерьмократы довели... :)

CommuniGatePro вполне себе на нитях и стабилен

2wom: стабилен... угу... не под фрюниксами, хотя после появления FreeBSD 4.0 действительно стало жить гораздо легче...
Кстати это именно его разработчики грят что нормальной реализации посиксовых тредов нет ни в одном фрюниксе...

Хорошо. Пусть нити будут г...но. Но для серверов.
Вы фильмы на сервере смотреть собрались?
Уж не знаю как у вас, но под linux'ом mpg у меня
смотрится с 14-20% загрузкой проца при разрешении
640x480.
Зато divx жрет 76-82% на 320x240 можно аналогичную
широкоэкранку посмотреть, загрузка будет 93-97
процентов (имеется ввиду фильмы, где много движения).
mplayer 6.0

Берем теперь винды 98se.
640x480 - 93%
320x240 - 36-43%
(загрузку проца смотрел на waterfall pro 2.99)

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

Обсуждение бессмысленное.

С другой стороны, если все будут отказываться от нитей,
они начнут дохнуть. Слава богу никто не отказывается.

> Уж не знаю как у вас, но под linux'ом mpg у меня > смотрится с 14-20% загрузкой проца при разрешении > 640x480. > Зато divx жрет 76-82% на 320x240 можно аналогичную > широкоэкранку посмотреть, загрузка будет 93-97

Вот что я вам скажу - _огромное_ значение имеет видеокарта. Личный опыт: машинка Duron-750, памяти дофига, Xfree 4.1.0. Кино DivX 640x480, mplayer 0.60 Видеокарточка PCI S3-Virge: 95% загрузки процессора Видеокарточка Radeon VE, драйвер X11: 30% загрузки Тот же радеон, драйвер XV: менее 15% загрузки

Т.е. замена _только_ видеокарты в итоге дала выигрыш в 6 раз ;-)

> Сервера построенные на простой модели select/poll делают
нитяных по всем параметрам.
>Устойчивость нитяных - ниже всяких критериев,
>потребление ресурсов - наоборот, на высоте ;)

Глупый ты. Это все зависит только от рук разработчика. Если ты нитку в сосотоянии ожидания гоняешь в вечном цикле, то не удивляйся, что она проц жрет.
Select/poll не проще нитей/форков.
И как у людей J2EE сервера работают, ума не приложу. Там же сплошные трэды.

Интересно, а кто-нибудь читал про то, как он предлагает нити эти заюзать? А то лично я в подобном ПО нити вижу только в одном месте - в разделении задач декодирования и визуализации/управления. Думается, что за счёт этого можно за счёт оптимизации буферизации добиться более плавного показа...

парни вы тут ругаетесь и доказываете что то
а кто нибудь из вас хоть строчку для video playe или http сервера
написал ?

Uman

RTFM copy-on-write

Ну, у венгров то компилятор "не тот", то треды "глючные".
Известно, что плохому программисту компилятор мешает :)

Где по-русски почитать о нитях и сопировании-при-записи?

2Antichrist (*) (2002-03-20 00:35:28.0):
> А всякий лузерский отстой навроде
> веб-серверов и файлопомоек на SMP крутить - извращение.
В принципе, согласен. Но - так уж повелось, хорошогруженные веб-серверы
и файлопомойки лепят на SMP. Идеологически такие серверы на SMP хорошо
ложатся.

>Я думаю речь идет о реализации серверов по однопроцессной схеме без 
>тредов. 

Оно самое.

С тем, что число задач(где это применимо) ограниченно - не 
согласен. Просто требует более тщательной планировки, в отличие от тредов, где "сел и поехал" ;)

Losiki

Shadow, это проблемы конкретной реализации (линуксовой в частности), а не трэдов вообще.