Где узнать о низкоуровневых, высокопроизводительных продуктах? - PullRequest
4 голосов
/ 31 августа 2011

Это фактически вопрос из 2 частей:

Для людей, которые хотят сжать каждый такт, люди говорят о конвейерах, локальности кэша и т. Д.

  1. Я видел эти техники исполнения низкого уровня, упомянутые здесь и там, но я не видел хорошего введения в предмет от начала до конца. Любые рекомендации по ресурсам? (Google дал мне определения и документы, где я действительно оценил бы какие-то проработанные примеры / учебные пособия из реальных материалов)

  2. Как можно измерить такие вещи? Как, например, в профилировщике? Я знаю, что мы всегда можем изменить код, увидеть улучшения и теоретизировать в ретроспективе, мне просто интересно, есть ли установленные инструменты для работы.

(я знаю, что оптимизация алгоритма - это то, где порядки величин. Меня интересует металл здесь)

Ответы [ 5 ]

3 голосов
/ 31 августа 2011

Припев ответов: «Не оптимизируйте преждевременно».Как вы упомянули, вы получите гораздо большую производительность от лучшего дизайна, чем от лучшего цикла, и ваши сопровождающие также оценят его.Много-много сборок.Не MUL степенью двойки, когда вы можете сдвинуться.Узнайте странное использование xor для копирования и очистки регистров.Для конкретных ссылок, http://www.mark.masmcode.com/ и http://www.agner.org/optimize/

Да, вам нужно время вашего кода.На * nix это может быть так же просто, как на time { commands ; }, но вы, вероятно, захотите использовать полнофункциональный профилировщик.GNU gprof с открытым исходным кодом http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html

Если это действительно ваша вещь, дерзайте, веселитесь и помните, много-много математики на битовом уровне.И твои помощники будут ненавидеть тебя;)

2 голосов
/ 31 августа 2011

EDIT / REWRITE:

Если вам нужны книги, Майкл Абраш хорошо поработал в этой области, языке Zen of Assembly, ряде журнальных статей, большой черной книге графического программирования и т. Д. Многое из того, что он настраивал, больше не является проблема, проблемы изменились. Из этого вы получите идеи о вещах, которые могут вызвать проблемы с горлышком, и о способах их решения. Самое важное - это рассчитать время и понять, как работают ваши временные измерения, чтобы вы не обманывали себя неправильными измерениями. Придумайте разные решения и попробуйте сумасшедшие, странные решения, вы можете найти оптимизацию, о которой вы не знали и не осознавали, пока не раскрыли ее.

Я только начал читать, но пока MIPS Run (ранняя / первая редакция) выглядит неплохо (обратите внимание, что ARM занял MIPS в качестве лидера на рынке процессоров, поэтому реклама MIPS и RISC немного устарела). Существует множество старых и новых учебников о MIPS. Mips предназначены для повышения производительности (в некотором смысле за счет разработчика программного обеспечения).

Узкие места сегодня попадают в категории самого процессора и входов / выходов вокруг него и того, что связано с этим вводом / выводом. Внутренности самих процессорных микросхем (для систем более высокого уровня) работают намного быстрее, чем может справиться с вводом / выводом, так что вы можете настроить только до тех пор, пока вам не придется выходить из чипа и ждать вечно. Сойти с поезда, от поезда до пункта назначения на полминуты быстрее, когда поездка на поезде была 3 часа, не обязательно стоит оптимизировать.

Все дело в изучении аппаратного обеспечения, вы, вероятно, можете оставаться в мире единиц и нулей и не должны разбираться в реальной электронике. Но, не зная интерфейсов и внутренних компонентов, вы не сможете настроить производительность. Вы можете изменить порядок или изменить несколько инструкций и получить небольшой импульс, но чтобы сделать что-то в несколько сотен раз быстрее, вам нужно нечто большее. Изучение множества различных наборов команд (языков ассемблера) помогает войти в процессоры. Я бы порекомендовал имитировать HDL, например, процессоры на opencores, чтобы понять, как некоторые люди делают свои проекты, и получить четкое представление о том, как действительно выжать часы из задачи. Знание процессоров велико, интерфейсы памяти огромны и требуют изучения, носителей (флэш-памяти, жестких дисков и т. Д.), А также дисплеев и графики, сетей и всех типов интерфейсов между всеми этими вещами. А понимание на уровне часов или как можно ближе к нему - вот что требуется.

1 голос
/ 01 сентября 2011

Да, измерьте, и да, знайте все эти техники.

Опытные люди скажут вам «не оптимизируйте преждевременно», что я называю просто «1003 *« не догадываться ».

Они также скажут: «Используйте профилировщик, чтобы найти узкое место», но у меня есть проблема с этим. Я слышал много историй о людях, использующих профилировщики, и им либо очень нравятся, либо они путаются с их результатами. ТАК полно их.

Что я не слышу много, так это историй успеха , с достигнутыми факторами ускорения.

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

1 голос
/ 01 сентября 2011
1 голос
/ 31 августа 2011

Intel и AMD предоставляют руководства по оптимизации для x86 и x86-64.

http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html/

http://developer.amd.com/documentation/guides/pages/default.aspx

Еще один отличный ресурс - agner.

http://www.agner.org/optimize/

Некоторые ключевые моменты (без определенного порядка):

  • Выравнивание; память, петли / функциональные метки / адреса
  • Cache; невременные подсказки, пропуски страниц и кэша
  • Ветви; прогнозирование ветвлений и предотвращение ветвления с помощью операционных кодов сравнения и перемещения
  • векторизации; используя инструкции SSE и AVX
  • Op-кода; избегая медленных кодов операций, используя преимущества объединения кодов операций
  • Пропускная способность / конвейер; переупорядочение или перемежение кодов операций для выполнения отдельных задач, избегая частичных устареваний и насыщения ALU и FPU процессора
  • Развертывание петли; выполнение нескольких итераций для одного «сравнения циклов, ветвь»
  • Синхронизация; использование атомарного кода операции (или префикса LOCK), чтобы избежать высокоуровневых конструкций синхронизации
...