О программировании
Погода на завтра
должна быть рассчитана сегодня хотя бы к обеду, а не через неделю. Это мой любимый пример.
Обратим внимание на то, что такие рассчеты проводятся многократно одним и тем же "приложением", только с новыми данными.
Эффективность = быстродействие
Есть и такие ситуации, когда быстродействие программы непринципиально. Не удивлюсь, например, если при выполнении программ Офиса процессор бóльшую часть времени простаивает или занимается какими-то посторонними делами. Ибо здесь главный тормоз — Оператор.
Но мы будем обсуждать программы, от которых требуется быстродействие.
Криопроцессор с технологией 0.1 нм
Ленивые программисты говорят, что если программа работает слишком медленно, то надо просто дождаться появления более быстрого оборудования, и это снимет все проблемы. Вот это и называется концепцией грубой силы.
На самом деле появление более быстрых процессоров следует использовать иначе:
1) это позволит использовать эффективный программный код для обработки больших объемов информации вместо того, чтобы с радостным визгом гонять на них код неэффективный;
2) или можно будет использовать более точные математические модели, требующие бóльшего объема вычислений. Если, конечно, не относиться наплевательски к эффективности.
В результате прогноз погоды станет точнее.
Вы слышали анекдоты о синоптиках? Когда последний раз? А была очень богатая тема!
STL — тормоз
Проведенные мной эксперименты с замером потраченного времени показали, что код с использованием языка Standard Template Library (STL) может работать в разы дольше, чем аккуратно спроектированные структуры данных и операции над ними с применением "чистого С". Это будет показано в архиве Polynomial_p1.zip, который будет опубликован первым.
Проблема STL также в том, что легкость написания кода на нем так и провоцирует программиста к созданию чудовищно неэффективных операций над данными. В предлагаемом архиве будет представлен обзор и критика нескольких таких работ, опубликованных в github.
Как добиваться быстродействия
Для этого надо
1) ответственно отнестись к стадии проектирования. В частности, надо хорошо знать предметную область;
2) продумать структуры данных — как правило, чем проще, тем лучше. Проще по сути, а не для программиста;
3) использовать более простые, относительно низкоуровневые, средства программирования;
Это общее правило: на низком уровне получаются более быстродействующие операции. У меня был пример, когда одно и то же вычисление на высокоуровневом языке Maple длилось почти в 80 раз дольше, чем написанное средствами класса Polynomial.
4) коды операций систематически испытывать, замеряя время исполнения. Сравнивая результаты, выбирать более эффективный вариант.
Все это проиллюстрировано на примерах в архиве Polynomial_p1.zip.