Mihail писал(а):
Оптимизатор в любом случае, придется адаптировать к железу. Основная оптимизация производится за счет особенностей конкретного процессора. При этом, кое что можно заимствовать при переходе на другой процессор.
Об этом толкую уже давно. Оптимизировать надо не под конкретное железо, а под конкретную задачу. Например, может быть MD и работает с кэшем и памятью каким-либо очень скоростным способом, но MD-офис был и будет тормозить на любых машинах.
Раз никто не хочет колоться, расскажу о своих жалких экспериментах по оптимизации (1991-2011).
1) Одна из первых моих задач была очень простой. Надо было раскидать значения фазовых сдвигов ФАР из таблиц разработчика в таблицы прошивки. До меня эту программу попытались реализовать на Turbo Pascal, но время бесперебойной работы PC-AT оказалось меньше времени работы программы. Я быстро накидал программку на честном masm-е. Она справилась минут за двадцать. Здесь я столкнулся с явлением избыточной оптимизации - полученные за двадцать минут результаты сбрасывались на перфоленту три рабочих дня.
2) Так как я был явным сторонником языков C и Forth, то абстрактную оптимизацию воспринимал очень настороженно, т.к. самой сильной стороной этих языков считал принцип: "что написал, то и получил". Более того, осилив "Построение и анализ ..." Ахо и компании, я уяснил, что всякие данные - это множество, а всякое множество может быть представлено таким образом, чтобы оптимизировать именно те операции, которые нам потребны. С тех пор с недоверием отношусь к языкам со встроенными списками и множествами.
3) Время шло, компьютеры становились все мощнее. Программа на Turbo Pascal рисовала вполне приличную пиксельную графику на 21"-мониторе, программы на GW-Basic летали с такой скоростью, что всем стало наплевать, что они честно интерпретируются.
4) Следующий случай был совсем смешным. Надо было как-то ускорить программу, созданную с использованием картографического ядра от Top-Plan. После нескольких попыток как-то оптимизировать честное Win-рисование оказался перед необходимостью переводить всю графику на OpenGl (часть графики этой программы уже и так была под нее). Перед этим решил подчистить, на всякий случай, саму картографическую БД. Оказалось, графика была не причем, выкинул избыточную очистку буферов (они заполнялись последовательно) и старт программы вместо минут стал занимать секунды. Для очистки совести отказался и от XML-баз данных (они тоже источник тормозов, особенно библиотеки, которые пытаются работать с XML по правилам реляционных БД).
5) Прочел книжку Кернигана и Пайка "Практика программирования". Там приведен интересный пример оптимизации (работа со строками) и подтверждено мое опасения по поводу "стандартных списков". Оказывается STL жутко тормозит на коротких очередях.
6) Последние годы работал в сфере, где с большими объемами информации надо было быстро проводить сложные преобразования. Вынес следующее. Главный источник торможения - избыточные копирования и переформатирования блоков информации. Вплоть до того, что у ведущего программиста проекта была присказка: "Не пошел тест, свапни исходные или полученные данные". Кроме того, анализ показал, что после разумных преобразований программ ускорять нужно считанное количество типовых операций (не более десятка).
7) Анализируя исходники Linux сразу обнаружил, что оптимизация при компиляции там необходима. Хитрые авторы для удобства связывания и макроподстановки используют такие конструкции, которые будучи откомпилированы буквально вызовут внесение в код большое количество пустых операторов или избыточных переадресаций.
8 ) Т.к. конкретно моя работа состояла в анализе ПО, я выяснил, что главная причина торможения - обычно, бешеная избыточность кода современных кодеров. Причем, заставлять исправлять их огрехи оптимизатор бессмысленно, т.к. количество критических ошибок программистов так же было очень велико. Избыточный код порождал избыточные ошибки. Приходилось заставлять переписывать.
9) Попытка модных программистов перейти от сложных структур управления к взаимодействию большого числа простых процессов/потоков вопроса не решила, т.к. поклонники этого метода забыли, что синхронизация этих процессов вопрос тоже не простой. С ужасом наблюдал за программами, которые сами себя душат избыточным трафиком пустых сообщений.