Прочитал я статью про /bin/true и кучу ее версий. Потом подумал посмотреть, что да как в моем Debian:
root@server:~# /bin/true --version
true (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <http://gnu.org/licenses/gpl.html>
Это свободное ПО: вы можете продавать и распространять его.
Нет НИКАКИХ ГАРАНТИЙ до степени, разрешённой законом.
Автор программы — Jim Meyering.
Суть даже не в том, на кой черт столько версий. Суть в том, что если программу переписывали кучу раз и она, ничего не делая, весит 20 (!) килобайт, то что-то здесь не так.
В общем, я переписал (какое громкое слово) ее на nasm и собрал. Объем уменьшился в ~40 раз. А потом - самое веселое, тестирование производительности.
Для этого использовался следующий скрипт:
#!/bin/bash
i=0
date
until [ $i -eq 220000 ]
do
/bin/true
i=$[$i+1]
done
date
После этого в скрипте /bin/true меняется на ./true и тест повторяется.
Тест проводился на Debian Stable x64, Xeon E3-1235 Sandy Brige, 16gb RAM DDR3 1333.
Результаты:
/bin/true - 61 sec
./true - 32 sec
C /bin/false все примерно так же. Еще сравнивал с true из busybox на нетбуке с slitaz. Ее nasm-версия обгоняет не в 2, а примерно, в полтора раза.
Я даже не знаю, что мне спросить. Зачем в ЭТИХ программах Си? Почему они такие медленные? Почему даже busybox, который призван работать на встраиваемых и маломощных железяках не использовал такой подход?
Я понимаю, что vi на nasm или gas переписать - мрак и ужас. Но cat, mount, ls, true, false и еще многие - вполне возможно. И даже я бы мог это сделать, если бы захотел. Другой вопрос в том, что системное программирование в Linux прибито гвоздями к сишечке. Неужели от нее не откажутся даже ради прироста производительности?
Даже двойного?
