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

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

Тема:

> > > Ну и к тому же ничего особенно катастрофического не вижу. В самом худшем случае имеем всего-навсего 100% оверхед, это весьма хороший результат.
> > Тогда почему тебя так пугает оверхед от (пере)загрузки селекторов и/или дальних вызовов.
> 
> Потому что оверхед по памяти в 100% в _худшем_ случае - это ерунда. А вот оверхед по скорости вызовов API во _всех_ случаях - это ни фига не ерунда.
> 
> > > Повторяю - стек растет вниз, от предела к базе. Базы всех стековых сегментов одной задачи равны базе DS, то есть равны между собой. Дальнейшее объяснять?
> > Да. Ибо предел SS меньше предела DS.
> 
> А кого собственно волнует предел (верхняя граница), если стек растет к нижней границе, которая у всех твоих сегментов оказывается одна и та же?
> 
> > Не, этот вариант тоже не годится, но по другим причинам.
> 
> Гм... Молчу-молчу.
> 
> > > Оптимизировать надо на основании _знания_ архитектуры и _особенностей_аппаратной_реализации,
> > Есть дилемма.
> > Некий кусок кода требует времени реакции (условно) десять микросекунд. Требует сейчас, требовал двадцать лет назад и будет требовать через пять лет.
> > Двадцать лет назад десять микросекунд это хорошо, если четыреста тактов процессора на топовом железе. Борьба за каждый сэкономленный такт и понятна и нужна.
> > Пять лет назад те же десять микросекунд - более пяти тысяч тактов на типовом железе, которое, к тому же ещё и суперскалярное. Борьба за каждый такт всё ещё ведётся, но уже непонятна и неоправдана.
> 
> Нужна не борьба за каждый такт, нужно общее понимание. Есть вещи которые в тактах дорого стоят, причем чем дальше - тем дороже. Есть частные случаи, когда на это начхать. Есть обшие случаи. Архитектура и ядро OS - общий случай. Нельзя принципиально дорогие решения закладывать в основу OS. Перегрузка селекторов - решение принципиально дорогое. Просто-напросто время перетряхивания дескрипторных кэшей никого из производителей процов не волнует, т.к. в массовых операционках это очень редкая операция. Время сброса TLB - операция теоретически медленная. Но она частая и производители процессоров ее пытаются ускорить.
> 
> > > а не на основе тестовых прогонов. Бо протестировать все возможные случаи на всех возможных процессорах никогда не получится.
> > Без комментариев :)
> 
> Пожалуйста, дай мне результаты тестов любой софтины в любых попугаях, выполненные на процессоре, который Интел выпустит в продажу через 3 года?
> 
> > > > > Опять отмазки. Код писать и то некому, а ты про цикл жизни.
> > > > Код для чего собираются писать? Силушку богатырскую показать или всё-таки для цикла жизни?
> > > Цикл жизни OS зависит в частности и от удобства программирования под ней и удобства/простоты переноса в нее существующего кода с других платформ. "OS в себе" никому не нужна и цикл ее жизни не больше цикла разработки.
> > "Цезарь, ты не прав" :)
> 
> И каков же жизненный цикл OS, под которую нет и не будет ни одной серьезной софтины и у которой нет ни одного пользователя?
> 
> > > > > То есть написать с нуля свои собственные http и SQL сервера.
> > > > Для начала - ограничить существующие соответствующими параметрами в файлах настройки.
> > > Это ежели таковые параметры во всех приложениях есть, во что как-то не верится.
> > Это ничего, что той же OS/2 4095 нитей - _глобальное_ ограничение, а отнюдь не на задачу?
> 
> Это _глобальное_, но не _принципиальное_ ограничение. Проще говоря - константа времени компиляции ядра.
> Размер некоего статического массива в кернеле.

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~