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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > > Т.е. имеется 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 решение против "сферического коня в вакууме"?

__, _, __, _,_ _, _ \|_ / \ \|_) \| \| \|\/\| \| \ / \| \ \| \| \| \| ~ ~ ~ ~ `~' ~ ~