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


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

Это клинический случай клинической задачи. Я как-то слабо себе представляю такое реальное приложение.
Ну и к тому же ничего особенно катастрофического не вижу. В самом худшем случае имеем всего-навсего 100% оверхед, это весьма хороший результат. Даже если сравнивать с классической сишной функцией malloc, которая имеет в худшем случае оверхед от 800% и выше в зависимости от реализации.

> > > Каждая "общедоступная" функция реализуется в двух экземплярах.
> > > При вызове нельзя смешивать auto- и static-переменные.
> > Афигенно. Слов просто нет.
> "Без комментариев" :)

Я просто представил себе тучные стада девелоперов, толпой ломанувшихся разрабатывать софт для такой замечательной OS.

> > > Перегружаем при переключении между нитями и SS и DS. База SS равна базе DS, но предел - равен размеру стека и, естественно, меньше DS. Идентичность "статической" части DS обеспечивает диспетчер страниц.
> > > Надо перегружать два селектора вместо одного.
> > Если вспомнить, что стек растет вниз, то опять имеем все шансы запороть один стек расползанием другого.
> " ет" (ц).
> Стек не может расползстись за пределы границ своего селектора.

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

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

Оптимизировать надо на основании _знания_ архитектуры и _особенностей_аппаратной_реализации, а не на основе тестовых прогонов. Бо протестировать все возможные случаи на всех возможных процессорах никогда не получится.
Интел и АМД не будут перекраивать свои процессоры ради маргинальной OS. Процессоры уже давно оптимизируются под конкретные code pattern и сегментированная модель памяти в эти code pattern не входит.

> > Опять отмазки. Код писать и то некому, а ты про цикл жизни.
> Код для чего собираются писать? Силушку богатырскую показать или всё-таки для цикла жизни?

Цикл жизни OS зависит в частности и от удобства программирования под ней и удобства/простоты переноса в нее существующего кода с других платформ. "OS в себе" никому не нужна и цикл ее жизни не больше цикла разработки.

> > То есть написать с нуля свои собственные http и SQL сервера.
> Для начала - ограничить существующие соответствующими параметрами в файлах настройки.

Это ежели таковые параметры во всех приложениях есть, во что как-то не верится.

> > > Не факт, что новые грабли хуже, просто старые - исхожены :)
> > Ну давай изобретать свой велосипед не с квадратными, а с треугольными колесами.
> Для начала не худо было бы _измерить_ угольность разных вариантов.

А чего сравнивать-то? Mainstream решение против "сферического коня в вакууме"?

Tue 19 Jun 2007 14:33 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.