Алгоритмы (и эффективность в целом) становятся менее важными?

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

Мне очень нравится пример из книги « Введение в алгоритмы» , который иллюстрирует важность эффективности алгоритма:

Давайте сравним две алгоритмы сортировки: вставка сортировки и сортировки слиянием . Их сложность и соответственно. Обычно сортировка слиянием имеет больший постоянный коэффициент, поэтому предположим, что . O ( n log n ) = c 2 n lg n c 1 < c $O(n^2) = c_1n^2$$O(n\log n) = c_2n \lg n$$c_1 < c_2$

Чтобы ответить на ваш вопрос, мы оцениваем время выполнения более быстрого компьютера (A), выполняющего алгоритм сортировки вставкой, по сравнению с более медленным компьютером (B), выполняющим алгоритм сортировки слиянием.

Мы предполагаем:

• размер входной задачи составляет 10 миллионов чисел: ;$n=10^7$
• компьютер А выполняет инструкций в секунду (~ 10 ГГц);$10^{10}$
• компьютер B выполняет только инструкций в секунду (~ 10 МГц);$10^7$
• постоянные коэффициенты (что немного завышено) и (в действительности меньше).с 2 = $c_1=2$$c_2=50$

Так что с этими допущениями требуется

10

для компьютера Б.

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

Однако это не все о сложности алгоритма. Сегодня практически невозможно добиться значительного ускорения, просто используя машину с более высокой частотой процессора. Люди должны разрабатывать алгоритмы для многоядерных систем, которые хорошо масштабируются. Это также сложная задача, потому что с увеличением количества ядер увеличиваются накладные расходы (например, для управления доступом к памяти). Так что почти невозможно добиться линейного ускорения.

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

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

Во-первых, объем обрабатываемых данных растет в геометрической прогрессии. Это привело к изучению алгоритмов квазилинейного времени и области больших данных . Подумайте, например, о поисковых системах - они должны обрабатывать большие объемы запросов, обрабатывать большие объемы данных и делать это быстро. Алгоритмы важны как никогда.

Во-вторых, область машинного обучения становится все сильнее и полнее алгоритмов (хотя и отличается от того, что вы изучаете в своей БА). Область процветает, и очень часто изобретается действительно новый алгоритм, который значительно повышает производительность.

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

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

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

Знание алгоритмов намного больше, чем умение писать быстрые алгоритмы.

Он также дает вам методы решения проблем (например, разделяй и властвуй, динамическое программирование, жадность, редукция, линейное программирование и т. Д.), Которые можно затем применять при приближении к новой и сложной задаче. Наличие подходящего подхода обычно приводит к кодам, которые проще и гораздо быстрее пишутся. Поэтому я должен не согласиться с ответом Кевина, поскольку коды, которые не тщательно составлены, часто не только медленны, но и сложны. Мне нравится эта цитата Дэвида Парнаса:

Я часто слышу, как разработчики называют «кем-то, кто знает, как быстро построить большую систему». Нет никакой хитрости в быстром создании больших систем; чем быстрее вы их построите, тем больше они станут!

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

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

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

Что касается важности эффективности программного обеспечения, я процитирую закон Вирта:

Программное обеспечение работает медленнее, быстрее, чем аппаратное.

Ларри Пейдж недавно повторил, что программное обеспечение становится в два раза медленнее каждые 18 месяцев, и поэтому оно опережает закон Мура.

Да , они «относительно» менее важны в широкой отрасли. Текстовый редактор может быть «достаточно быстрым» и не требует особых улучшений. Большая часть ИТ-усилий направлена ​​на то, чтобы компонент A, написанный на Java, работал с компонентом B, написанным на C, правильно связывался через очередь сообщений, написанную на Cobol (или чем-то еще), или чтобы доставить продукт на рынок и т. Д.

Кроме того, архитектура усложнилась. Когда у вас были простые старые простые процессоры, в которых у вас было 1 инструкция на цикл, и вы писали в сборке, оптимизация была «легкой» (вам просто нужно было подсчитать количество инструкций). В настоящее время у вас нет простого процессора, но есть полностью конвейерный, суперскалярный, неупорядоченный процессор с переименованием регистров и многоуровневым кешем. И вы пишете не на ассемблере, а на C / Java / и т.д. где код скомпилирован / JITed (обычно для лучшего кода, чем вы или я бы написали на ассемблере), или в Python / Ruby / ..., где код интерпретируется, и вы отделены несколькими уровнями абстракции от машины. Микрооптимализация трудна, и большинство программистов достигли бы противоположного эффекта.

Нет , они как никогда важны в исследованиях и в «абсолютных» терминах. Есть области, где важна скорость, поскольку они работают с большим объемом данных. В этом масштабе сложности имеют значение, как показано на примере Павла.

Однако есть и другие случаи - отказ от алгоритмов все еще остается выбором, если скорость имеет значение (HPC, встроенные устройства и т. Д.). Вы найдете во многих университетах группы, специализирующиеся на компиляторах и / или оптимизации программного обеспечения. Например, простая замена порядка циклов может ускорить процесс в тысячу раз только потому, что он эффективно использует кэш - хотя это может быть пограничным примером, за последние 30 лет разрыв в памяти ЦП увеличился в 1000 раз. Также компьютерная архитектура является частью CS. Поэтому многие улучшения в скорости вычислений фактически являются частью общего поля CS.

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

Также скорость может означать лучший UX. Во многих обзорах ОС мобильных телефонов указывается, какой из них является «более быстрым», и хотя это можно сделать с помощью «хитростей», это, безусловно, область исследования. Также вы хотите получить доступ к вашим данным быстрее и быстрее делать то, что вам нужно. Иногда это означает, что вы можете сделать больше - в играх у вас есть 0,017, чтобы делать все, и чем быстрее вы набираете, тем больше конфет вы можете положить.

Это интересная дискуссия. И нам есть на что посмотреть.

1. Теоретическая информатика - это развивающаяся наука, которая означает, что со временем мы найдем новые и лучшие способы решения проблем, например, улучшенные алгоритмы поиска и сортировки.

2. Большие сообщества / большие библиотеки - поскольку многие люди проделали большую работу, мы можем просто опираться на их работу и использовать алгоритмы, которые они уже создали и даже закодировали. И эти библиотеки будут обновляться со временем, что позволит нам автоматически получать доступ к более эффективным программам / алгоритмам.

3. Развитие - Теперь у нас есть проблема, я думаю. Многие программисты не являются компьютерными учеными, поэтому они пишут код для решения бизнес-задач, а не технических / теоретических проблем, и они были бы рады использовать пузырьковую сортировку, например, как быструю. И здесь скорость аппаратного обеспечения позволяет плохим программистам избегать использования плохих алгоритмов и плохих методов кодирования. Память, скорость процессора, объем памяти больше не являются проблемой, и каждые несколько месяцев все становится больше, быстрее и дешевле. Я имею в виду, посмотрите на новые мобильные телефоны. Сейчас они более продвинуты, чем мейнфрейм-компьютеры / серверы 1970-х / 80-х годов. Больше памяти, больше вычислительной мощности, более быстрая память.

4. Пользовательский интерфейс и данные - пользовательский интерфейс / пользовательский опыт и данные теперь считаются более важными, чем суперэффективный код в большинстве областей разработки. Так что скорость становится и возникает только тогда, когда пользователю приходится долго ждать. Если мы даем пользователю хороший внешний вид, и он получает хороший ответ от приложения, он счастлив. И если бизнес знает, что все данные хранятся безопасно и надежно, и они могут извлекать их и манипулировать ими в любое время, им все равно, сколько места им нужно.

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

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

Программное обеспечение работает медленнее, быстрее, чем аппаратное.

Есть интересные параллели этой идеи с явлениями, наблюдаемыми в экономике. Обратите внимание, что экономика имеет много глубоких связей с информатикой, например, в планировании, например, когда ограниченные ресурсы (например, потоки и т. Д.) Распределяются по запросу с помощью алгоритмов «распределения нагрузки». Другим примером является то, что называется очередь производитель-потребитель. Также аукционы.

Также, например, Список одноименных законов, Википедия :

Закон Паркинсона - «Работа расширяется, чтобы заполнить время, доступное для ее завершения». Придумано К. Норткотом Паркинсоном (1909–1993), который также придумал свое следствие: «Расходы растут, чтобы удовлетворить доход». В компьютерах: программы расширяются, чтобы заполнить всю доступную память.

Существует некоторое сильное сходство и с парадоксом Джевона, который наблюдался в увеличении потребления энергии после того, как более эффективные паровые двигатели Watt начали заменять конструкцию Newcomen, но использование или распространение двигателей увеличилось:

В экономике парадокс Джевонса (/ ˈdʒɛvənz /; иногда эффект Джевонса) состоит в том, что технический прогресс, который повышает эффективность использования ресурса, имеет тенденцию увеличивать (а не уменьшать) скорость потребления этого ресурса.

Аналогия в том, что аппаратное обеспечение является ресурсом, а программное обеспечение похоже на потребление ресурса (иначе говоря, предложение против спроса). Таким образом, программные и аппаратные средства (и достижения в каждом из них) существуют в тесной взаимосвязанной симбиотической петле обратной связи друг с другом, в некотором смысле, одновременно развивающейся . Есть много сложных и взаимосвязанных факторов, влияющих на это взаимодействие, например:

• коэволюции
• Эволюционная раса
• Закон Мура
• Распространение языков программирования / структур
• Относительное алгоритмическое и аппаратное ускорение

Нет, в основном, учитывая космическую сложность! Емкость обычного компьютера растет в геометрической прогрессии.