Размышления про x86_64

>Почему бы точно не указать, где именно потеря?

Не знаю, сам не измерял, но традиционно называется именно эта цифра. Видимо, переключение контекстов тормозит.

не... на самом деле потери могут быть при «сдвиге окна»

точнее фактически когда необходимо перестроить виртуальное пространство

а потом еще и работать с этим плавающем делом

>точнее фактически когда необходимо перестроить виртуальное пространство

Это я и называю переключением контекста. В широком смысле. Да, в одном текущем отображении потерь не будет. Но система у нас многозадачная...

хм. ну это в люом случае стандартные потери на переключении.

потерю будут расти когда реально начнут использоваться подвижные окна в виртаульном адресном пространстве. Нужно будет считать смещенные адреса, да и окно само двигать. А это переключение страниц

А так. Что отораженое, что нет. Какая разница для ОС, что переключать?

namezys> хм. мне кажется, что оптимизация при компиляции даст прирост более сильный, чем при исполнении

Использование RISC-ядра напрямую даст прирост производительности ещё более существенный, Особенно если оптимизировать компилятор.

Конечн не революция, но AMD ушла вперёд по сравнению с быдлоинтелем, который разучился делать процессоры.

наглейшее 4.2, изучи как обстоит дело

Запутать хочешь?) Под контекстом обычно подразумевается состояние проца в текущей задаче.
Даже если предположить, что приходится дополнительно сильно напрягаться при каждом переключении по таймеру или другому прерыванию, 10-15% потерять как-то нереально. Т.е. может сам процесс переключения и больше, конечно... Но механизм такой потери мне непонятен(надо будет посмотреть). Ведь просто меняется состояние регистров проца, а не обращение к внешней шине или преключение банков в vesa1 :)

>Под контекстом обычно подразумевается состояние проца в текущей задаче

У «контекста» - очень широкие понятия. Даже в области компьютерной схемотехники :) Я имел в виду не контекст состояния процессора, а контекст задачи.

Даже если предположить, что приходится дополнительно сильно напрягаться при каждом переключении по таймеру или другому прерыванию, 10-15% потерять как-то нереально.

Ну, традиционно называется эта цифра. Сам не проверял, не требовалось никогда :)

Ведь просто меняется состояние регистров проца

Мне кажется, при использовании PAE при переключении задач ещё и переключать что-то в памяти приходится. Не может же 32-х битный процессор более 4Гб памяти отобразить. И одним мапингом тут уже не обойтись.

Хотя - Х.З., конечно, не разбирался.

>Мне кажется, при использовании PAE при переключении задач ещё и переключать что-то в памяти приходится. Не может же 32-х битный процессор более 4Гб памяти отобразить. И одним мапингом тут уже не обойтись.

Ну там технология типа свопа в ОЗУ, когда нужная страница из верхних гигабайт копируется в окно, лежащее внутри допустимых четырёх.

копируется или все таки происходит подмена адресов без физического копирования данных?

>копируется или все таки происходит подмена адресов без физического копирования данных?

Если бы копировалось - то 15-ю процентами не обошлось бы :) Тормозило бы в десятки-сотни-тысячи раз.

А вот замена схемы трансляции для каждой задачи и может дать ощутимую, но не критическую потерю производительности.

>Ну там технология типа свопа в ОЗУ, когда нужная страница из верхних гигабайт копируется в окно, лежащее внутри допустимых четырёх.

O_o Я почему-то думал, что страницы памяти могут просто как угодно отображаться. Все-таки придется подробнее изучить вопрос...

вот и меня эта фраза смутила, про копирование,
насколько я понимаю там что-то типа extents как в ext4
т.е. вместо прямой адресации идет двойная 32+16 = 48 битная
сначала 16 битный адрес, потом 32 битный

хотя по-моему так лучше поставить 64 битную систему, или в крайнем случае 32 userland on 64 kernel (в таком случае возможны неудобства с virtualbox например, хотя все остальное будет работать, 3D в играх например меня удивило по быстродействию, в положительном плане)

>т.е. вместо прямой адресации идет двойная 32+16 = 48 битная

Скорее всего там используется сегментная модель на уровне ядра. Приложения современные всё равно только во Flat-модели юзаются, про сегменты ничего не знают, а вот ядро может процессы запускать не в едином адресном пространстве с общими сегментами, а в разных.

>3D в играх например меня удивило по быстродействию, в положительном
плане)

tuxracer?

wow @ wine
la2 @ wine
хотя даже в glxgears, который не тест производительности на самом деле, и то fps было больше

драйвера проприетарные Nvidia , модуль 64, библиотеки 32

Да не такая убогая, как сегментная. Без мэппинга страниц со времен 386 было бы совсем тяжело в многозадачных ОС :)

вспомнить хотя бы EMS , там 1 страничка на 64 кб маппилась в нижние адреса (1024k) , и вроде и никто не жаловался на производительность особенно )

>вспомнить хотя бы EMS , там 1 страничка на 64 кб маппилась в нижние адреса (1024k)

В верхние.

и вроде и никто не жаловался на производительность особенно )

Потому что программа прикладная работала в нижних адресах и не было никакой многозадачности. Подключили нужную страницу и работаем...

нижние в том смысле , что в пределах 1024 Kb
хотя с точки зрения терминологии 0-640 Kb - нижние, 640-1024K - верхние )

Откуда ты знаешь, что никто не жаловался :)
Это было отвратительно до появления 286.

>Это было отвратительно до появления 286.

А что, в смысле EMS была хоть какая-то разница между XT и AT? :)

Что на 8086, что на 80286 EMS реализовывалась только дополнительной аппаратной платой. Которых я в жизни своей ни разу не видел и ни от кого из первых уст не слышал :)

...

Вот на 80386, когда появился MMU, стало возможным эмулировать EMS программно. Тогда и пошла эта память в народ :) Правда, не как полноценный многостраничный способ расширения памяти, а как введение дополнительной памяти в верхней области мегабайта реального режима.

...

80286 же характерна тем, что из-за аппаратной ошибки в процессоре стало возможным адресовать 64кБ за пределами 1Мб. (сегмент 0xFFFF - при превышении адреса 0xF, дальше происходило не зануление адреса, а выход за первый мегабайт), чем тут же стали пользоваться. Лишние 64кБ очень даже не были лишими :)

DOS=HIGH,UMB

в этот UMB если постараться мог влезть даже Volkov Commander )
и около 624кб памяти (из 640) оставались свободными для приложений реального режима, при наличии загруженных драйверов мыши, cdrom ...

с EMM386 конечно сложнее было освободить много памяти, с QEMM386 проще)

Смысл в том, что 286 давал возможность не использовать EMS :)
Конечно, все было совсем не так пушисто, как у 386, но все же.

кстати, himem дефолтно делал все селекторы сегментов размером 4ГБ, из-за чего некоторые говнопроги не работали, расчитывающие на переполнение в 64К :)

>Смысл в том, что 286 давал возможность не использовать EMS :)

Да. Но HIMEM давал только 64к, а EMS - полторы-две сотни (точнее зависело уже от типа видео, BIOS и т.п. - короче, сколько было свободного адресного пространства в верхней памяти). А в сумме набегало уже и за две сотни где-то :)

>кстати, himem дефолтно делал все селекторы сегментов размером 4ГБ

На AT? ;)

286 позволял адресовать 16М, и там где нужна память этим пользовались, в итоге каждая прога со своим менеджером памяти(ДОС-то не вкурсе). Из-за чего многие не работали с emm/qemm

>На AT? ;)

На любом проце 386+

>286 позволял адресовать 16М

Угу. Но только из защищённого режима.

и там где нужна память этим пользовались

Но не из реального режима DOS.

Из-за чего многие не работали с emm/qemm

Кроме винды 3.0/3.1 (но уже не 3.11) много назовёшь программ под 286, работавших в защищённом режиме? :)

>На любом проце 386+

См. начало треда :) - http://www.linux.org.ru/jump-message.jsp?msgid=4300228&cid=4303426

...

А так - я не помню проблем с размером селектора под DOS. Всё равно каждая софтина защищённого режима под себя всё перестраивала. А реальному режиму - пофиг.

>>286 позволял адресовать 16М

Угу. Но только из защищённого режима.

Адресация 4Г в реальном режиме на 386 тоже результат бага :) Знаменитый BIGmode.

Но не из реального режима DOS.

См. те же борман-компиляторы - они умели компилять под протектед моде, о существовании в будущем dpmi они еще не знали
Кстати, любой менеджер памяти типа емм прозрачно переходил в защищенный режим, на 286 из него вернутся нельзя :)

Кроме винды 3.0/3.1 (но уже не 3.11) много назовёшь программ под 286, работавших в защищённом режиме? :)

smartdrive мало?, множество игрух, дем

>А так - я не помню проблем с размером селектора под DOS.

Потомучто кроме himem ты грузил всегда emm386/или еще чего
Они, в отличии от, реально переходили в защищенный режим и эмулировали 8086(адресное пространство отображали итп)

>Адресация 4Г в реальном режиме на 386 тоже результат бага :) Знаменитый BIGmode.

А... Это я уже и забыть успел. Тем более, что в своём софте никогда не использовал :)

См. те же борман-компиляторы - они умели компилять под протектед моде

Хм. Я как-то сразу с BC3.1 на винду перелез :) А 3.1 - не умел.

Кстати, любой менеджер памяти типа емм прозрачно переходил в защищенный режим, на 286 из него вернутся нельзя :)

Можно было, но не на всех машинах. Там, где перезагрузить можно было машину через порты :) А на 386 - да, там тройная ошибка сильно помогла :)

smartdrive мало?

Да ладно! Как же он в realmode на 286 возвращался-то? :) Это ж был билет в один конец...

множество игрух, дем

Опять же, не помню под 286 ничего протектмодного из оного. Вот с 386 - да, другая жизнь началась. На 386 я и сам свой DPMI писал :)

>>smartdrive мало?

Да ладно! Как же он в realmode на 286 возвращался-то?

Тьфу, сорри, упустил, что мы про размер селектора на 386 говорим :) Попутался.

...

Но со smartdrv на 386 никогда проблем не видел.

Равно, как и с кучей нестандартного софта. Да, были проблемы, если софт имел свой менеджер памяти, несовместимый с DPMI, но это решалось просто загрузкой без emm386. Всё остальное работало.

>Потомучто кроме himem ты грузил всегда emm386/или еще чего

Угу.

Они, в отличии от, реально переходили в защищенный режим и эмулировали 8086(адресное пространство отображали итп)

Но и когда под emm386 не работал софт (тот же First Encounter, например), то всё равно smartdrv работал исправно :) Т.е. не исключаю, что кто-то мог что-то совсем уж похерачить, но, думаю, что это была крайне экзотическая ситуация :)

> копируется или все таки происходит подмена адресов без физического копирования данных?

конечно смена виртуального отображения

с точки зрения логики нет не какой разницы

First Encounter я помнится видел сборку даже под NT с умноженными на 2 пикселями...
Да говно редскостное, я лучше в элиту на zx поиграю

>с точки зрения логики нет не какой разницы

Глумимся?

>First Encounter я помнится видел сборку даже под NT

Либо римейк какой-то, либо ты с Frontier'ом путаешь. Frontier был реалмодовый и даже на 286 летал. А вот First Encounter («Frontier-2») - был 386-й со своим дос-экстендером. И ни под чем, кроме голого DOS'а не запускался :)

Да говно редскостное, я лучше в элиту на zx поиграю

Это ты зря. Я последний раз во Frontier уже в начале 2000-х играл :) Всё же, последний космосим с реалистичной физикой был, увы...

...

А сегодня, кстати, есть GL-версия его. В т.ч. под Linux нативная :) Правда, хакнутая/реверсная, так что там не всё из оригинала есть (секретные мисии разные и т.п.) - http://tom.noflag.org.uk/glfrontier.html

Скрины:
http://wiki.alioth.net/images/6/61/Saturn.jpg
http://linux.softpedia.com/screenshots/GLFrontier_1.jpg
http://linux.softpedia.com/screenshots/GLFrontier_3.jpg

Хорошо, что я это пропустил :)