Это было задано давно, но я столкнулся с решением, которое здесь не упоминалось, так что, возможно, кто-то все еще заинтересован.
В моем случае эти исключения уже были обнаружены внутри Unity (или чем-то еще), но мои Настройки исключений в Visual Studio заставили их все еще появляться. Мне просто пришлось снять флажок «Перерыв, когда отображается этот тип исключения», и приложение продолжало нормально работать.
Плохой код всегда может превзойти скорость процессора.
Отличный пример см. в столбце Coding Horror и прокрутите вниз до раздела с описанием книги Programming Pearls . Здесь воспроизведен график, показывающий, как для определенного алгоритма TRS-80 с 8-разрядным процессором 4,77 МГц может превзойти 32-разрядный чип Alpha.
Текущая тенденция к ускорению заключается в добавлении большего количества ядер, потому что заставить отдельные ядра работать быстрее сложно . Таким образом, совокупная скорость увеличивается, но линейные задачи не всегда приносят пользу.
Будем надеяться, что скорость сети не изменится, и мы сможем передавать по сети достаточно данных, чтобы не отставать от процессоров ...
Как упоминалось, всегда будут узкие места
Да, мы находимся на этапе, когда оптимизация имеет значение, и она будет там в обозримом будущем. Потому что:
Несмотря на то, что процессоры становятся все быстрее и быстрее, вы всегда можете оптимизировать
(это примеры из реального мира, которые я видел за последние полгода).
Различные части сложных компьютерных систем считаются дорогими по разному точки вычислительной истории. Вы должны измерить узкие места и решить, где приложить усилия.
Предположим, в вашем ЦП столько транзисторов, сколько субатомных частиц во Вселенной, и его часы работают с частотой жестких космических лучей, вы все равно можете превзойти его.
Если вы хотите опережать последние частоты процессора, просто добавьте еще один уровень вложенности в свои циклы или добавьте еще один уровень вложенности в вызовы подпрограмм.
Или, если вы хотите быть действительно профессиональным, добавьте еще один уровень абстракции.
Это несложно: -)
В конечном итоге мы не сможем стать быстрее, в конечном итоге мы будем ограничены пространством, поэтому вы видите новые процессоры с тактовой частотой 3 ГГц и многоядерными ... Так что да, оптимизация все еще необходима.
Стоимость оптимизации очень мала, поэтому я сомневаюсь, что возникнет необходимость отказаться от нее. Настоящая проблема состоит в том, чтобы найти задачи для использования всей имеющейся вычислительной мощности - поэтому вместо того, чтобы отказываться от оптимизации, мы будем оптимизировать нашу способность делать что-то в параллельном .
Оптимизирующий код всегда будет требоваться до некоторой степени, а не только для ускорения скорости выполнения и уменьшения использования памяти. Например, поиск оптимального энергоэффективного метода обработки информации будет основным требованием в центрах обработки данных. Навыки профилирования станут более важными!
Верно или нет, на мой взгляд, это уже происходит, и это не всегда плохо. Лучшее оборудование действительно дает разработчику возможность сосредоточить больше усилий на решении текущей проблемы, чем беспокоиться о дополнительных 10% использования памяти.
Оптимизация бесспорна, но только тогда, когда это необходимо. Я думаю, что дополнительная мощность оборудования просто уменьшает количество случаев, когда это действительно необходимо. Однако тому, кто пишет программное обеспечение для запуска космического корабля на Луну, лучше оптимизировать свой код :)
Учитывая, что компьютеры примерно в тысячу раз быстрее, чем они были несколько десятилетий назад, но, как правило, не кажутся намного быстрее, я бы сказал, что нам предстоит ДОЛГОЙ путь, прежде чем мы перестань беспокоиться об оптимизации. Проблема в том, что по мере того, как компьютеры становятся более мощными, они заставляют компьютеры выполнять все больше и больше работы за нас, чтобы мы могли работать на более высоких уровнях абстракции. Оптимизация на каждом уровне абстракции остается важной.
Да, компьютеры делают многие вещи намного быстрее: вы можете нарисовать Мандельброта за считанные минуты, что раньше требовало нескольких дней компьютерного времени. GIF загружается практически мгновенно, вместо того, чтобы рисовать на экране за видимые секунды. Многие вещи быстрее. Но просмотр, например, не намного быстрее. Обработка текста не намного быстрее. По мере того, как компьютеры становятся более мощными, мы просто ожидаем большего и заставляем компьютеры делать больше.
Оптимизация будет иметь важное значение в обозримом будущем. Однако микрооптимизации гораздо менее важны, чем раньше. Самой важной оптимизацией в наши дни может быть выбор алгоритма. Вы выбираете O (n log n) или O (n ^ 2) .... и т. Д.
Оптимизация будет по-прежнему необходима во многих ситуациях, в частности:
Системы реального времени, где время ЦП в цене
Встроенные системы, где память - это память в цене
Серверы, где многие процессы требуют внимания одновременно
Игры, где трехмерная трассировка лучей, аудио, AI и сеть может сделать программу очень требовательной
Двукратное увеличение вычислительной мощности не очень помогает уменьшить ужас вашего паршивого поиска n ^ 2.
Скорость компьютера не всегда может преодолеть человеческую ошибку. Вопросы могут быть сформулированы так: « Станут ли процессоры достаточно быстрыми , чтобы компиляторы могли найти время , чтобы выявить (и исправить) проблемы реализации ». Очевидно, что (в обозримом будущем) потребуется оптимизация кода, чтобы исправить проблемы типа художника Шлемиэля .
Разработка программного обеспечения по-прежнему заключается в том, чтобы точно сказать компьютеру , что ему делать. делать. «Все более быстрые» процессоры дадут нам возможность разрабатывать все более абстрактные и естественные языки программирования , в конечном итоге до такой степени, что компьютеры принимают наши намерения и реализуют все низкоуровневые детали ... когда-нибудь.
Чем быстрее работают компьютеры, тем больше мы от них ожидаем.
Пока одни люди пишут медленный код, который использует чрезмерные ресурсы, другим придется оптимизировать свой код, чтобы обеспечить эти ресурсы быстрее и вернуть скорость.
Я нахожу удивительным, насколько творчески некоторые разработчики могут писать неоптимальный код. На моей предыдущей работе один парень написал функцию для вычисления времени между двумя датами, продолжая увеличивать одну дату и сравнивая, например.
Закон Мура говорит о том, сколько транзисторов мы можем упаковать в микросхему - он ничего не говорит о том, что эти транзисторы могут переключаться со все более высокой скоростью. Действительно, в последние несколько лет тактовые частоты более или менее стагнировали - мы просто продолжаем получать все больше и больше «ядер» (по сути, целых процессоров) на чип. Чтобы воспользоваться этим, требуется распараллеливание кода, поэтому, если вы пишете «наивно», волшебный оптимизатор будущего будет занят обнаружением скрытого параллелизма в вашем коде, чтобы он мог передать его на несколько ядер (что более реалистично, для в обозримом будущем вам придется очень сильно помогать вашему компилятору; -).
Будь то более быстрый код для большего количества многоугольников в видеоигре или более быстрые алгоритмы для торговли на финансовых рынках, если есть конкурентное преимущество в скорости, оптимизация все равно будет важна. Вам не нужно обгонять льва, который преследует вас и вашего приятеля - вам просто нужно обогнать своего приятеля.
Мир меняется, и нам нужно меняться вместе с ним. Когда я только начинал, быть хорошим программистом означало знать все маленькие микрооптимизации, которые можно было бы сделать, чтобы выжать еще 0,2% из подпрограммы, манипулируя указателями в C и другими подобными вещами. Сейчас я трачу гораздо больше времени на то, чтобы сделать алгоритмы более понятными, поскольку в долгосрочной перспективе это более ценно. Но - всегда есть что оптимизировать, и всегда есть узкие места. Больше ресурсов означает, что люди ожидают большего от своих систем, поэтому небрежность - недопустимый вариант для профессионала.
Однако стратегии оптимизации меняются по мере увеличения скорости / памяти / ресурсов для работы.
Некоторая оптимизация имеет не причем со скоростью. Например, при оптимизации многопоточных алгоритмов вы можете оптимизировать сокращение общего количества общих блокировок. Добавление большей вычислительной мощности в виде скорости (или, что еще хуже, процессоров) может не иметь никакого эффекта, если ваша текущая вычислительная мощность тратится на ожидание блокировок .... Добавление процессоров может даже снизить общую производительность, если вы делаете что-то неправильно . Оптимизация в этом случае означает попытку уменьшить количество блокировок и сохранить их как можно более детализированными, вместо того, чтобы пытаться уменьшить количество инструкций.
Пока все программисты с первого раза не напишут оптимальный код, всегда будет место для оптимизации. Между тем реальный вопрос заключается в следующем: для чего оптимизировать в первую очередь?
Оптимизация - это не только скорость. Закон Мура не распространяется на компьютерную память. Кроме того, оптимизация часто представляет собой процесс компиляции кода для использования инструкций, специфичных для процессора. Это лишь некоторые из оптимизаций, которые, на мой взгляд, не будут решены более быстрыми процессорами.
Другие ответы, похоже, концентрируются на скорости. Это хорошо. Реальная проблема, которую я вижу, заключается в том, что если вы оптимизируете свой код, для его запуска потребуется меньше энергии. В вашем центре обработки данных меньше тепла, ваш ноутбук работает дольше, ваш телефон работает больше суток без подзарядки. На этом конце рынка существует реальное давление отбора.
Оптимизация всегда будет необходима, потому что смягчающим фактором закона Мура является раздутое ПО .
Программное обеспечение становится медленнее быстрее, чем оборудование становится быстрее.
PS На более серьезном примечании: по мере того, как вычислительная модель переходит на параллельную обработку, код оптимизация становится более важной. Если вы оптимизируете свой код вдвое, и он будет работать 5 минут вместо 10 минут на одном поле, это может быть не так впечатляюще. Следующий компьютер с двукратной скоростью это компенсирует. Но представьте, что вы запускаете свою программу на 1000 процессоров. Тогда любая оптимизация экономит МНОГО машинного времени. И электричество. Оптимизируйте и спасите Землю! :)
Вычислительные задачи, кажется, разделены примерно на две большие группы.
Большинство проблем попадают в эту первую категорию. Например, трехмерная растеризация в реальном времени. Долгое время эта проблема была недоступна для обычной бытовой электроники. Не существовало убедительных 3D-игр или других программ, которые могли бы создавать миры в реальном времени на Apple] [. В конце концов, технологии догнали, и теперь эта проблема вполне достижима. Похожая проблема - моделирование сворачивания белка. До недавнего времени, невозможно было преобразовать известную пептидную последовательность в полученную молекулу белка, но современное оборудование делает это возможным за несколько часов или минут обработки.
Однако есть несколько проблем, которые по своей природе могут поглотить все доступные вычислительные ресурсы. Большинство из них представляют собой динамические физические симуляции. Очевидно, что можно создать вычислительную модель, скажем, погоды. Мы занимаемся этим почти столько же, сколько у нас есть компьютеры. Однако такая сложная система выигрывает от повышенной точности. моделирование во все более мелком пространственно-временном разрешении улучшает предсказания побитно. Но независимо от того, насколько точна любая данная симуляция, есть место для большей точности с последующими преимуществами.
Оба типа задач очень часто используются для оптимизации всех видов. Второй тип довольно очевиден. Если программа, выполняющая моделирование, немного улучшится, то она будет работать немного быстрее, давая результаты немного раньше или с большей точностью.
Первый, однако, немного более тонкий. В течение определенного периода времени никакая оптимизация не имеет смысла, поскольку не существует компьютера, который был бы достаточно быстрым для этого. Через некоторое время оптимизация становится бессмысленной, поскольку оборудование, на котором она работает, работает во много раз быстрее, чем необходимо. Но есть узкое окно, в течение которого оптимальное решение будет приемлемо работать на текущем оборудовании, а неоптимальное решение - нет. в течение этого периода тщательно продуманная оптимизация может стать разницей между продуктом, первым вышедшим на рынок, и продуктом, который также был запущен.
давая результаты немного раньше или с большей точностью.Первый, однако, немного более тонкий. В течение определенного периода времени никакая оптимизация не имеет смысла, поскольку не существует компьютера, который был бы достаточно быстрым для этого. Через некоторое время оптимизация становится бессмысленной, поскольку оборудование, на котором она работает, работает во много раз быстрее, чем необходимо. Но есть узкое окно, в течение которого оптимальное решение будет приемлемо работать на текущем оборудовании, а неоптимальное решение - нет. в течение этого периода тщательно продуманная оптимизация может быть разницей между продуктом, первым вышедшим на рынок, и продуктом, который также был запущен. давая результаты немного раньше или с большей точностью.
Первый, однако, немного более тонкий. В течение определенного периода времени никакая оптимизация не имеет смысла, поскольку не существует компьютера, который был бы достаточно быстрым для этого. Через некоторое время оптимизация становится бессмысленной, поскольку оборудование, на котором она работает, работает во много раз быстрее, чем необходимо. Но есть узкое окно, в течение которого оптимальное решение будет приемлемо работать на текущем оборудовании, а неоптимальное решение - нет. в течение этого периода тщательно продуманная оптимизация может стать разницей между продуктом, первым вышедшим на рынок, и продуктом, который также был запущен.
поскольку оборудование, на котором оно работает, работает во много раз быстрее, чем необходимо. Но есть узкое окно, в течение которого оптимальное решение будет приемлемо работать на текущем оборудовании, а неоптимальное решение - нет. в течение этого периода тщательно продуманная оптимизация может стать разницей между продуктом, первым вышедшим на рынок, и продуктом, который также был запущен. поскольку оборудование, на котором оно работает, работает во много раз быстрее, чем необходимо. Но есть узкое окно, в течение которого оптимальное решение будет приемлемо работать на текущем оборудовании, а неоптимальное решение - нет. в течение этого периода тщательно продуманная оптимизация может стать разницей между продуктом, первым вышедшим на рынок, и продуктом, который также был запущен.Компьютер похож на комнату подростка.
Он никогда не будет достаточно большим, чтобы вместить весь мусор.