Выполнение максимально возможного исполняемого файла

Question

У меня есть очень большая программа, которую я собирал под визуальной студией (v6 затем перенесен на 2008). Мне нужно, чтобы исполняемый файл выполнялся как можно быстрее. Программа тратит большую часть времени на обработку целых чисел различных размеров и делает очень мало ввода-вывода.

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

Итак, мой вопрос: существуют ли другие параметры компилятора/компоновщика, которые я должен использовать, чтобы ускорить выполнение программы, не контролируемую на странице «Оптимизация» диалогового окна «Свойства».

EDIT: Я уже широко использую профилировщики.

Answer 1

1) Уменьшите наложение с помощью __restrict.

2) Помогите компилятору устранить исключение общего кода или уничтожить код с помощью __pure.

3) Введение в SSE/SIMD можно найти here и here. Интернет не совсем переполнен статьями по теме, но этого достаточно. Для справочного списка встроенных функций вы можете искать MSDN для 'compir intrinsics'.

4) Для «макропараллельности» вы можете попробовать OpenMP. Это стандарт компилятора для простой распараллеливания задач - по сути, вы говорите компилятору, используя несколько #pragmas, что некоторые разделы кода являются реентерабельными, а компилятор автоматически создает потоки для вас.

5) Я второй вопрос interjay о том, что PGO может быть очень полезным. И в отличие от # 3 и # 4, это почти без усилий, чтобы добавить в

Answer 2

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

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

И, в конечном счете, вы, вероятно, никогда не узнаете, что такое «как можно быстрее». В конце концов вам нужно будет согласиться на «это достаточно быстро для наших целей».

Answer 3

Забудьте микро-оптимизацию, такую ​​как то, что вы описываете. Запустите приложение через профилировщик (есть один, включенный в Visual Studio, по крайней мере в некоторых изданиях). Профайлер расскажет вам, где ваше приложение тратит свое время.

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

Answer 4

Profile-guided optimization может привести к большому ускорению. Мое приложение работает на 30% быстрее с помощью сборки PGO, чем обычная оптимизированная сборка. В принципе, вы запускаете свое приложение один раз и позволяете Visual Studio профилировать его, а затем он снова создается с оптимизацией на основе собранных данных.

Answer 5

Я согласен с тем, что все говорили о профилировании. Однако вы указываете «целые числа разных размеров». Если вы делаете много арифметики с несогласованными целыми числами, много времени может быть потрачено впустую при изменении размеров, например, шортах на int, когда выражения оцениваются.

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

Answer 6

У вас есть три пути ускорения приложения:

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

2. Макро-параллелизация - разделить задачу на куски и дать каждому фрагменту отдельный процессор, поэтому на двухъядерном процессоре разделите целое число на два набора и дайте половину каждому процессору.Это зависит от алгоритма, который вы используете - не все алгоритмы могут быть обработаны следующим образом.

3. Микропараллелизация - это похоже на вышеизложенное, но использует SIMD. Вы можете комбинировать это с точкой 2.

Answer 7

Вы спрашиваете, какие опции компилятора могут помочь вам ускорить вашу программу, но вот некоторые общие советы по оптимизации:.

1) Убедитесь, что ваши алгоритмы подходят для работы. Никакое количество возиться с параметрами компилятора не поможет вам, если вы напишете алгоритм O (квадрат квадрата).

2) Нет жестких правил для параметров компилятора. Иногда оптимизируйте скорость, иногда оптимизируйте размер и убедитесь, что время разницы!

3) Поймите платформу, над которой вы работаете. Понимать, как работают кэши для этого ЦП, и писать код, который специально использует преимущества аппаратного обеспечения. Убедитесь, что вы не следуете указателям везде, чтобы получить доступ к данным, которые будут разбивать кеш. Поймите доступные SIMD-операции и используйте встроенные средства, а не записывайте сборку. Только писать сборку, если компилятор определенно не генерирует правильный код (т. Е. Плохо записывает в нераскрытую память). Убедитесь, что вы используете __restrict для указателей, которые не будут псевдонимом. Некоторые платформы предпочитают передавать векторные переменные по значению, а не по ссылке, поскольку они могут сидеть в регистрах - я мог бы продолжить это, но этого должно быть достаточно, чтобы указать вам в правильном направлении!

Надеется, что это помогает,

-Tom

Answer 8

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

Также вы можете бросить оборудование по этой проблеме. Возможно, на вашем ПК уже есть необходимое оборудование, в основном неиспользованное: графический процессор! Одним из способов повышения производительности некоторых типов вычислительно дорогостоящей обработки является ее выполнение на графическом процессоре. Это аппаратная спецификация, но NVIDIA предоставляет API для этого: CUDA. Использование GPU, скорее всего, даст вам гораздо большее преимущество, чем использование процессора.

Answer 9

Проверьте, какой режим/точность вы используете. Каждый из них генерирует совершенно другой код, и вам нужно выбирать, исходя из того, какая точность требуется в вашем приложении.Наш код нуждается в точности (геометрия, графический код), но мы по-прежнему используем/fp: fast (C/C++ -> Опции генерации кода).

Также убедитесь, что у вас есть/arch: SSE2, предполагая, что ваше развертывание охватывает процессоры, поддерживающие SSE2. Это приведет к довольно большой разнице в производительности, поскольку компилятор будет использовать очень мало циклов. Подробности в блоге хорошо освещены SomeAssemblyRequired

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

Используйте __forceinline в горячих точках, если применимо.

Измените горячие точки вашего кода на использование SSE2 и т. Д., Так как ваше приложение, похоже, интенсивно вычисляется.

Answer 10

Вы говорите, что программа очень большая. Это говорит мне, что у него, вероятно, много классов в иерархии.

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

Если программа не была настроена агрессивно, может быть место для массового ускорения в виде операций в середине стека, которые могут быть выполнены по-разному. Они, как правило, очень невинно выглядят и никогда не привлекут ваше внимание. Это не случаи «улучшения алгоритма». Обычно это случаи «хорошего дизайна», которые, как оказалось, находятся на критическом пути.

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

This is an example of what I'm talking about.