Закон Вирта все еще остается в силе?

Question

Изречение, сделанное Никлаусом Виртом в 1995 году:

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

• Как вы думаете, это на самом деле правда?
• Как вы должны измерить "скорость" программного обеспечения? По циклам процессора, а точнее по времени, вам нужно выполнить какое-то задание?
• Что касается программного обеспечения, которое на самом деле становится быстрее и экономнее (измеряется циклами ЦП и МБ ОЗУ) и более отзывчивым с новыми версиями, такими как Firefox 3.0 по сравнению с 2.0, Linux 2.6 по сравнению с 2.4, Ruby 1.9 по сравнению с 1.8. Или совершенно новое программное обеспечение, которое на порядок быстрее, чем старое (например, Google V8 Engine )? Разве это не отрицает этот закон?

Answer 1

Дело не в том, что программное обеспечение становится медленнее, а в том, что его сложность увеличивается.

Теперь мы опираемся на множество уровней абстракции.
Когда в последний раз люди на SO писали на ассемблере?
Большинство никогда не будет и никогда не будет.

Answer 2

Да, я думаю, что это правда.

Как измерить скорость программного обеспечения? Хорошо время для решения задач является актуальным показателем. Для меня, как пользователя программного обеспечения, мне все равно, есть ли на моей машине 2 или 16 ядер. Я хочу, чтобы моя ОС загружалась быстро, мои программы запускались быстро, и я абсолютно не хочу ждать простых действий, таких как открытие файлов. Программное обеспечение должно просто чувствовать быстро. Итак ... при загрузке Windows Vista нет быстрого программного обеспечения, которое я наблюдаю.

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

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

Answer 3

Это неправильно. Правильно

Программное обеспечение работает медленнее с той же скоростью по мере того, как аппаратное обеспечение становится быстрее. Причина в том, что это в основном определяется человеческим терпением, которое остается неизменным. Также не стоит упоминать, что современное программное обеспечение работает более 30 лет назад, даже если мы не обращаем на это внимание.

Answer 4

В целом закон остается в силе. Как вы заявили, есть исключения, «которые подтверждают правило». Мой брат недавно установил Win3.1 на свой ПК с тактовой частотой 2 ГГц, и он загружается в мгновение ока.

Я полагаю, есть много причин, по которым закон гласит:

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

Мне кажется, что отсутствие немедленного всплывающего диалогового окна в FF вызывает раздражение, так как главное окно появляется после запуска приложения, и я никогда не уверен, что щелчок «сработал». ОО тоже страдает от этого.

В Интернете есть несколько статей об изменении восприятия скорости программного обеспечения без изменения фактической скорости.

EDIT:

В дополнение к вышеупомянутым пунктам, примером низкой важности, придаваемой эффективности, является этот сайт, или, скорее, большинство других сайтов вопросов и ответов. Этот сайт всегда был разработан, чтобы быть быстрым и отзывчивым, и это показывает. Сравните это с другими сайтами - я обнаружил, что сайты на phpBB гибкие, но медленные. Google - еще один пример придания высокой значимости скорости (он даже говорит о том, сколько времени занял поиск) - сравните с другими поисковыми системами, которые были рядом, когда Google запускался (теперь они все быстрые благодаря Google).

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

Answer 5

Цитата из исследования UX:

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

Детальное сравнение UX на винтажном Mac и современном Dual Core: http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

Answer 6

Исходя из собственного опыта, я не согласен с законом Вирта.

Когда я впервые подошел к компьютеру (в 80-х годах), время для отображения небольшого неподвижного изображения было ощутимо. Сегодня мой компьютер может декодировать и отображать фильмы в формате 1080p AVCHD в режиме реального времени.

Другим показателем является количество кадров в секунду в видеоиграх. Не так давно это было около 15 кадров в секунду. Сегодня от 30 до 60 кадров в секунду не редкость.

Answer 7

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

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

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

Answer 8

Скизз и Дазмоган правильно поняли.

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

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

Я занимаюсь настройкой производительности. (Мой метод выбора - случайная остановка.) Почти во всех случаях причиной медлительности является чрезмерный дизайн класса и структуры данных.

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

Как говорит Бомпюи, мы опираемся на множество уровней абстракции. Это именно проблема.

Answer 9

Да, программное обеспечение в настоящее время может быть медленнее или быстрее, но вы не сравниваете подобное с подобным. У программного обеспечения теперь намного больше возможностей, и от него ожидается намного больше.

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

Дело в том, что да, программное обеспечение работает медленнее, но оно делает больше.

То же самое относится и к людям, которые используют программное обеспечение. Еще в 70-х, чтобы создать презентацию, вы должны были создавать свои собственные прозрачные пленки, возможно, даже с помощью ручки :-). Теперь, если бы вы сделали то же самое, вы бы смеялись из комнаты. Это занимает столько же времени, но качество выше.

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

Answer 10

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

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