Интервью с Энди Таненбаумом

>Первый пункт был очевиден, а что во втором (мне просто интересно)?

А его уже частично коснулись - это как раз _сложность_ дизайна взаимодействия драйверов (по сравнению с понолитом)

> этот абзац портит всю статью и впечатление от этого неприятное :-(

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

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

если уж на то пошло то сделали бы от себя факультативное введение или послесловие, где и выразили что считают нужным, а не разрывали бы текст своими 5 копейками

> А может точка зрения неправильная? - сходи почитай про аспектно-ориентированое програмирование.

а может тоже сходишь куда-нибудь?

Запомни дурачек раз и навсегда.

Фанатизм - удел исключительно линуксоидов, которые смешивают в одну кучу технику и идеологию и из этого делают религиозную секту.

Винду люди используют как кульман и токарный станок для выполнения задач даже несвязанных с IT. (К примеру хирург не считает лохом тех, кто неможет аппендицит вырезать, так почему я его должен ламером и дебилом считать если он умеет только в ворде всякие доки набивать?)

А вот линуксоиды именно РАБОТАЮТ с линуксом и почему то хотят чтобы за это ковыряние им еще и деньги платили

Дело не только в кол-ве инструкций. Дело в том, КАКИЕ это инструкции. И сколько циклов они выполняются. В х86 есть несколько инструкций, которые предназначены для смены таблиц страниц, дескрипторов задач и пр. Но СКОЛЬКО ЦИКЛОВ они кушают! И как они при этом сбрасывают все процессорные кэши!

Соббсно, об этом я и спрашивал - так ли дороги аналогичные инструкции на других платформах, как на интеле?

Полностью разделяю это мнение. Собственно команда-то -- одна. SWPCTX. Сводится к запихиванию всех регистров в в один стек и випихиванию содержимого регистров из другого. Естественно, что сейчас мне будет трудно найти тот фрагмент кода, бо человек с этими кусками кода и соответствующими книжками уже далеко в Штатах, да и сам я давно не видел живого VMS (к моему великому сожалению). В тех книжках по ваксовому ассемблеру, что стоят у меня на полке, число тактов на команду не приводится. Но, как пишет Вахалия в "книжке с кактусом" (в русском переводе -- "UNIX изнутри", вышла в той же серии, что и Танненбаумовские кники), переключение контекста на VAX не занимало много времени по сравнению со всем остальными архитектурами. Вахалия подробно разбирает ваксовую схему как основу для реализации "классического" юниксового ядра.

А кеши всегда сбрасывать приходится. И конвейеры тоже. Без этого--никуда. Да. Таков неизбежный оверхед за использование многозадачной ОС.

>Дело не только в кол-ве инструкций. Дело в том, КАКИЕ это инструкции. И сколько циклов они выполняются. В х86 есть несколько инструкций, которые предназначены для смены таблиц страниц, дескрипторов задач и пр. Но СКОЛЬКО ЦИКЛОВ они кушают! И как они при этом сбрасывают все процессорные кэши!

Полностью разделяю это мнение. Собственно команда-то -- одна. SWPCTX. Сводится к запихиванию всех регистров в в один стек и випихиванию содержимого регистров из другого. Естественно, что сейчас мне будет трудно найти тот фрагмент кода, бо человек с этими кусками кода и соответствующими книжками уже далеко в Штатах, да и сам я давно не видел живого VMS (к моему великому сожалению). В тех книжках по ваксовому ассемблеру, что стоят у меня на полке, число тактов на команду не приводится. Но, как пишет Вахалия в "книжке с кактусом" (в русском переводе -- "UNIX изнутри", вышла в той же серии, что и Танненбаумовские кники), переключение контекста на VAX не занимало много времени по сравнению со всем остальными архитектурами. Вахалия подробно разбирает ваксовую схему как основу для реализации "классического" юниксового ядра.

А кеши всегда сбрасывать приходится. И конвейеры тоже. Без этого--никуда. Да. Таков неизбежный оверхед за использование многозадачной ОС.

> Запомни дурачек раз и навсегда

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

Сегодня первый раз после годичного перерыва увидел винду, пришлось знакомому ставить. Я просто офигел... После установки в системе нет ни нормального браузера, ни нормального почтового клиента, ни просмотровщика картинок, ни просматровщика видео, ни графического редактора, ни нормального проигрывателя медиа и mp3, нету файрволла, нету нормального текстового редактора, нечем посмотреть PDF, нечем посмотреть оффисовые документы, нету спеллчекера, нету переводчика, нету нормальной качалки файлов, нету нормального файлового менеджера, нету архиваторов, нечем записать болванку, нету системы бекапа, нету icq клиента, нету irc клиента ..... Ничего нет, как на этом ***** работать-то? Ужас, бррр...

> тот же bluetooth, USB стек
>Надо, надо говорить. Вот врать не надо. Особенно про bluetooth,
>предъявите-ка корни линукса в коде, изначально
>Netgraph-ориентированном, не сочтите за труд.

Легко, http://bluez.sf.net, качни свой Netgraph'овский и проверь
в нем комментарии и заодно весь код...

> Сегодня первый раз после годичного перерыва увидел винду, пришлось знакомому ставить....

All inclusive часто бывает хуже индивидуального обслуживания. Да и нафига платить за 5 дисков, если потом все равно приходится качать обновления (считай, целиком пакеты). В дисте-то они не работают...

Зы: 70 процентов перечисленного есть. И рвет линуксовые поделки как тузик грелку.

>Сегодня первый раз после годичного перерыва увидел винду, пришлось знакомому ставить. Я просто офигел... После установки в системе нет ни нормального браузера, ни нормального почтового клиента, ни просмотровщика картинок, ни просматровщика видео, ни графического редактора, ни нормального проигрывателя медиа и mp3, нету файрволла, нету нормального текстового редактора, нечем посмотреть PDF, нечем посмотреть оффисовые документы, нету спеллчекера, нету переводчика, нету нормальной качалки файлов, нету нормального файлового менеджера, нету архиваторов, нечем записать болванку, нету системы бекапа, нету icq клиента, нету irc клиента ..... Ничего нет, как на этом ***** работать-то? Ужас, бррр...

А это Windows from scratch! ;))) А xочешь поднять функциональность - топай на www.download.com , например...

Первый вопрос тебе лет то отроду сколько?

И после вот этой фразы
>>После установки в системе нет ни нормального браузера, ни нормального почтового клиента, ни просмотровщика картинок, ни просматровщика видео, ни графического редактора, ни нормального проигрывателя медиа и mp3

дополнительный вопрос- ты что куришь? И где такое берешь?
Или это от годичного использования линуха так крышу сносит?

Не, ну ты че, не понял, он WIn3.1 ставил. По описанию - точно она!

"Аааа ты в этом смысле..."(c)анекдот

Так он бы сразу так и сказал, а то я с перепугу на соседнюю тачку, куда вчера XP Prof, ставил побег смотреть, чтобы убедиться, что IE,Outlook,midiapleyer и остальное мне после бутылки арманьяка не привидилось.
Уффф, нельзя же так пугать, я ж уже немолодой, сердчишко то и сбойнуть могет:))

> Так он бы сразу так и сказал, а то я с перепугу на соседнюю тачку, куда вчера XP Prof, ставил побег смотреть, чтобы убедиться, что IE,Outlook,midiapleyer и остальное мне после бутылки арманьяка не привидилось.

"нет ни _нормального_ браузера, ни _нормального_ почтового клиента, ..., ни _нормального_ проигрывателя медиа и mp3"

Или вы на полном серьезе считаете, что читать почту аутглюком в наше время - не самоубийство? Или, может быть, что IE - это браузер, а не просто "смотрелка" HTML с интерфейсом Notepad?

>А его уже частично коснулись - это как раз _сложность_ дизайна взаимодействия драйверов (по сравнению с понолитом)

А вот это уже пиздёж. (Прости Господи, чего не скажешь)

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

Скорее не миних а амеба. Самое прикольно что к 91 году этот проект был закончен. Но почемуто не пользовался популярностью, народ не оценил переписанное с нуля микроядро? Не недумаю, скорее народ не оценил аппетиты Профессора - штука(!) баксов за ядро! Вот и сдохла амеба так что сам профессор не может забыть свой позор.

А вот тут какой-то япошка портанул Minix на L4 микроядро:

http://research.nii.ac.jp/H2O/L4minix.html

Мужик то этот Энди может и правильный. Что совсем не помешало ему состряпать лицензию на Minix так чтобы сторонние патчи не входили туда. Вот сам во всем и виноват. Хотя нельзя отрицать сильное влияние Minix на Linux - навряд ли есть сильное влияние Таненбаума на Торвальдса. Да и просил Энди порядка 200 баксов за свою систему. Короче сам виноват ;)

>Насколько я знаю, не только в ИО - вообще любое переключение
>контекста - очень дорогая вещь для проца. В частности, на х86.
>Поэтому при любой более-менее заметной нагрузке микроядро >
>(теоретически) должно "проседать" по сравнению с монолитным - ведь
>околоядерные модули (файловая система, драйвера, подсистема памяти и
>пр.) начинают как безумные перекидываться сообщениями и ядро (и
>проц) только тем и занимается, что переключает контексты этих задач.
>Собственно, именно эта стОимость переключения привела к тому, что в
>NT кусок GDI был внесен в ядро.

Cтоимость перкеключения контекста, говорите?
Ну и чему же она равна на x86 _В ЧАСТНОСТИ_ ?

Брамм П., Брамм Д. Микропроцессор 80386 и его программирование.
М.: - Мир, 1990


Утверждает 16 мс для 80386 16 МГЦ!!!

Да, это конечно СВЕРХНЕПРИЕМЛЕМО !!!!

А вот ещё для любителей Monolithic VS Microkernel:

http://i30www.ira.uka.de/teaching/pastcourses/lecture.php?courseid=11

Читать pdf или ps

Знаете, господа, не в глюках виндовс дело. Вот ключевое:

>TanaT: Вы соответственно используете в работе UNIX, а не
>Windows?
>Энди Таненбаум: Именно UNIX.
>TanaT: Ваше пристрастие к UNIX связано с открытостью исходного >кода многих ее версий?
>Энди Таненбаум: Мне совершенно все равно - открыт код или нет. >Это меня не касается ни с какой стороны. Даже если бы Windows >была системой с открытым исходным кодом, а UNIX, по-прежнему,
> - секретом AT&T, я бы в любом случае выбрал UNIX. Она просто
>лучше.

Жила-была одна девочка... короче, сама виновата.

:-)

<<Может кто знает как в Москве можно найти книжку...>>В книжных магазинах.Например сам видел ее в Библиоглобусе. Причем на русском языке.

зюыюЖ система может быть любой. только не виндовз.
(машина может быть любого цвета, если этот цвет -- черный (с)
Форд, вроде)

<<А xочешь поднять функциональность - топай на www.download.com , например...>> А в линуксе это все прямо в дистрибутиве...

<<А xочешь поднять функциональность - топай на www.download.com , например...>> А в линуксе это все прямо в дистрибутиве...

А ты налей и отойди.

2kraw (*) respect.

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

если не ошибается наш профессор читающий нам "организация эвм и систем" то на интеле - 200 тактов на переключение контекста

//llelik

"А кеши всегда сбрасывать приходится. И конвейеры тоже. Без этого--никуда. Да. Таков неизбежный оверхед за использование многозадачной ОС. "

Ну и зачем тебе сбрасывать кеши в многозадачной ОС?

Действительно, если первые версии Линукс работали на 386 процессоре с хорошей скоростью, то современные требуют очень больших рессурсов. А зачем?

Получается, что Линус Торвальд опирался на чужой опыт (это вообще-то нормально), тогда почему его стали приравнивать к богу (это не нормально). Собираюсь в знак протеста переходить на *BSD систему. А то от Линукса запашок какой-то пошел.

>> Сегодня первый раз после годичного перерыва увидел винду, пришлось знакомому ставить....

>All inclusive часто бывает хуже индивидуального обслуживания. Да и нафига платить за 5 дисков, если потом все равно приходится качать обновления (считай, целиком пакеты). В дисте-то они не работают...

>Зы: 70 процентов перечисленного есть. И рвет линуксовые поделки как тузик грелку.

ИНОГДА. Например запись дисков. Особенно "хорошо" приходится когда у винды проблемы с поддержкой конкретного пишущего привода. Пока винтукейник танцует с бубном вокруг попытки поставить драйвера в Linux можно записать все, что нужно.

Про неработающие дистрибутивные пакеты: действительно не работают? Все?

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

Ok. Нет проблем.

Исходное утверждение было:

>А его уже частично коснулись - это как раз _сложность_ дизайна взаимодействия драйверов (по сравнению с понолитом)

Не буду говорить за Mach, ибо не знаю как оно там устроено внутри, но с точки зрения L4 это элементарно. Драйвера взаимодействуют только через IPC. Один драйвер является сервером для другого. Драйвера могу передвать запросы по цепочке, наподобие как это сделано в Windows NT. Достаточно взглянуть на исходный код, чтобы увидеть что взаимодействие _элементарно_. Конечно, для такой системы важен дизайн, но в результате получается стройное, логичное и красивое решение.

Что касается монолита, то видимая лёгкость дизайна взаимодействия драйверов, на деле оборачивается тратой кучей ресурсов на то, чтобы заставить всё это вместе работать. И ещё большее время уходит на то, чтобы переделать. Изменения в одном драйвере, ведут к модификации кучи сопутствующих драйверов.

> дополнительный вопрос- ты что куришь? И где такое берешь? > Или это от годичного использования линуха так крышу сносит?

Читай внимательно мой пост. Я же писал, что в винде нет "_НОРМАЛЬНОГО_" браузера, _НОРМАЛЬНОГО_ почтового клиента. А если ты пользуешься OE и слушаешь музыку Windows Media PLayerom, так это ни что иное, как твоя личная родовая травма, или у твоего отца хрен не стоял, и тебя зачали в пробирке спермой землеройки...

Так я просил доказательства и пояснения от уважаемого Ss. Мне тоже кажется, что при микроядре драйвера делать должно быть легче - интерфейсы жестче определены. Мне так казалось (спорить не буду, не ядерщик). А вот Ss утверждает, что драйверам в моноядре жить проще. Именно это и вызывает сомнения...

2svu

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

Ну на бумаге то все просто ;) а вот как например в данном случае иметь асинхронный IPC в том же L4 (в отличае от HURD(Mach) где IPC асинхронный в L4 ,AFAIK, он вроде бы только синхронный).

Собсно так гладкие на бумаге модели обрастают ненужными сущностями (из за своей теоретической жесткости)

>>"А кеши всегда сбрасывать приходится. И конвейеры тоже. Без этого--никуда. Да. Таков неизбежный оверхед за использование многозадачной ОС. "

>Ну и зачем тебе сбрасывать кеши в многозадачной ОС?

Имелись ввиду внутренние процессорные кеши и конвейеры.

Ну, это вечная проблема дизайна - как продумать хорошо, чтобы не было потом плохо:)

Только стОит ли использовать "размытый" дизайн (с заведомо избыточным чистом степеней свободы и и нечетко определенными интерфейсами), чтобы "предупредить" подобные ситуации? Мне кажется - не стОит.

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

Кстати, если народ в L4 не предусмотрел асинхронные вызовы - может, за этим стояла какая-то МЫСЛЬ? Может, те, кому нужна асинхронность, эту МЫСЛЬ не поняли? По своему опыту знаю - так очень часто бывает...

>>>"А кеши всегда сбрасывать приходится. И конвейеры тоже.
>>>Без этого--никуда. Да. Таков неизбежный оверхед за использование >>>многозадачной ОС. "

>>Ну и зачем тебе сбрасывать кеши в многозадачной ОС?

>Имелись ввиду внутренние процессорные кеши и конвейеры

А ты думаешь в современном x86 процессоре ничего не предусмотренно
для увязывания данных в кеше и задачи ???
Зачем же тогда сначало контроллер кеш-памяти "переехал" в процессор,
а затем и сама кешь-память ? Не только и не столько из-за
недостаточной пропускной способности шины памяти.
А ,во многом, из-за возможности (поверь мне - она используется !)
управления кешом в соответствии с контекстом выполнения,
что даст (и дает) выигрыш в РАЗЫ БОЛЬШИЙ, чем увеличение пропускной способности шины процессор-память.
Зачастую даже prefetch для данных происходит автоматически,
а уж для инструкций он давно есть.

Другое дело, что в 80386 этого нет и Линус , когда делал 1.x,
о таких вещах мог и не знать. Но сейчас такая экономия - сродни экономии на спичках. Пусть в микроядерной архитектуре переключение
контекста происходит чаще - зато там структуры данных меньше и
,следовательно эффективность их кеширования больше, чем у монолита.

А нет такого, что вынося все сервисы из ядра, мы получим целый лес, порубленный на спички?:) Ведь в сущности весь этот выигрыш (он внутреннего процессорного кэша) теряется при смене контекста. Соббственно, сам кэщ памяти, возможно, и остается. Но в чем я уверен, в том, что:

1. Таблицы страниц перегружаются (потому как они, вроде, per process)

2. Все команды, которые были в конвейере уже разложены на кусочки и наполовину выполнены на теневых регистрах - идут в помойку. И начинается prefetch и пережевывание новых команд - с нуля. Если они окажутся в где-то кеше L2 - хорошо. А если нет - процессор стоит в сторонке и курит. Ждет подсистему памяти. При этом вероятность того, что команд в кэше нет - очень немаленькая. Команды-то от другого процесса. Этот процесс невесть когда давно был исполняем. С тех пор кэши уже 10 раз могли все о нем скинуть...

Да, совсем забыл - с данными примерно тоже. Только процу их пережевывать не надо перед употреблением. Но ждать подсистему памяти в случае отсутствия данных в кеше - все равно придется.

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

>>>>"А кеши всегда сбрасывать приходится. И конвейеры тоже. >>>>Без этого--никуда. Да. Таков неизбежный оверхед за использование >>>>многозадачной ОС. "

>>>Ну и зачем тебе сбрасывать кеши в многозадачной ОС?

>>Имелись ввиду внутренние процессорные кеши и конвейеры

>А ты думаешь в современном x86 процессоре ничего не предусмотренно >для увязывания данных в кеше и задачи ??? >Зачем же тогда сначало контроллер кеш-памяти "переехал" в процессор, >а затем и сама кешь-память ? Не только и не столько из-за >недостаточной пропускной способности шины памяти. >А ,во многом, из-за возможности (поверь мне - она используется !) >управления кешом в соответствии с контекстом выполнения, >что даст (и дает) выигрыш в РАЗЫ БОЛЬШИЙ, чем увеличение пропускной >способности шины процессор-память. >Зачастую даже prefetch для данных происходит автоматически, >а уж для инструкций он давно есть.

Если это все есть, то это хорошо. Я уже давно перестал следить за развитием линейки интеловских процессоров. Наврное потому, что ушел в программисты для других архитектур примерно тогда, когда появился pentium. с тех пор смотрю на intel так же как на кухонный комбайн. У меня дома стоит, работает и ладно. В интернет ходит, xemacs запускает. Большего мне от него не надо :)

>Другое дело, что в 80386 этого нет и Линус , когда делал 1.x, >о таких вещах мог и не знать. Но сейчас такая экономия - сродни >экономии на спичках. Пусть в микроядерной архитектуре переключение >контекста происходит чаще - зато там структуры данных меньше и >,следовательно эффективность их кеширования больше, чем у монолита.

Зато этих самых структур данных сильно больше.

Я, собственно, и не защищал ни монолит ни микроядро. Я придерживаюсь ответа царя Соломона двум спорящим: "И ты прав, и ты прав" :)

А мы вообще о цене преключения контекста говорили...

>Cтоимость перкеключения контекста, говорите? >Ну и чему же она равна на x86 _В ЧАСТНОСТИ_ ?

>Брамм П., Брамм Д. Микропроцессор 80386 и его программирование. >М.: - Мир, 1990

>Утверждает 16 мс для 80386 16 МГЦ!!!

>Да, это конечно СВЕРХНЕПРИЕМЛЕМО !!!!

а что такое "мс"? если миллисекунд, то это 256000 тактов - затрелиться! а если микро, то 256 тактов... м-м-м... тоже не сахар

А разве на x86 свет клином сошелёся??? А разве нас не "коробит" надпись на миропроцессоре "Designed for Microsoft Windows"?

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

Мне как-то приходила идея реализации, при которой процессор держит все регистры задач, эдак, для 16, и переключает контекст без обращения к памяти, а задачи, которые редко крутятся как бы уходят в свап в озу. Возможно, в будущем что-то такое и придумают.