Лучшие решения для оптимизации

Вот уже давно занимаюсь написанием игр:
Перешёл на ASSEMBLER и появились вопросы.
Нужна максимальная производительность.
На сколько различается скорость запуска программ под Bios, или напривер под Windows расчитаных на Bios.
Что использовать?
In\Out
прерывания Bios
прерывания Windows
Что быстрее(видео-карта)?
In\Out
DirectX
OpenGl
Что быстрее(работа с файлами)?
In\Out
прерывания Bios
прерывания Windows
Что быстрее(звук)?
In\Out
прерывания Windows
И. Т. Д.

p.s.: Хотелось-бы сделать мульти-операционную систему.

 

А по руски вопросы задовать можно?

Быстрее через порты ввода/вывода. Но это требует написание драйверов. Так как написать драйвера под все железки не реально. Железок много, а спецификации на большую часть закрытые(отсутствуют) . Отсюда вывод используем готовые драйвера. Так что тебе прямая дорога к OpenGL и DirectX.
BIOS не обязан поддерживать все функции железа. Да и оптимизировон он в основном на компактность кода.

Это еще что за зверь?

 

Телепатор упорно нашёптывает, что тут имелась в виду прога, для которой был бы не сильно критичен тип ОСи - Винда, Мак или Никсы.

 

ASSAMBLER
а что это за зверь? )))

Что-то я ничего не понял...

 

Ну на сколько Windows может тормозить программу.

 

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

 

OpenGL и DirectX — А что всё-таки лучше:
Я слышал что OpenGl красивее, но не везде поддерживается, а DirectX и так к каждой игре прилагается?

 

Скорее наоборот - OGL кроссплатформенный и поддерживается всеми. А прямой Х - поддерживается только дядей Вилли. И то десятая версия не идет на ХР.

 

1: Я слышал что команды рисования OpenGl(glBegin;glEnd;glVertex;glColor) только заносят данные в какую-то область памяти,
а потом уже выполняются при команде glFlush() (или другой?):
Правда-ли? На DirectX такая-же система? Как можно взять оттуда данные, изменить, и поставить изменённые?
2: Большая-ли разница в DirectX и OpenGl?
Можно-ли сделать игру, где используется и то и то на выбор игрока без очень сложных вариантов?
3: Что именно представляет из себя DirectX и OpenGl — драйвера для работы с другими драйверами или программа,
которая !сильно! преобразует данные и посылает их другим драйверам?

 

Zhelezka
Прежде чем о чем-то спрашивать, нужно хотя бы в общих чертах знать об этом. У тебя чудовищное незнание мат. части и все твои вопросы - бред.

 

Ты как раньше писал, гуру ты наш?

 

На кой шут конкретно тебе нужна "максимальная производительность"? Чем таким можно загрузить процессор, чтоб оно потребовалось? Игрой? 2 Гб текстур, расчет перекрытия тысяч трехмерных объектов, рассчет в реальном времени трассы и рикошетов для сотен пуль одновременно? ))) Да, команда из N человек наверно напишет что-то такое за M лет... где N и М однозначно больше 1.

Программы "под биос", равно как и программы под дос, даже использующие порты, будут всегда медленнее, чем программы для Windows. Это судьба. 16-разрядный режим, невозможность написать драйвера под произвольные видеокарты (из-за отсутствия документации и общего объема кода), использование исключительно того, что в Windows-играх называлось "software rendering" - словом, то, что тормозит в реальном режиме под ДОСом, при правильной переделке будет летать в окошках (естественно, при переделке на директХ-ОГЛ, а не при запуске той же программы в виртуальной дос-машине)

В Windows нет прерываний. По крайней мере, для пользователей и программистов игр. Забудь о существовании инструкции int.

В реальном режиме для видеокарт обычно быстрее in/out. Но не для того, что тебе надо. С помощью in/out можно будет изменить видеорежим, сменить видеостраницу, ну и еще немного. Это разовый процесс, и ничего страшного, даже если он займет секунду или 2...
Рисовать ты будешь пересылкой данных в видеопамять - вот этот процесс будет как раз одинаково медленным (или одинаково быстрым - это зависит от того, оптимист ты или пессимист), вне зависимости от переключения режимов - через int 10h или через порты. В защищенном режиме вместо портов есть специальная область памяти, куда можно слить сразу несколько мегабайт текстур - и передать их таким образом в видеокарту.

В Windows и OpenGL, и DirectX дают сравнимое быстродействие... DirectX быстрее. Еще быстрее писать на специальном языке видеоускорителя и передавать целый блок команд напрямую в видеокарту (а там свой процессор, умеющий массу специальных операций), но тут голова опухнет, это удел избранных.

Естественно, работа с файлами быстрее под Windows или другой 32-битной (или 64-битной) операционной системой

Windows НЕ тормозит программу. Как бы не говорили, это сейчас самая быстрая (или по крайней мере не уступающая другим вариантам) операционная система, особенно (!) в части графики. Любая другая ОС тормозит БОЛЬШЕ. Не знаю почему. Не хочу начинать холивар, если у кого-то Intel Core 2 Duo, там и знаменитая KDE под FreeBSD летает, несомненно Подозреваю, что все дело в тщательно отлаженных драйверах - для других ОС они или отсутствуют, или сделаны энтузиастами на коленке и с глюками, или поддерживаются и обновляются с ба-альшим скрипом.

ОпенГЛ не красивее. Он несколько проще для освоения. В конечном счете (под Windows) будет вызван тот же самый драйвер, и получится то же, что и с DirectX. Многие игры позволяют переключить используемый движок хоть на то, хоть на это. Как правило, за счет 2-х экземпляров одного и того же графического движка, скомпилированных для каждого варианта отдельно

Уф. Как-то так вроде.

 

Насчёт оптимизации:
1)Может команда(mov,shr) на более новый процессорах занимать больше тактов?
2)Может команда выполняться на процессоре неровное колличество тактов(например 2.71)?
3)Зависит-ли скорость от размера операндов(mov byte a, b; mov dword a, b)
4)Может немного изменяться скорость исполнении одной и той-же команды?
5)Стабильно-ли процессор выполняет одно и тоже колличество тактов?

 

1 - http://intel.com http://amd.com
2 - да может, но такты все равно это сгладят. собстно зачем и нужна синхронизация (вообще любая операция будет выполняться чуть меньше 1..n тактов, но следующая начнет выполнение только по тактовому синхроимпульсу)
3 - изучай ассемблер дальше mov byte a, b; mov dword a, b - это две разные команды (<prefix> 88/8А mod <sib> и <prefix> 89/8В mod <sib> соответственно)
4 - см. п. 1
5 - аналогично 4 п. (но рассуждая философски и принимая во внимание, что реальные элементы не идеальны - нет не стабильно, но отклонение минимально)

З.Ы. Рановато тебе исчо игры на асме писать.

 

Я знаю что это две разные команды:
я просто говорил про команды с одними и теми-же параметрами и задачами, но разным размером операндов.

З.Ы. Думал игры писать но пока передумал: слишком Windows и DirectX не нравится.
Решил с ОС пока попрактиковаться.

 

1) В общем случае, да.

2) Нет. Процессор тактируемое устройство и все задержки считаются в целых тактах (в P4 - в полутактах). Поэтому говорить о том, сколько на самом деле пиксекунд или долей такта выполняется команда просто бессмысленно, т.к. результат выполнения команды в любом случае м.б. использован только в начале следующего такта

3) Чтение\запись в память выравненных байтов\вордов\двордов (а в 64-битном режиме и q-вордов) осуществляется за одно время независимо от размера. Это же относится и ко всем основным операциям АЛУ, кроме деления.

4) Если имеется в виду вопрос 2), то "немного" не может. "Быстрые" команды (включая умножение) в процессорах выполняются за фиксированное число тактов (т.к. и анализировать условия некогда и при фикс.задержке упрощается работа планировщика). А вот задержка тормозных фпу-шных операций типа fsin и т.п. наоборот может сильно "гулять" в завис-ти от операндов. Задержка средне-тормозных div,fdiv,fsqrt зависит от проца - в некоторых фиксирована (зависит только от размера операнда, а не от его значения), в некоторых, в частности Core 2, используются сокращенные алгоритмы для малых значений. Ну и ес-но задержки при чтении операндов из памяти сильно зависят от того находятся ли данные в кэше L1, L2 или в ОЗУ.

5) Не понятно, что имеется в виду. Если процу не мешать, то одна и та же последовательность команд в одних и тех же условиях выполняется одинаковое кол-во тактов

 

leo

я так думаю, что имеется ввиду отклонение тактовой частоты от заданного наминала.
Zhelezka

ну а посмотреть время выполнения в таблице и не задавать глупых вопросов (но по секрету скажу, что в большинстве случаев, а может даже и всегда за исключением внешнего устройства (FPU и расширений на его основе) скорость не зависит от размера операндов)

 

max7C4
а может даже и всегда...скорость не зависит от размера операндов - т.е. по времени mul ah = mul edx ?

 

leo
1) Не должен. Теоретически может. А практически надо таблицы смотреть.
2) Как мерить.
Вопервых есть два праметра Latency и Throughput. Latency- задержка до результата выч блока. Throughput - задержка до возможности выполнять следующую команду на выч блке.
Мало того что в NETBURST выч блок работат на двной скороти так почему-то Throughput бывает и 0,33такта
3) На разных процессорах по разному. Зависит и еще как.
Есть еще оптимизация, процессор пробует групировать записи. Но у него это плохо получается.
4) может. Но это редкое исключение. Первое это проблемы с доступом к памяти тогда может быть задержка на так. А если это не брать в рассчет. То и тогда некоторые арефметические операции могут выполняться разное число тактов.
А еще есть непомню точно какая инструкция xchg вроде, так она само произвольно может выполняться на такт дольше.
5) Еще раз повторю смотря как мерить.

Тут дело такое что эти условия нам не известны и поставить эксперемент одинаково очень трудно. У меня так расхождение в скорости кода 2 раза!!!

 

max7C4

Все определяется целесообразностью. Например, в 486 умножение было тормозным и команды исполнялись по очереди (не было хлопот с планированием), поэтому актуально было ускорить mul\imul в зависимости от реального значения операнда (старшего значащего бита), а соотв-но и от его размера. В современных процах аппаратно довели латентность умножения до 3-5 тактов, поэтому и целесообразность анализа отпала. А вот деление осталось тормозным и соотв-но зависимость задержки от размера тоже осталась, к тому же в Core 2 еще и преданализ значений операндов ввели для "досрочного" завершения.

Поэтому резюме таково - для сравнительно быстрых или же тормозных, но малопопулярных операций вводить зависимость от размера не имеет смысла, т.к. это лишь усложнит планировщик. А из популярных тормозных АЛУ-шных операций остается пожалуй только деление, для которого и целесообразно вводить зависимость задержки от размера.
Ну а задержки FPU от размера вообще не зависят, т.к. он работает только со своим 80-битным форматом (только загрузка\выгрузка tbyte ес-но тормозит, т.к. "ни в какие ворота не лезет"