Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / C++ vs ASM

C++ vs ASM

Удалёнwww9 фев. 200310:09#0
У меня компьютер GF4 MX440 Athlon XP 1600+ 256 RAM Win XP
Я пиши 3д игру ( по пустому 3д городу ездит авто )
FPS без всяких расчетов 360, а если включить расчеты то 250.Так получается, что расчет одного авто занимает приблизительно 1 млсек. и если в городе сразу видно 100 авто по 1 млсек.
то получается 10 fps.Расчет простой не используется даже cos, sin.
1. Почему C++ так медленно все расчитывает ? Может мне стоит все переписать на ASM ?
2. Где бы взять хорошию книгу статью по ASM вставкам в Visual C++
Keiraen Do'ArnНовичокwww9 фев. 200316:13#1
ILUSHA NIL
1. Почему C++ так медленно все расчитывает ?

Ошибка в 17й строке. :)

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

ILUSHA NIL
Может мне стоит все переписать на ASM ?

Не стоит. Лучше алгоритмы правь. Даже _правильно_ (что _оччень_ непросто) переписав на ассемблер не сможешь добиться качественного роста производительности. Ассемблер - последнее средство. Навроде ампутации.

Удалёнwww9 фев. 200317:39#2
N'Kam Do'Arn
Все я уже нашел функция sqrt ужасна тормозная но за сегодня я разабрался как на ASM програмить микропроцессор и общий код расчитывается быстрее в два с половиной раза я уже думаю переписывать по техоньку !
IROV..Постоялецwww9 фев. 200321:40#3
ILUSHA NIL
Всетаки лучше поищи лучшие алгоритмы.. Асм.. правельно говорят последнее дело.. :)
extremeНовичокwww10 фев. 20031:35#4
ILUSHA NIL
Приветик на ASM'e лучше писать циклы которые повторяются тысячи раз.Вообще все зависит от алгоритма плохой алгоритм будет плохо работать и на ASM. Даже сам Джон вроде говорил "Мне смешно видеть как програмист пытается весь код писать на ASM" Может еще попробывать вместо нескольких маленьких функций написать одну большую с хорошим алгоритмом.Бывает помогает
X MonsterНовичокwww10 фев. 20033:31#5
ILUSHA NIL
Не занимайся ерундой, лучше доки читай...
Если ты перепишешь на асме даю руку на отсечение, что скорость только уменьшится. Многие современные компиляторы(Intel C++, MSVC, GCC) генерируют очень качественный  код. Сделать быстрее почти невозможно(хотя бы посмотри, что делает IOC под SSE2 это же мрак...)
Хотя решать конечно тебе :-)
raskolnikovНовичокwww10 фев. 200312:13#6
ILUSHA NIL
Лучше попробуй вообще избавиться от такого большого количества sqrt-функций. Зачем тебе в расчетах так много корней???
JetПостоялецwww10 фев. 200313:18#7
Используй таблицы т.е. создай таблицу корней и читай из нее - скорость возрастет на порядок.постарайся все вычисления какие возможно сделать заранее и вынести из циклов и тп
ChebПостоялецwww10 фев. 200323:11#8
Я тоже однажды, вспомнив свой былой опыт "ТурбоПаскаль+Асм" попытался Дельфи обогнать - ни хрена не получилось, как ни пыжился... С тех пор пользую Асм только ради MMX'а (который, кстати, тоже потихоньку отмирает - вон, в четвёртом пне его поддержка какая отвратительно медленная) и ради такой полезной пары команд, как BSR / BSF (не думаю, что компилятору хватит ума их использовать при сканирования битовых масок).

Если не делаешь что-то совсем уж экзотическое и при этом опыт у тебя на уровне матёрого ассемблерщика - не стоит и пытаться эту штуку использовать. На лошади ещё можно было обогнать первый паровоз (типа ТурбоПаскаля), но с современным электропоездом Р-200 ей не тягаться... Время Ассемблера ушло. Хотя писать на нём было весело :)

СеменПостоялецwww11 фев. 20036:24#9
Я вот тоже хочу высказаться.

Я спрашивал у умных дядек, сколько дает очень хардкорная оптимизация на asm'e. Говорили - за 20% не выходит. Это в сравнении с правильно написанным C кодом + хороший компилятор
Но это очень хардкорная оптимизация. Если почитать доки по последним процессорам, то становится понятно насколько это серьезно.

Учитывать unit'ы разбора инструкции на mop'ы, учитывать их latency для каждого типа инструкции, учитывать latency выполнения самой инструкции, учитывать branch prediction и уходы от бранча методами без джампа, я уже не говорю про работу с кешем, которая святое всегда и везде. Оптимизация под размер L1, L2, страницы кеша, учитывать наличие хардварного префетча, использовать ли mov вместо prefetch, учитывать в какой кеш надо префетчить, ставить movntq. Отдельная история - распараллеливание команд и все что с этим связано. Там же все на уровне mop'ов происходит, поэтому детектится все только очень детальным профайлом.
И так далее. VTune - лучший и единственный друг, других друзей нет.

Еще одна песня - генерирование кода на лету, чтобы не засорять branch'aми и лучше кеш пользовать.

И вот все это - 20% по сравнению с C-кодом. И только в самом лучшем случае столько. И, естественно, при оптимизации под конкретный процессор. То есть на другом выигрыша может и не быть, даже наоборот.

Cheb
Для MMX, SSE, 3dNow! и компании intrins придумали чтобы компилятору больше свободы дать. Не знаю, есть ли они в Delphi.

KasheyПостоялецwww11 фев. 200311:22#10
дельфя при компиляции делает код пентиум-1 совместимым. можно зделать под пень про :)
остальное ручками ну или дргим компилятором опять же.

/ Форум / Программирование игр / Графика

Тема в архиве.

2001—2018 © GameDev.ru — Разработка игр