Алгоритмы для современного оборудования?

Ответ 1

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

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

Если вам интересно, наряду с ошибками страницы и медленными операциями с дисками, вы можете знать:

• Кэш-запросы - ориентированный на данные дизайн
• Кэш-хиты - Уменьшение ненужных ветки/прыжки.
• Прогнозирование кэш-памяти они вписываются в кеш процессора.

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

Ответ 2

Одна важная вещь заключается в том, чтобы понять, что наиболее распространенное использование нотации Big-O (говорить о сложности выполнения) - это только половина истории - там другая половина, а именно пространственная сложность (которая также может быть выражена с помощью big-O), что также может быть весьма актуальным.

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

Ответ 3

Я объясню ответ GregS: разница между эффективной сложностью и асимптотической сложностью. Асимптотическая сложность игнорирует постоянные факторы и действительна только для "достаточно больших" входов. Часто "достаточно большой" может на самом деле означать "больше, чем любой компьютер может иметь дело сейчас и в течение нескольких десятилетий"; это - то, где теория (оправданно) получает плохую репутацию. Конечно, есть также случаи, когда "достаточно большой" означает n = 3!

Более сложный (и, следовательно, более точный) способ взглянуть на это - сначала спросить: "Каков диапазон размеров проблем, которые вас интересуют?" Затем вам нужно измерить эффективность различных алгоритмов в этом диапазоне размеров, чтобы почувствовать "скрытые константы". Или вы можете использовать более тонкие методы алгоритмической асимптотики, которые фактически дают вам оценки по константам.

Другая вещь, на которую нужно обратить внимание, - это точки перехода. Конечно, алгоритм, который работает в 2 n ² времени, будет быстрее, чем тот, который работает в 10 ¹⁶ n log (n) раз для всех n 1,99 * 10 ¹⁷. Таким образом, квадратичный алгоритм будет выбран (если вы не имеете дело с размерами данных, о которых заботится ЦЕРН). Даже субэкспоненциальные члены могут укусить - 3 n ³ намного лучше, чем n ³ + 10 ¹⁶ n ² для n 5 * 10 ¹⁵ (предполагая, что это фактические сложности).

Ответ 4

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

Ответ 5

O (n) - только часть истории - большая часть, а зачастую и доминирующая часть, но не всегда доминирующая часть. Как только вы перейдете к оптимизации производительности (который не следует делать слишком рано в вашей разработке), вам необходимо рассмотреть все ресурсы, которые вы используете, Вы можете обобщить Закон Amdahl, чтобы означать, что на ваше время исполнения будет доминировать самый ограниченный ресурс. Обратите внимание, что это также означает, что конкретное оборудование, на котором вы выполняете, также должно быть рассмотрено. Программа, которая высоко оптимизирована и чрезвычайно эффективна для массового параллельного компьютера (например, CM или MassPar), вероятно, не будет хорошо работать на большой векторной коробке (например, Cray-2) или на высокоскоростном микропроцессоре. Эта программа может даже не преуспевать в массиве мощных микропроцессоров (стиль map/reduce). Различные оптимизации для различных балансов кэша, связи ЦП, ввода/вывода, скорости процессора, доступа к памяти и т.д. Означают разную производительность.

Назад, когда я потратил время на оптимизацию производительности, мы будем стремиться к "сбалансированной" производительности по всей системе. Супер-быстрый процессор с медленной системой ввода-вывода редко имел смысл и так далее. O() обычно рассматривает только сложность ЦП. Возможно, вам удастся обменять пространство памяти (разворачивающиеся циклы не делают O() смысл, но часто помогают в реальной производительности); озабоченность по поводу кеш-хитов вице-линейных макетов памяти; виртуальный против реальной памяти; лента против вращающегося диска против RAID и т.д. Если в вашей производительности преобладает активность процессора, при этом входы/выходы и память ломаются, большой-O - ваша главная проблема. Если ваш процессор находится на уровне 5%, а сеть - на 100%, может быть, вы можете уйти от big-O и работать с I/O, кэшированием и т.д.

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