2011-10-15 3 views
0

Мне было интересно, являются ли локальные переменные в сборке быстрее глобальных переменных, которые мы используем. Контекст для этого заключается в том, что я изучаю анимацию 2d, используя win32 api, из книги. Автор использует функцию для инициализации (создание, регистрация, показ и обновление окна) главного окна программы. Я написал эту функцию в asm (просто для того, чтобы практиковать некоторый asm). Поэтому мне было интересно, есть ли какое-либо преимущество в производительности, поскольку в используемой функции asm структура WNDCLASSEX была создана локально (в стеке). Я знаю, что локальные переменные в сборке должны быть быстрее, но, пройдя разборку для другой программы (полностью в cpp), я заметил, что компилятор также создает локальный WNDCLASSEX. Это смутило меня в этой теме. Поэтому я хочу знать, есть ли разница в производительности между кодом asm и кодом C++.Локальные переменные в сборке: они быстрее глобальных переменных?

Devjeet

+4

Концепции переменной или области действия (локальные, глобальные) не существуют в сборке. И C++ не определяется с точки зрения концепций сборки. –

+1

Нет кода. Трудно сказать, что быстрее. Неприменимо, учитывая вызовы CreateWindow и т. Д., Которые заполняют ваш код. –

+2

@cat Предполагаю, что вы можете рассматривать переменную, находящуюся в стеке как локальную, а одну выделенную в сегменте данных как глобальную. –

ответ

4

В верхней части стека много кодов. Это означает, что вершина стека обычно находится в кэше процессора. Доступ к этому будет быстрее, чем доступ к другим областям памяти (от .bss и т. Д.).

Но для функции типа CreateWindow, которая называется только несколько раз для каждой программы, это не имеет большого значения. Разница составляет менее нескольких сотен циклов процессора. Для других частей кода разница может быть более заметной. Но важно отметить, что если вы повторяете одно и то же много раз с одним и тем же фрагментом данных, данные также попадают в кеш процессора и, следовательно, разница в производительности будет сведена на нет.

2

Честно говоря, я думаю, вы должны оставить такие решения компилятора. Люди, которые написали компилятор, потратили много человеко-лет, оптимизируя код, есть очень мало оснований беспокоиться о таких вещах для 99% всех приложений. В случае 1%, когда вы компилируете, делаете сборку и проверяете код, там вы можете заработать цикл или два.

2

Не имея свой код на суд, у меня есть совет:

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

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

Еще одна плохая вещь с кодировкой с сборкой внутри языка высокого уровня - предотвращает переносимость кода.

Примечание: Тем не менее, есть некоторые машины и системы, которые кодируют сборку для них.

Смежные вопросы