RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Следующий шаг. Немного конкретики.


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : LightElf
To : Василий А. Сидоров
Subj : Следующий шаг. Немного конкретики.
> > Ну и к тому же ничего особенно катастрофического не вижу. В самом худшем случае имеем всего-навсего 100% оверхед, это весьма хороший результат.
> Тогда почему тебя так пугает оверхед от (пере)загрузки селекторов и/или дальних вызовов.

Потому что оверхед по памяти в 100% в _худшем_ случае - это ерунда. А вот оверхед по скорости вызовов API во _всех_ случаях - это ни фига не ерунда.

> > Повторяю - стек растет вниз, от предела к базе. Базы всех стековых сегментов одной задачи равны базе DS, то есть равны между собой. Дальнейшее объяснять?
> Да. Ибо предел SS меньше предела DS.

А кого собственно волнует предел (верхняя граница), если стек растет к нижней границе, которая у всех твоих сегментов оказывается одна и та же?

> Не, этот вариант тоже не годится, но по другим причинам.

Гм... Молчу-молчу.

> > Оптимизировать надо на основании _знания_ архитектуры и _особенностей_аппаратной_реализации,
> Есть дилемма.
> Некий кусок кода требует времени реакции (условно) десять микросекунд. Требует сейчас, требовал двадцать лет назад и будет требовать через пять лет.
> Двадцать лет назад десять микросекунд это хорошо, если четыреста тактов процессора на топовом железе. Борьба за каждый сэкономленный такт и понятна и нужна.
> Пять лет назад те же десять микросекунд - более пяти тысяч тактов на типовом железе, которое, к тому же ещё и суперскалярное. Борьба за каждый такт всё ещё ведётся, но уже непонятна и неоправдана.

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

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

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

> > > > Опять отмазки. Код писать и то некому, а ты про цикл жизни.
> > > Код для чего собираются писать? Силушку богатырскую показать или всё-таки для цикла жизни?
> > Цикл жизни OS зависит в частности и от удобства программирования под ней и удобства/простоты переноса в нее существующего кода с других платформ. "OS в себе" никому не нужна и цикл ее жизни не больше цикла разработки.
> "Цезарь, ты не прав" :)

И каков же жизненный цикл OS, под которую нет и не будет ни одной серьезной софтины и у которой нет ни одного пользователя?

> > > > То есть написать с нуля свои собственные http и SQL сервера.
> > > Для начала - ограничить существующие соответствующими параметрами в файлах настройки.
> > Это ежели таковые параметры во всех приложениях есть, во что как-то не верится.
> Это ничего, что той же OS/2 4095 нитей - _глобальное_ ограничение, а отнюдь не на задачу?

Это _глобальное_, но не _принципиальное_ ограничение. Проще говоря - константа времени компиляции ядра.
Размер некоего статического массива в кернеле.

Tue 19 Jun 2007 18:46 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3) Gecko/2003031



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.