Многое можно было сделать лучше, например:

• Исключить лишние операций при вычислении условий
• Использовать два индексных регистра вместо одного
• Расширить набор используемых команд процессора
• Использовать многопроходный ассемблер

Это не оптимизация, а всего лишь небольшие усовершенствования простого генератора кода. Нельзя сказать, что все это дает очень много, но кое-что дает.

Ниже приведены результаты некоторых тестов, включающих компиляцию программы, сжатие данных методом LZSS (без использования индекса или хеш-таблицы) и расчет хода в игре ним (перебором). Тесты не претендуют на полноту, но они дают некоторое представление о качестве компилятора и позволили его улучшить. Кроме того, они были выполнены почти на всех процессорах, когда-либо использовавшихся в IBM PC и могут быть интересны уже этим.

Почти во всех тестах время измерялось по таймеру машины, соответственно, погрешность измерения не превосходит 0.11 сек, как правило это меньше случайной погрешности. Каких-либо мер для устранения последней не предпринималось.

Использовались следующие компиляторы:

Context.pas - первая версии context'а, написанная осенью 1994 года. Так как его входной язык очень ограничен, компилятор участвует лишь в одном тесте (и демонстрирует худший результат).

Ранние версии Turbo Pascal взяты в музее фирмы Borland, который находится на сайте community.borland.com. Наверное, наибольший интерес представляет Turbo Pascal 1.0. Третью версию я видел в 1989 году, а первую увидел лишь недавно. Это совсем маленькая программа turbo.com, включающая редактор текста, собственно компилятор и небольшую библиотеку функций. Все это как-то умещается в файле размером 33280 байт и может работать при наличии менее 64K памяти.

Тесты выполнялись на различных ПЭВМ с процессорами от 286 до Pentium 4 и Athlon XP. На этих машинах были установлены разные ОС, поэтому условия выполнения тестов не совсем одинаковы. На 286/12 установлена MS-DOS 3.30 (без smartdrv), на 386/40 - MS-DOS 6.22 (также без smartdrv), на остальных машинах - одна из систем Windows - Windows 95, Windows 98, Windows NT 4.0, Windows 2000 или Windows XP. Согласно SysInfo (Norton Utilities 8) относительное быстродействие процессора 286/12 - 9.2 (цифра странная, эта машина примерно в шесть раз быстрее IBM PC, но за неимением последней проверить это нельзя). Некоторые результаты трудно объяснить, но большая часть результатов соответствует ожиданиям.

Компиляция:

Для этого теста использовалась промежуточная версия компилятора context.tmp (99832 байта, 4628 строк). Это немного уменьшеный context.opt, сделанный только из-за имевшей место ошибки в ассемблере, который выдавал лишние префиксы замены сегмента, из-за этого код самого context.opt не умещался в 64 килобайта.

Длины исполняемых модулей context.ctx/context.cpp, байт:

При компиляции программы context.cpp была задана оптимизация по скорости. При оптимизации по размеру кода получается файл размером 42048 байт и скорость его работы не ухудшается.

Время компиляции программы context.tmp, сек:

Сравнение с Borland C++ не вполне корректно, т.к. компилятор context.cpp не эквивалентен context.tmp. Вообще, тест неудачен - в нем очень большую роль играет вывод на экран, особенно это заметно на Am486DX/66 с ISA VGA. Но с другой стороны - есть некая программа и мы не вдаваясь в особенности реализации определяем скорость ее работы на разных машинах. Результаты, отмеченные звездочкой немного занижены из-за упомянутой ошибки в ассемблере. Результат K6/300 совершенно непонятен.

Время компиляции просто огромно - для сравнения Borland Pascal 7.0 на 286/12 компилирует программу context.pas (~2400 строк текста) за пять с небольшим секунд. Конечно, на современных машинах это не заметно, но на 286 и, тем более, 8088 скорость компилятора сложно было игнорировать. На той же 286/12 Borland C++ 2.0 тратил на полную компиляцию прототипа edit64k (всего 400 строк) примерно 45 секунд.

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

• замену strpos(@ALPHA,Read())!=0 сравнениями ('A'<=Ch & Ch<='Z')
• снижение частоты вывода на экран номеров строк (вывод каждой сотой строки)
• более аккуратную реализацию функции записи результата (Code)

Дальнейшее повышение быстродействия может быть достигнуто за счет реализации быстрого поиска в таблицах компилятора и прямой генерации машиного кода. Последнее стоило сделать сразу, но тогда я решил, что генерация ассемблерного листинга проще. Это не совсем верно, но что сделано, то сделано...

Для следующего теста использовался построенный на иснове context.min прямой генератор кода. Длины исполняемых модулей, байт:

Время компиляции context.min (63838 байт, 3549 строк) и context.pas (<=65001 байт, <=2395 строк - эти цифры немного различны для разных версий Turbo Pascal), сек:

В первой колонке (CMP) для сравнения приведено время работы компилятора CTX из предыдущего теста. Время выполнения тестов TP1 и TP3 измерялось c меньшей точностью, чем указано в таблице, лишний ноль приписан только для выравнивания чисел. В остальных случаях погрешность измерения времени не боле 0.01 секунды (тест выполнялся десять раз подряд, измерялось общее время). Скорость Turbo Pascal не достигнута, но результат сопоставим и разницу уже можно списать на недостаточную эффективность самого компилятора. К тому же есть основания полагать, что все версии Turbo Pascal написаны на ассемблере.

Компилятор context.pas не эквивалентен context.min (последний чуть меньше, но содержит на треть больше лексем), специально писать большие одинаковые программы на разных языках нет возможности...

Компиляция context.202 для Windows с помощью context.201 (DOS) и context.202 (Win32), сек:

Этот тест также более корректный, поскольку context.201 выполняет только последовательное чтение и последовательную запись файла. На верхнем уровне погрешность измерения 0.01 секунды слишком велика, выполнение теста сто раз подряд дало следующие результаты:

Сжатие файла:

Для этого теста программа arcdemo.ctx была переведена на Pascal и С++. Длины исполняемых модулей arcdemo.ctx/arcdemo.pas/arcdemo.cpp следующие, байт:

Программы, созданные с помощью компиляторов Turbo Pascal и C++ не содержат функции раскрытия архива, полные программы были бы несколько больше. Длины исполняемых модулей, созданных ранними версиями Turbo Pascal не приводятся, т.к. они включают полную библиотеку функций.

Время сжатия файла context.tmp (99832 байт) с помощью программы arcdemo, сек:

Трудно объяснить результаты, показанные Turbo Pascal - созданный им код плохо подходит для новых процессоров (Context'а это тоже касается). Этот тест также имеет недостаток - в цикле поиска совпадений есть лишние действия.

Расчет первого хода в игре ним:

В первой колонке (MIX) приведено время работы программы, скомпилированой посредством context 0.5.

Тот же тест, но использовались компиляторы Context 1.4, Context 2.04 (в версии 2.02 нет поддержки целых со знаком), Context 2.07 и MS Visual C++ 4.2 (странно, но созданный им код оказался лучше, чем код MSVC 6.0, особенно это заметно на K6):

Видно, что 32-х разрядный код выполняется заметно быстрее 16-и разрядного, причем разница может быть значительна. По-видимому, лишь результат Сontext 1.4 можно прямо сопоставлять с результатом 16-и разрядного теста (Context 1.3/OPT), поскольку в них используются сходные методы генерации кода.

Подведем итоги:

Тесты не полны, поэтому сделанные из них выводы могут быть не вполне справедливы, но все же:

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

Для Pentium 4 очень важно выравнивание кода, более важно чем для предшествующих процессоров.

На основе полученных результатов был построен график зависимости быстродействия процессоров от времени. Использовались результаты из последних колонок (Borland C++ 3.1). Результаты привязаны к датам выпуска микропроцессоров а не машин, относительное быстродействие 286/12 принято равным шести, для получения быстродействия первого процессора каждого семейства (8086, 80286 и т.д.) результаты экстраполировались (исключение - Athlon, его быстродействие приведено к 1000 МГц):

За двадцать лет рост примерно в тысячу раз (1.4 раза в год), реальный рост несколько больше, т.к. 32-х разрядный код выполняеся бысрее 16-разрядного. Но полное представление о росте быстродействия может дать только 16-разрядный код, поскольку на старых машинах может быть выполнен только он. Выполнить тесты на 8086 к сожалению пока нет возможности.

P.S.

Это может показаться удивительным, но во время выполнения тестов были обнаружены неожиданные ошибки в MS-DOS и Turbo Pascal.

При запуске следующего командного файла

в MS-DOS 3.30 два раза выполняется программа n0.com (и перестановка строк ничего не меняет).

Turbo Pascal 1.0 неправильно компилирует программу Pascal-S (маленький компилятор подмножества Pascal и интерпретатор P-кода, первоначально использовался вместо context.pas). Ошибка связана с обработкой массивов строк:

• В загодовке цикла while может отсутствовать do
• Write(UpCase(97)) компилируется и выполняется

Вопрос лишь в том, ошибки это или так было задумано? Да, видно программ без ошибок не бывает...