основное операционное процессорное время стоится
Посмотрите видео Brian Cantrill DTrace. Это - большой основанный на демонстрации разговор, и Cantrill является одним из создателей DTrace.
http://video.google.com/videoplay?docid=-8002801113289007228
6 ответов
Производительность на современном процессоре далеко не тривиальна. Вот пара вещей, которые усложняют это:
- Компьютеры быстрые. Ваш ЦП может выполнять до 6 миллиардов инструкций в секунду. Таким образом, даже самая медленная инструкция может выполняться миллионы раз в секунду, а это означает, что на самом деле имеет значение , если вы используете ее очень часто
- В современных процессорах одновременно выполняются сотни инструкций. Они конвейерные, что означает, что пока одна инструкция читается, другая читает из регистров, третья выполняется, а четвертый выполняет обратную запись в регистр. В современных процессорах таких ступеней 15-20. Кроме того, они могут одновременно выполнять по 3-4 инструкции на каждом из этих этапов. И они могут изменить порядок этих инструкций. Если единица умножения используется другой инструкцией, возможно, мы сможем найти, например, инструкцию сложения для выполнения. Таким образом, даже если у вас есть несколько медленных инструкций, их стоимость может быть очень хорошо скрыта большую часть времени, выполняя другие инструкции, ожидая завершения медленной.
- Память в сотни раз медленнее, чем процессор. Выполняемые инструкции не имеют особого значения, если их стоимость меньше, чем получение данных из памяти. И даже это ненадежно, потому что у ЦП есть собственные встроенные кеши, чтобы попытаться скрыть эту стоимость.
Краткий ответ: «не пытайтесь перехитрить компилятор». Если вы можете выбирать между двумя эквивалентными выражениями, компилятор, вероятно, сможет сделать то же самое и выберет наиболее эффективное. Стоимость обучения варьируется в зависимости от всех вышеперечисленных факторов. Какие другие инструкции выполняются, какие данные находятся в кеше ЦП, какая точная модель ЦП является исполняемым кодом и т. Д. Код, который в одном случае очень эффективен, в других случаях может оказаться очень неэффективным. Компилятор попытается выбрать наиболее эффективные инструкции и составить их график как можно лучше. Если вы не знаете об этом больше, чем компилятор, вы вряд ли сможете справиться с этим лучше.
Не пытайтесь делать такие микрооптимизации, если вы действительно не знаете, что делаете. Как показано выше, производительность на низком уровне - смехотворно сложная тема, и очень легко написать «оптимизацию», которая приведет к гораздо медленному коду. Или просто жертвуют удобочитаемостью ради чего-то, что вообще не имеет значения.
Кроме того, большая часть вашего кода просто не оказывает заметного влияния на производительность. Обычно люди любят цитировать (или неверно цитировать) Кнута по этому поводу:
Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол
Люди часто интерпретируют это как «не надо» Не пытайтесь оптимизировать ваш код ". Если вы на самом деле прочитаете полную цитату, должны стать ясны некоторые гораздо более интересные последствия:
В большинстве случаев нам следует забыть о микрооптимизациях. Большая часть кода выполняется так редко, что оптимизации не имеют значения. Принимая во внимание количество инструкций, которые ЦП может выполнять в секунду, очевидно, что блок кода должен выполняться очень очень часто, чтобы оптимизация в нем имела какой-либо эффект. Таким образом, в 97% случаев ваши оптимизации будут пустой тратой времени. Но он также говорит, что иногда (в 3% случаев) ваши оптимизации будут иметь значение . И, очевидно, искать эти 3% - все равно что искать иголку в стоге сена. Если вы просто решите «оптимизировать свой код» в целом, вы потратите время на первые 97%. Вместо этого вам нужно сначала найти 3%, которые действительно нуждаются в оптимизации. Другими словами, запустите свой код через профилировщик, и пусть он скажет вам, какой код занимает больше всего процессорного времени. Тогда вы знаете, где оптимизировать. И тогда ваши оптимизации больше не преждевременны.
Другими словами, запустите свой код через профилировщик, и пусть он скажет вам, какой код занимает больше всего процессорного времени. Тогда вы знаете, где оптимизировать. И тогда ваши оптимизации больше не преждевременны. Другими словами, запустите свой код через профилировщик, и пусть он скажет вам, какой код занимает больше всего процессорного времени. Тогда вы знаете, где оптимизировать. И тогда ваши оптимизации больше не преждевременны.Чрезвычайно маловероятно, что такие микрооптимизации существенно повлияют на ваш код в каких-либо обстоятельствах, кроме самых экстремальных (встроенные системы реального времени?). Возможно, вам лучше потратить время на то, чтобы позаботиться о том, чтобы ваш код был читабельным и поддерживаемым.
В случае сомнений всегда начинайте с вопроса Дональда Кнута:
http://shreevatsa.wordpress.com/2008/05/16/premature-optimization-is-the-root-of-all-evil/
Или, для чуть менее строгого подхода к микрооптимизации:
Преждевременная оптимизация может быть опасной, лучше всего написать приложение, не беспокоясь об этом, а затем найдите медленные точки и оптимизируйте их. Если вас это действительно беспокоит, используйте язык более низкого уровня. Интерпретируемый язык, такой как javascript, будет стоить вам некоторой вычислительной мощности по сравнению с языком более низкого уровня, таким как C.
Это как просить рыбу, когда я предпочитаю научить вас ловить рыбу.
Есть простые способы лично убедиться, сколько времени занимает все. Я предпочитаю просто скопировать код 10 раз, а затем завернуть его в цикл из 10 ^ 8 раз. Если я запускаю его и смотрю на часы, количество секунд, которое требуется, переходит в наносекунды.
Сказать «не проводить преждевременную оптимизацию» - значит «не быть». Если вы хотите, чтобы все было в порядке, вы можете попробовать метод активной настройки производительности, например этот .
Кстати, мой любимый способ кодирования вашего цикла:
for (i = N; --i >= 0;){...}
В данном конкретном случае> vs =, вероятно, не является проблемой производительности. ОДНАКО> обычно более безопасный выбор, потому что предотвращает случаи, когда вы модифицировали код, ускользая в сорняки и застревая в бесконечном цикле.
Большинство сравнений имеют одинаковую скорость, потому что процессор просто сравнивает их во всех аспектах, а затем после этого он принимает решение на основе флагов, сгенерированных этим предыдущим сравнением, поэтому сигнал сравнения не не имеет значения вообще. Но некоторые архитектуры пытаются ускорить этот процесс на основе значения, с которым вы сравниваете, например, сравнения с 0.
Насколько мне известно, побитовые операции - самые дешевые операции, немного быстрее, чем сложение и вычитание. Операции умножения и деления немного дороже, а сравнение - это самая высокая операция по инерции.
Но некоторые архитектуры пытаются ускорить этот процесс на основе значения, с которым вы сравниваете, например, сравнения с 0.Насколько мне известно, побитовые операции - самые дешевые операции, немного быстрее, чем сложение и вычитание. Операции умножения и деления немного дороже, а сравнение - это самая высокая операция по инерции.
Но некоторые архитектуры пытаются ускорить этот процесс, основываясь на величине, с которой вы сравниваете, например, при сравнении с 0.Насколько мне известно, побитовые операции - самые дешевые операции, немного быстрее, чем сложение и вычитание. Операции умножения и деления немного дороже, а сравнение - самая высокая операция по выбору.