Концепция грубой силы

О программировании

Погода на завтра

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

Обратим внимание на то, что такие рассчеты проводятся многократно одним и тем же "приложением", только с новыми данными.

Эффективность = быстродействие

Есть и такие ситуации, когда быстродействие программы непринципиально. Не удивлюсь, например, если при выполнении программ Офиса процессор бóльшую часть времени простаивает или занимается какими-то посторонними делами. Ибо здесь главный тормоз — Оператор.

Но мы будем обсуждать программы, от которых требуется быстродействие.

Криопроцессор с технологией 0.1 нм

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

На самом деле появление более быстрых процессоров следует использовать иначе:
1) это позволит использовать эффективный программный код для обработки больших объемов информации вместо того, чтобы с радостным визгом гонять на них код неэффективный;
2) или можно будет использовать более точные математические модели, требующие бóльшего объема вычислений. Если, конечно, не относиться наплевательски к эффективности.
В результате прогноз погоды станет точнее.

Вы слышали анекдоты о синоптиках? Когда последний раз? А была очень богатая тема!

STL — тормоз

Проведенные мной эксперименты с замером потраченного времени показали, что код с использованием языка Standard Template Library (STL) может работать в разы дольше, чем аккуратно спроектированные структуры данных и операции над ними с применением "чистого С". Это будет показано в архиве Polynomial_p1.zip, который будет опубликован первым.

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

Как добиваться быстродействия

Для этого надо
1) ответственно отнестись к стадии проектирования. В частности, надо хорошо знать предметную область;
2) продумать структуры данных — как правило, чем проще, тем лучше. Проще по сути, а не для программиста;
3) использовать более простые, относительно низкоуровневые, средства программирования;

Это общее правило: на низком уровне получаются более быстродействующие операции. У меня был пример, когда одно и то же вычисление на высокоуровневом языке Maple длилось почти в 80 раз дольше, чем написанное средствами класса Polynomial.

4) коды операций систематически испытывать, замеряя время исполнения. Сравнивая результаты, выбирать более эффективный вариант.

Все это проиллюстрировано на примерах в архиве Polynomial_p1.zip.