Воспользовавшись тестом на производительность с форума oberspace, реализованного для разных языков, проверил свой транслятор. Тест представляет собой написанную в лоб пузырьковую сортировку.
Одним из преимуществ использования транслятора Оберона перед непосредственным написанием кода на C/C++ является лёгкая возможность добавления проверок границ массива и использования неинициализированных переменных. Современные компиляторы Си тоже не так просты и позволяют добавлять некоторые проверки (-fsanitize), впрочем, рассматриваемые авторами больше как отладочная возможность. Сравним эти возможности.
| Язык: | С++ vector.at | С++ vector[] | Go | Oberon | Rust |
| Опции компилятора: | clang++ -O3 | -O3 -fsanitize=address | go build | ost | clang -O3 | rustc -O -C lto |
| Время сек.: | 1.41 | 1.08 | 1.84 | 0.54 | 0.52 |
Транслятор Оберона вставляет проверки с помощью стандартного для Си assert, поэтому для их отключения достаточно объявить макрос NDEBUG при компиляции.
| Язык: | С++ vector[] | Oberon | Rust |
| Опции компилятора: | clang++ -O3 | ost | clang -DNDEBUG -O3 | rustc -opt-level=3 -C lto |
| Время сек.: | 0.53 | 0.47 | 0.52 |
Результаты забавные — с проверками границ программа на Обероне оказалась в 2-а раза быстрей С++ и лишь слегка уступила самому быстрому варианту на Rust, и оказалась самой быстрой для сортировки без проверок границ. С учётом того, что здесь Оберон транслируется в Си, то это, по сути, победа Си. С той поправкой, что написание защищённой программы сразу на Си потребует от программиста бо́льших усилий за счёт явного прописывания проверок и неизбежного допущения какого-то количества дополнительных ошибок при этом процессе.
| OS: | GNU/Linux Ubuntu 16.04 |
| CPU: | Intel i3-4160 3.60GHz |
| clang: | 3.5 |
| go: | 1.6.2 |
| rustc: | 1.7.0 |
Камрад, добрый совет. Увеличь время выполнения тестов для приличия, ну хотя бы раз в 20, штале :)
ОтветитьУдалитьЗачем ждать, если увеличение времени не меняет принципиальной картины? Соотношение по времени достаточно стабильное и при увеличении замеров на порядок и так.
УдалитьДело хозяйское. Но, как там на счёт кэшей погреть, планировщику маленько подсказать, что этот процесс надо любить чуть сильнее?))
УдалитьКак я уже писал, картина от этого не менялась особо.
УдалитьЭтот комментарий был удален автором.
ОтветитьУдалитьПостоянно слышу этот аргумент(а ты как мерял, надо jit прогнать и т.п.), это смешно господа, ЯП должен из коробки летать. Пользователю что ли объяснять, что он программу "не прогрел"? ))
ОтветитьУдалить