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

А такие слова как Copy On Write и страничная виртуальная память тебе не о чем не говорят?

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

Угу. Ктото похоже вместо лекций распивал пивко ;-)

> А всякий лузерский отстой навроде веб-серверов и файлопомоек на SMP крутить - извращение.

Иногда складывается ощущение что вы когда говорите - слегка бредите :-)

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

> Почему?

т.к. планирование переключений нужно проводить "руками" и не любая задача позволит это делать с разумными для разработчика трудозатратами.

Да уж. Помнится, дядя Вова много плохих слов про линьюховые и бздёвые треды сказал... При этом, правда, он хвалил OS X, так что, возможно, не все плохие слова по делу были сказаны...

Так тебе ещё и по ру-у-у-усски?!? Ну ну. Тогда кушай Робачевского... IMHO, ничего больше и нету.

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

Да не бредю я. Я честно говорю - на писюке вовсе не процессор узким местом оказывается, так что от SMP иногда даже лишний оверхед возможен. Особливо это касается файлопомойки, где процессору ВООБЩЕ делать нечего.

> Я честно говорю - на писюке вовсе не процессор узким местом оказывается, так что от SMP иногда даже лишний оверхед возможен.

В теории конечно все возможно, но на практике добавление второго камня ускоряет работу веб-сервера с динамикой и СУБД (типичная провайдерская задача). Разделить задачу на две машины конечно возможно, но не всякая задача безболезненно параллелится и потом две машины это дороже, чем два проца.

2Antichrist (*) (2002-03-20 17:04:01.0):
Надо же, впервые, наверное, согласен с тобой по всем пунктам.

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

И появилась эта современная мода именно благодаря сантехникам IMHO.

В журнале видел кластер в одном стандартном корпусе (8 матерей впихнули) :)

oops весьма даже весь из себя весь так использующий треды вдоль
и поперек что аж страшно. Другое дело что у него скоро в каком-нибудь
system requirements будет значится solaris ;)

На писюке, опять же, не дороже... Я заметного прироста не наблюдал даже на жабских приложениях (Resin, PostgreSQL), а вот когда PostgreSQL утащил на другую машину - всё сразу заплясало и запрыгало. Причём, утащил на вдвое более тормозную машину...

> а вот когда PostgreSQL утащил на другую машину - всё сразу заплясало и запрыгало.

Это ты имел проблемсы с scheduler. Много running processes за счет поганой жабы. Получите дулю.
Очень выручает O(1) scheduler на 2.5.х в таких случаях или последние 2.4.19-pre-aa ядра.

Oops, говоришь классная вещь и на нитях? Дык где она классная? На соплярисе.
Там нитяные проги неплохо (относительно) работали всегда. Но ты забыл, что речь тут шла
про фрюниксы. На бсде еще туда-сюда, на линуксе oops oops...

Поскольку ни один защитник нитей не привел образей _стабильной_ и скромной к ресурсам проги
на нитях для фрюниксов, мое утверждение остается в силе.

> Уж не знаю как у вас, но под linux'ом [...] Зато divx жрет 76-82% на 320x240
> можно аналогичную широкоэкранку посмотреть, загрузка будет 93-97
> Берем теперь винды 98se.
> 640x480 - 93%
> 320x240 - 36-43%

Во ламерье! У меня аж челюсть выпала от такого прогона. Да главное кого он в пример
приводит? Сраную виндень, на которой вообще фильмы смотреть невозможно без содрогания
от ужаснейшего блевотного качества.

Так вот, ламерочек, слушай сюда. Mplayer на моем линуксе полноэкранный фильмец divx
показывает с загрузкой CPU 6%. Изумительное качество aka real dvd quality. Уж не знаю сколько
оно жрет CPU на винде, но потеря кадров, сбои в звуке и общее дерьмое качество - факт,
который говорит сам за себя.

> К сожалению, современная мода диктует сторительство серверов на именно на SMP.

Откуда такое заключение, и если оно верно, то почему с сожалением и причем тут мода?
Мода модой, а деньги во все времена считать умели.

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

Плохо _Вас_ на ВМиК учили :) Сэр что нибуть про CoW слышал ?


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

А оверхеды да синхронизацию которая из за такой "гибкости" практически
становится ручной ? Собственно откуда и растут ноги о "нестабильности"
нитевых прог - дело не в нестабильности как таковой а в обилии ручной
работы по синхронизации и как следствие - запутанный код со скрытыми ошибками - кроме того сказывается что на нитевую модель складываются
старые (single context - ориентированные) куски кода которые народу лень
переписывать наново ...

/Другой

Ну вы даете...

Ребятки, вот вы так мило рассуждаете о том, что Ник неправ, а, между тем, хоть кто-нибудь прочитал README к этому самому mplayerXP, чтобы понять, в чем фишка-то?

Кадры практически любого видео делятся на два вида: на ключевые и на промежуточные. Ключевой кадр полностью кодирует все, что находится в данный момент на экране, в то время как промежуточные вносят в него лишь инкрементальные изменения (и так, пока не появится новый ключевой кадр). Важно то, что на декодирование ключевого кадра уходит больше времени, чем на декодирование промежуточного, при том, что время, за которое декодирование должно быть проведено, всегда одинаково (=1/fps). Идея Ника состоит в том, что пока идет декодирование промежуточных кадров от начала одного ключевого, одновременно можно заниматься декодированием _следующего_ ключевого. Это сглаживает общую загрузку процессора, понижая, таким образом, общую планку, давая возможность смотреть видео без выбрасывания кадров на более слабых процессорах, чем это было возможно ранее. В README это малость поподробнее расписано.

p.s. А Arpi -- просто типичный кретин. Потому что это никак не нитевая революция, а всего лишь дополнительная отключаемая (более того, выключенная по умолчанию!) примочка, которую он не хочет взять только из-за того, что она (о боже!) использует нити, тем самым порочя святой сан безгреш...безтредного mplayer'а.

Как то даже странно читать тут про какие-то мифические глюки тредов в linux. Возьмем к примеру всеми любимый MySQL, хороший пример мультитредового сервера. И где он глючит/падает? Больше 2 лет прекрасно работает не SMP машине и не жужжит. ИМХО все дело в руках, можно и без тредов любую программу уронить :)

PS: Удачи Ник!

/lelik

2 anonymous (*) (2002-03-20 14:50:56.0) >Где по-русски почитать о нитях и сопировании-при-записи?

книга "легендарного" КЮБ'а - rulezzzzz.virtualave.net/rtos.ps.gz

>Разделить задачу на две машины конечно возможно, но не всякая задача >безболезненно параллелится и потом две машины это дороже, чем два >проца.

2 да 4 уже нет

2ikm (*) (2002-03-21 12:03:20.0):
> хоть кто-нибудь прочитал README к этому самому mplayerXP, чтобы понять, в чем фишка-то?
Читали, читали.
А ты сам-то читал, что Нику на его README ответили?:
http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006279.html

2anonymous (*) (2002-03-21 00:34:03.0):
>> К сожалению, современная мода диктует сторительство серверов на именно на SMP.

> Откуда такое заключение
Частное мнение

> почему с сожалением и причем тут мода?
IMHO:
После того, как Сантехники в начале 90-х продемонстрировали преимущества
SMP для поддержки серверов (субъективно - Саны между делом держали серверы,
да к тому же народ на них числогрызные задачи гонял, а сравнимые по
производительности Альфы, делавшие Саны на числодробилках в разы, с трудом
держали один НФС(!) сервер), все заключили, что именно это - правильный
путь. И технологии пошли развиваться в этом направлении. Мода!

В результате сейчас, на фактически единственной выжившей платформе (РС),
все стремяться распараллелить все, что можно (а чаще - что нельзя). Но
как раз на Интеле, как заметил Антихрист несколько выше, процессор не
является узким местом. Значительно выгоднее IMHO было бы построить кластер
из дешевых процов, работающих независимо и получающих запросы от железяки,
которая смотрит в сеть, раздает запросы и следит за балансом нагрузки.
Или еще как-нибудь, - словом, подумать надо было, а не тупо SMP городить.

>Поскольку ни один защитник нитей не привел образей _стабильной_ и
>скромной к ресурсам проги
>на нитях для фрюниксов, мое утверждение остается в силе.

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

2Havoc (*) (2002-03-21 17:58:22.0):
> кривые трэды - это личная проблемя фрюниксов.
Сколько копий сломано вокруг этой темы!

И, все же, кроме эмоций - чем они тебе не нравятся?
Только тем, что и для ниток, и для процессов используется один шедулер?

А что в этом кривого?

2Havoc
> Т.е. сделайте нормальные трэды и будет вам софт, их использующий.
Таким образом Вы даете понять что в Мастдае прекраснейшая реализация
тредов, и вообще лучше Зёбры(ms windows) нет коня.

Не будьте смешным - Вам за это не платят.

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

Оно и видно, что твои мозги уже перенапряглись. Ну переставил ты слагаемые, и что? Сумма осталась прежняя.
Говорилось про слабую связку ``нитяные проги+фрюниксы``. Что тебе еще не понятно?

> А Линус и компания свою реализацию высокопарно называют самой лучшей.

Если б ты сидел рядом, то получил по лбу тупому. Где Линус говорил? Ссылку давай, пиздунок.

За доки на русском - спасибо. а где можно найти доки на английском о thread, желательно чтобы не очень академично, ближе к пионерам )))

2Die-Hard: во все нормальных ОС использование тредов не приводит к гимороям типа излишней требовательности к ресурсам и к снижению стабильности... Только на фрюниксах...

>Таким образом Вы даете понять что в Мастдае прекраснейшая реализация
>тредов,

Можно и открытым текстом :)
Одна из лучших.

VMS-ники. молчать ! :)

>и вообще лучше Зёбры(ms windows) нет коня.
>Не будьте смешным - Вам за это не платят.

Ну а список косяков NT шных тредов можно озвучить ? :)

2Irsi (*) (2002-03-22 11:15:52.0) Интересно какие это излишние требования к ресурсам? Какие снижение стабильности? Сколько ими (threads) пользуюсь и первый раз слышу...

Коли руки кривые - доступ к данным правильно обеспечить не могут да статические переменные используют, так потом и начинают кричать - треды это плохо, глюкаво работают. (И это только так к примеру, для начала)

Линуксовые треды работают и не надо говорить что в 2.4.х они глюкавят - для 2.2.х я бы еще может прислушался а так фигня полная.

Интересно сколько из тех кто кричит что треды во 'фрюниксах' или Unix вообще фигня, реально ими занимался, и не день-два а от а до я...

2tvn: имхо мнению разработчиков CGP о фрюниксовых тредах можно доверять...

2Irsi: А линк подкинеш? Не совсем понятно чем это им "фрюниксовые" треды так носолили;)

2tvn: линк не подкину - в списке рассылки пробегало. там было сказано что нормальные посиксовые треды на х86 реализованы только в нте и солярке...

Arpi сказал очень верно:
"У нас есть примеры нитяных плэеров - xine, avifile. Но почему юзвери выбирают mplayer?
Да потому что он быстрее, качественнее, стабильнее. Нити - в морг."

Да - как написано на главной страничке mplayer:
it's became a nice thread since

Как я понял - для народа главное - это пофлеймить и совсем не важно
скачивал ли кто-нибудь 0.0.0 или нет ;)

Первое - mplayerxp будет жить и развиваться не смотря ни на что!!!

По поводу всего остального:

Нити - это нормальное решение для любой real-time системы.
Нити - это единственное что не хватает mplayer'у сечас:
http://MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006206.html

Реация Arpi - совершенно нормальная - mplayer был сорздан не с нуля
Arpi - тоже в свое время очень долго убирал нити из базового проекта
(не совсем ясно - но по моему это был avifile):
http://MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006220.html
И естественно когда я предложил ему их возродить - это было против его концепций.

По поводу технической стороны:

- нить не добавляет нагрузки на процессор - по крайней мере у меня всегда около 20
процессов сидит так-что еще +1 процесс ничего не решает.
- время переключения задачи пренебрежимо мало по сравнению со временем декодирования
кадра или это уже не процессор ;)
- нить позволяет отойти от real-time декодирования и декодировать кадры когда процессор свободен
а не когда дело доходит до pts.
- mplayer будет терять кадры на любом проце - были сообщения что он теряет их на
Athlon-1700+nvidia. И дела не всегда в тяжелом декодировании - бывают еще и блокировки
во время чтения носителя (плохой CDROM) - нити решают и эту проблему.
- среднее нагрузка на проц (ave bench) не говорит не о чем в mplayer.
у меня при просмотре DivX-MPEG4 720x480@30 fps средняя загрузка проца 30%
(Duron-700+RadeonVE) но mplayer теряет кадры. Для mplayer актуальна - max bench
в то время как ave bench актуальна для mplayerxp. Даже если cpumeter показывает
5% - это еще не гарантирует отсутствие потери кадров в mplayer - это средняя величина
просчитанная за несколько кадров - как правило 10-15 - просто потому что все эти мерилки
делают замеры 1 - 3 раза в секунду чтобы не грузить собой проц.

По поводу - почему все выбирают mplayer - потому же почему и я - не из-за скорости
а из-за того что он просто показывает ВСЕ подряд в отличии от других player'ов
А заоптимизить тот-же avifile до уровня mplayer - дело 2-3 месяцев (собственно
вся оптимизация в mplayer начиналась с меня и перетащить уже готовые нароботки
не составило бы труда)

2Irsi: Ну вот рассмешил - на NT нормальные posix thread. К сожалению posix в NT реализован как одна большая задница, в том числе и треды (не путать с их родными нитями, там хоть что-то от чего плакать не хочется;) )

Я вот и скачал и посмотрел, Ник ;).

Субъективно, при всём уважении: too buggy. У меня так и не получилось посмотреть, практически _ни_один_ фильм нормально.

Хотелось просто сравнить скорость воспроизведения двух плейеров: mplayer нормально работал и работает с 0.1xxx чего-то там. mplayerxp (даже если не обращать внимание на корку при перемотке) показывает следующим образом: проигрывает кусочек длиной x<1 сек, возвращается назад на величину чуть меньшую x, проигрывает снова и т.д. Получается дёрганое воспроизведение каноном ;). Сразу скажу: не копался. Единственное что сделал, заменил -O3 на -O2. Процессор: P266. FreeBSD. Карточка на Mach64 со свежими GATOS'овскими драйверами. -vo xv.

Losiki

>Я вот и скачал и посмотрел, Ник ;).

>Субъективно, при всём уважении: too buggy. У меня так и не получилось посмотреть, практически _ни_один_ фильм
>нормально.
0.0.0 ;)

>Хотелось просто сравнить скорость воспроизведения двух плейеров: mplayer нормально работал и работает с 0.1xxx
>чего-то там. mplayerxp (даже если не обращать внимание на корку при перемотке) показывает следующим образом:
>проигрывает кусочек длиной x<1 сек, возвращается назад на величину чуть меньшую x, проигрывает снова и т.д.
>Получается дёрганое воспроизведение каноном ;). Сразу скажу: не копался. Единственное что сделал, заменил -O3 на
>-O2. Процессор: P266. FreeBSD. Карточка на Mach64 со свежими GATOS'овскими драйверами. -vo xv.
Юзай vidix

в 0.0.0 еще не реализован frame dropping - в 0.0.1 уже все будет значительно лучше.
дергание (screen juddering) вызывается недостаточной тягой проца.
(Против общей MMX оптимизации я никогда не спорил :)

Если энтузиасты все-таки найдутся еще, вот мои ключики:
mplayerxp -vo [*]vidix -vc ffdivx -xp -double -fs -zoom filename.avi

(лично использую -vo vesa:vidix вместо -vo xvidix просто потому
что так еще и tvout работает - на скорость это не влияет)

Фильм 540x288@25fps идет на Cel1-266 без потери кадров при
параллельно запущенном gcc.

Правда карточка Rage3D - 2MB - т.е. в видео память влезает всего 7 кадров
что не очень-то и много для упреждающего декодирования.

По поводу всего остального:
-vo xv - ипользует буффер из 10 кадров в основной памяти - что очень
сильно торомозит декодирование за счет еще одного memcpy
-vc divxds и все остальное - просто медленные кодеки.

по поводу багов - пока замечен только один серьезный:
видео остает от звука на n/fps
n - количество кадров упреждающего декодирования

т.е. если стоит 32MB видео памяти то в нее влазит около 48 кадров
среднего фильма - получаем, что видео отстает на 1.92 секунды от звука
(В настоящий момент работаю и над этой проблемой!)

2nick:

Ну, в общем, точки расставлены - mplayer форкнулся, и будущее покажет.

Все же, мне было бы интересно услышать на оставленный без ответа контраргумент
Daniel'а Egger'а:
http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006279.html

Или ответ был, и я его просто не нашел?

Интерес мой - чисто академический, не обижусь, если (во избежание новой волны флейма)
ответа не будет :)

Удачи!

2Irsi (*) (2002-03-22 11:15:52.0):
> во все нормальных ОС использование тредов не приводит к гимороям типа излишней
> требовательности к ресурсам и к снижению стабильности.
Это я и имел в виду, говоря об "эмоциях".

Чесслово, везде приводит и снижает. Просто на "нормальных ОС" нет альтернативы ниткам.

> Нити - это нормальное решение для любой real-time системы.
Неправда.

> Нити - это единственное что не хватает mplayer'у сечас
Их хватает у xine, хватает ровно настолько, чтобы быть unusable ;)

> нить не добавляет нагрузки на процессор - по крайней мере у меня всегда около 20
> процессов сидит так-что еще +1 процесс ничего не решает

Текущее ядро без O(1) scheduler хорошо работает с не более 5-10 рабочими процессами.

> mplayer будет терять кадры на любом проце

Смотря чем нагружена машина. Я никогда не видел потерь кадров начиная с duron-600,
если работает один mplayer.

mplayerxp-0.0.0

>Ну, в общем, точки расставлены - mplayer форкнулся, и будущее покажет.

>Все же, мне было бы интересно услышать на оставленный без ответа >контраргумент Daniel'а Egger'а:
>http://www.MPlayerHQ.hu/pipermail/mplayer-dev-eng/2002-March/006279.html
>Или ответ был, и я его просто не нашел?
http://www.mplayerhq.hu/pipermail/mplayer-dev-eng/2002-March/006351.html

>Интерес мой - чисто академический, не обижусь, если (во избежание >новой волны флейма) ответа не будет :)

А вообще нефиг всяких-там флеймеров слушать!
Egger далеко не ключевая фигура в mplayer. Он даже не хотел вникать
в идею и гнал всякую чушь.

Postavil sebe etot mplayerxp, klassnaya chtochka, no k sozhaleniu poka eche s oshibkami. Interesno, a Nick (avtor programmy) russkii vrode by ... Interessno, a na cyrix 200 mozhno budet teper' tyanud' divx ili net?

Kastate, eche takoi vopros ... Kak zagruzhat' plug-iny dlya divx 5 i divx 4 dlya nego??? kak ih dobovlyat'???

Announce: mplayerxp-0.0.1

SUBJ :)

stranno, a ya toka 0.0.0 postavil segodnya zhe

2nick (*) (2002-03-22 18:29:00.0):

>> Или ответ был, и я его просто не нашел?
> http://www.mplayerhq.hu/pipermail/mplayer-dev-eng/2002-March/006351.html
Неубедительно.

> Он даже не хотел вникать в идею и гнал всякую чушь.
IMHO наоборот.
Он вник в идею и все правильно говорил.

Впрочем, все это субъективно и, вообще, флейм. Посмотрим, что получится
в результате.:)

2 anonymous (*) (2002-03-22 18:21:24.0)
а что у вас за кретерий unusability ?
у меня xine на p2-233 с с&t 2mb video показывает точно
такой же performance как и с mplayer. причем ecли mplayer
запушен с -ffdivx у него начинаенся приличный frame drop (50 -80 %)
но вообщем оба они use 90-95 % CPU но frame drop все равно есть
(из за audio/video synhronisation )

Uman

s /с -ffdivx/ без -ffdivx