>>>Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения
>>>контекста действительно _существенно_ повлияет на общую производительность системы?
>>
>>ухудшают производительность только две вещи:
>>- "лишние" переключения контекста
>>- усложненная структура общения между этим контекстами
>>
>>вы понимаете разницу между влияет на производительность и _существенно_ влияет?
>
>а какая разница между "пиво" и "много пива" ? %)
>
разница в том что есть понятие "лучше чем дороже" - хорошие итальянские туфли стоят в разы дороже китайских, но служат значительно дольше, точнее раньше устаревают морально чем разваливаются (с китайцами часто наоборот).>
>>это я к тому, что в реальной жизни никто не работает с
>>файлом, например (сокетом, etc), прямо через системные вызовы, а обычно через
>>какую-нить кеширующую структуру с буферами, и количество системных вызовов резко сокращается.
>
>поставьте себе strace (не помню уже аналога под бздю) и посмотри на
>любой попавшийся под руку процесс. Будете удивлены: системные вызовы юзаются ОФИГЕННО
>часто. Про кеширование - думает уже ядро.
>Только вот сам факт сискола для микроядра - уже намного (ну не
>знаю насколько... и у вас это больной вопрос ;) больше работы
>чем для монолита...
>
>>Хотя, конечно есть проблема криворукости программеров, но современное железо, похоже, скоро и
>>так заставит руки ровнять..
>
>странная у вас логика... пока-что наблюдаеццо обратная тенденция.
>Железо становитсья мощьнее - про качество кода программеры забывают...
ничего странного - сейчас _все_без_исключения_ переводится с простой (или не очень) параллельной шины на всевозможные варианты последовательных (не считая того, что растет число слоев между приложением и железом), а там - хоть с железной поддержкой хоть без - вызов намного дороже, и что характерно, последние итерации новой аппаратуры _все_без_исключения_ по крайней мере в первых реализациях хуже по латентности чем предыдущие :(
(например DDR vs DDR2)
хотя предельная (пиковая) пропускная способность таки действительно растет, почти в соответствии с законом мура.
>
>>>>Да, и не забудьте учесть, что в современном железе и так латентность
>>>>ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают
>>>>кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется,
>>>>но так же постоянно и неуклонно растет латентность)..
>>>>Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.
>>>
>>>Да, некритичность ошибок дров в микроядре - это его главный плюс, несомненно.
>>>
>>>Но и с другой стороны - за все нужно платить. Сложность реализации
>>>такого ядра - немалого стоит, хотя идея столь высокой надежности и
>>>очень привлекательна...
>>
>>простая и прозрачная архитектура сложна в реализации?
>
>у вас есть положительный опыт написания микроядер?
>
движок игрушки есть нечто близкое по сложности/функциональности к микроядру, и только подход с жесточайшей формализацией простой архитектуры позволяет создать его с нуля с небольшими затратами ресурсов - то есть конкурировать с китайцами и индийцами.
>
>>Вы, извините, в какой области работаете?
>
>админ с богатым опытом программирования
>
>>ато я в практической инженерной деятельности
>>(от пайки/доводки железяк уровня спектрума и драйверов для FreeBSD и собственных
>>мониторов для дос, до флешевых игрушек) ни разу не встречал подтверждающих
>>примеров..
>
>ну... чтоб встретить пример легкой/тяжелой реализации микроядра - нужно как минимум попробовать,
>либо послушать людей, съевшЫх некое жЫвотное на этом.
>Лично я сам не пробовал фдра писать, увы. Но наслышан мнением Торвальдса
>о переводе линуха на микроядерные рельсы. (Речь не идет о
>написании микроядра с нуля). Так вот он считает, что это достаточно
>большой труд, и, к сожалению, не очень оправданный с точки зрения
>потерь производительности в дальнейшем.
>Ну, с потерей производительности я с ним не совсем согласен. Есть области
>применения, где любые потери ее - ерудна по сравнению с полученной
>надежностью.
>В принципе, на пальцах :), микроядро сделать их линуха - раз плюнуть.
>Известна теория и как все должно работать. Но вот у меня
>большые сомнения касательно реализации этого "раз плюнуть"...
перепахивать готовый код это конечно далеко не "раз плюнуть", а вот сделать с нуля, для нескольких вариантов широко распространенного железа (да хотя-бы даже для запуска под виртуализатором железа) - вполне реально даже для одного человека.
