Почему Linux в разы эффективней FreeBSD, OpenBSD, NetBSD и DragonFlyBSD

Спецы от скуки стали запускать команду yes и перенаправлять вывод в /dev/null. Средняя скорость записи в BSD-системах получилась в районе 150 мегабайт в секунду. Когда тот же фокус был проделан в Linux, то скорость составила 10 гигабайт в секунду. Откуда такой «рост производительности»?

Производительность Linux vs FreeBSD

Дальше еще интереснее. Испытатели написали программу, которая делает то же самое, что делает связка $ yes | pv > /dev/null. А именно, отправляет символ «y» в никуда:

/* yes.c - iteration 1 */
void main() {
    while(puts("y"));
}
$ gcc yes.c -o yes
$ ./yes | pv > /dev/null

Оказалось, что самопальная версия программы yes дает всё те же 150 мегабайт в секунду, причем теперь даже в Linux. Откуда тогда взялись 10 гигабайт в секунду, если только что был опытным путем вычислен теоретический предел в 150 Мб/с? Не вмешались ли в работу алгоритма сверхъестественные силы? Экспериментаторы на всякий случай вызвали специалиста с кадилом и продолжили поиски истины.

Для этого потребовалось лезть в исходники и сравнивать реализации yes в Linux и BSD. Секрет, как многие догадались, в буферизации и внутреннем устройстве операционных систем. Разработчики Linux знают, что весь ввод/вывод заметно медленнее других операций, поэтому кэшируют I/O при каждой возможности. Буферизация вывода и дала десяточку.

Но дальше еще интереснее. Когда была написана спецверсия yes с буферизаций, то ее запустили и в BSD-системах, однако испытатели недосчитались 1,5 гигабайта в секунду. Ну а теперь-то что? Почему Linux уделал даже FreeBSD, которую никто в низкой производительности ранее не подозревал?

Дело в оптимизированности самой операционной системы. Существуют накладные расходы на организацию конвейеров (pipes). В Linux они низкие, а разработчики FreeBSD и прочих бздей об оптимизации, похоже, ничего не слышали. За счет более эффективной работы внутренностей ОС удалось получить лишние 1,5 гигабайт в секунду.

Имеет ли эта история какой-либо практический смысл, ведь отправка «y» в никуда — не самая насущная операция? Да — имеет. Этот простой эксперимент выявил превосходство Linux над FreeBSD в плане производительности (о других BSD-клонах и говорить не приходится). Потеря 1,5 Гб/c для домашнего пользователя не представляется критичной, а вот на уровне корпоративного кластера или в дата-центре такие накладные расходы на пайпы будут иметь реальное выражение в долларах США.

Комментарий человека с кадилом

Я всё же склонен настаивать на своей точке зрения. Я не знаток Linux- и BSD-систем, но даже я знаю, что /dev/null — это черная дыра. А черная дыра вполне может оказаться местом, где физически расположен ад и заигрывание с такими дырами даже на уровне, казалось бы, относительно безвредных компьютеров может быть смертельно опасным. Неудивительно, что с расчетами творится какая-то чертовщина. Я настоятельно рекомендую разработчикам Linux не провоцировать темные силы зла. Уберите из Linux демонов, замените черные дыры на Божественный Свет и тогда поведение операционной системы станет намного более предсказуемым.

Ваша оценка: Нет Средняя оценка: 4 (10 votes)

Поздравляю, ребята, вы померили malloc

#include <stdio.h>
int main(){
 for(int i=0; i<50000000L; i++) {
 printf("yes sir\n");
 }
}

0.7 секунды, причем цифра не сильно зависит от длины строки!

#include <stdio.h>
int main(){
 for(int i=0; i<50000000L; i++) {
 printf("%d\n", i);
 }
}

2.6 секунды

Смекаете? Эти 2.6 секунды выделены на аллокацию очередного числа в памяти при выводе пайпа, а в первом примере этой аллокации может не происходить.

Ваша оценка: Нет Средняя оценка: 4 (3 votes)
Texnoline

Мда, сейчас набегут юные бздуны и закидают всех "панамками"!;)

Ваша оценка: Нет

У BSD демоны в кедах, а у Линукса в ластах. Плавают они может и быстрее, зато склеивают их чаще -_-

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.