The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Сравнение производительности сетевого драйвера в вариантах н..., opennews (?), 12-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


94. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от svsd_valemail (ok), 12-Сен-19, 14:14 
Они не думают что 2-10% это тоже много, если 1 драйвер - это не страшно а теперь представляем ОС состоящую только из подобных драйверов и все с такими "просадками" производительности ... в итоге получим черепаху которая "нормально" будет работать разве что на дорогих компах ...
Ответить | Правка | Наверх | Cообщить модератору

96. "Сравнение производительности сетевого драйвера в вариантах н..."  –4 +/
Сообщение от kiwinix (?), 12-Сен-19, 14:22 
Люблю Раст, но плюсую что просадки производительности 2% для драйвера это многовато..
Ответить | Правка | Наверх | Cообщить модератору

314. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Wilem (?), 15-Сен-19, 19:03 
Все эти исходники могут сильно различаться по степени оптимизированности. Ну и плюс это сравнение не языков, а компиляторов и рантаймов. Которые ещё разных версий бывают. Раст должен работать без оверхеда над си, если где-то проседает значит либо код неоптимальный либо в компиляторе есть что улучшить.
Ответить | Правка | Наверх | Cообщить модератору

98. "Сравнение производительности сетевого драйвера в вариантах н..."  –1 +/
Сообщение от НяшМяш (ok), 12-Сен-19, 14:42 
Нельзя забывать что ОС - это куча других разных вещей. Взять тот же Clear Linux - при тех же самых исходниках умудряется иногда производительность выжимать в несколько раз больше. Если ОС сама по себе не будет давать большого оверхеда, то драйвер медленнее линуксического на 2-10% не будет такой большой проблемой.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

103. "Сравнение производительности сетевого драйвера в вариантах н..."  +1 +/
Сообщение от Аноним84701 (ok), 12-Сен-19, 15:07 
>о драйвер медленнее линуксического на 2-10%
> не будет такой большой проблемой.

Оно не будет проблемой, потому что можно вместо гаданий на опеннетной гуще поглядеть в код и/или объяснения авторов:
https://github.com/ixy-languages/ixy-languages/blob/master/R...
> There are only two major differences between the idiomatic Rust and C implementations:
> Rust enforces bounds checks while the C code contains no bounds checks (arguably idiomatic style for C).
> C does not require a wrapper object for DMA buffers, it stores all necessary metadata directly in front of the packet data the same memory area as the DMA buffer.

или
https://www.net.in.tum.de/fileadmin/bibtex/publications/pape...
> We present user space drivers for the Intel ixgbe 10 Gbit/s network cards
> implemented in Rust, Go, C#, Java, OCaml, Haskell, Swift,
> JavaScript, and Python written from scratch in idiomatic style for the respective languages.
> We quantify costs and benefits of using these languages: High-level languages are

...
>  Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-

Очевидно, что "идиоматический" стиль, особенно для критичных частей, типа дров, можно и не выдерживать.

Ну и вообще, делать выводы из разницы в пару процентов в _таком_ тесте я бы поостерегся.

Ответить | Правка | Наверх | Cообщить модератору

112. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Андрей (??), 12-Сен-19, 16:03 
>  Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-

Т.е. экономические затраты датацентра (на электричество) при переходе на такой вот драйвер вырастут.

Ответить | Правка | Наверх | Cообщить модератору

114. "Сравнение производительности сетевого драйвера в вариантах н..."  +1 +/
Сообщение от Аноним84701 (ok), 12-Сен-19, 16:09 
> >  Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-
> Т.е. экономические затраты датацентра (на электричество) при переходе на такой вот драйвер вырастут.

Проценты лучше смотреть вот эти:
>> But it manages to do so with only 6% (11%) more cycles per packet for batch size 32 (batch size 8).

Ответить | Правка | Наверх | Cообщить модератору

274. "Сравнение производительности сетевого драйвера в вариантах н..."  –1 +/
Сообщение от Онаним (?), 14-Сен-19, 11:01 
То есть целых 10% производительности надо отдать за возможность хипстерков писать на моднявом язычке? С учётом того, что стоимость разработки на C/хрусте выйдет примерно одинаковой, а толковых программистов на первом больше - не, спасибо.
Ответить | Правка | Наверх | Cообщить модератору

286. "Сравнение производительности сетевого драйвера в вариантах н..."  –1 +/
Сообщение от red75prim (?), 14-Сен-19, 19:06 
Когда-то давно хипстеры Керниган и Ричи переписывали UNIX с ассемблера на наколенную поделку, которая позже стала языком C. Наверно тоже сколько-то процентов производительности потеряли. Оптимизатора в компиляторе С тогда особо не было.
Ответить | Правка | Наверх | Cообщить модератору

287. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от red75prim (?), 14-Сен-19, 19:14 
Впрочем, из-за чего там эти 10% в статье особо не разбирались, а предположили, что из-за bounds checking. Но, если что, bounds checking можно и отключить.
Ответить | Правка | Наверх | Cообщить модератору

304. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Онаним (?), 15-Сен-19, 10:46 
> Когда-то давно хипстеры Керниган и Ричи переписывали UNIX с ассемблера на наколенную
> поделку, которая позже стала языком C

Ещё один, не осиливший разницу между транслятором ассемблера и реальным ЯВУ.
У хруста например такой разницы нет, скорее даже хуже стало.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

305. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Онаним (?), 15-Сен-19, 10:47 
> У хруста например такой разницы нет, скорее даже хуже стало.

(разницы с сями, естественно) - просто ещё одна потуга на предмет "альтернативного" яву, на тему "а вдруг выстрелит - тогда личный профит".

Ответить | Правка | Наверх | Cообщить модератору

134. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Анонимemail (134), 12-Сен-19, 18:04 
помнятся мне эти "нормально", там дорогой компа даже не спасает из-за wait for response.
Менеджеры и так софт в говно превратили ради быстрой разработки, и продажи. Теперь за саму ОСь взялись.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

153. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Dee (??), 12-Сен-19, 19:11 
0.98*a + 0.98*b + 0.98*c + 0.98*d = 0.98*(a+b+c+d)
Если каждый компонент просядет на пару процентов, общая скорость тоже лишь на пару процентов должна.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

165. "Сравнение производительности сетевого драйвера в вариантах н..."  –1 +/
Сообщение от anonymous (??), 12-Сен-19, 20:05 
Скорее: 0.98 * 0.98 * 0.98 * 0.98 ~= 0.92 (если эти модули используются последовательно)
Ответить | Правка | Наверх | Cообщить модератору

208. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от funny.falcon (?), 13-Сен-19, 07:05 
> Скорее: 0.98 * 0.98 * 0.98 * 0.98 ~= 0.92 (если эти
> модули используются последовательно)

Ещё правильнее: (1 + 1 + 1 + 1)/(1/0.98 + 1/0.98 + 1/0.98 + 1/0.98) = 4/(4/0.98) = 0.98

Ответить | Правка | Наверх | Cообщить модератору

238. "Сравнение производительности сетевого драйвера в вариантах н..."  +2 +/
Сообщение от Аноним (223), 13-Сен-19, 13:53 
Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера на C стали переписывать. Причем тогда у них были более весомые аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые С-компиляторы наверняка генерировали не самый оптимальный код.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

290. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от svsd_valemail (ok), 14-Сен-19, 20:20 
> Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
> на C стали переписывать. Причем тогда у них были более весомые
> аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые
> С-компиляторы наверняка генерировали не самый оптимальный код.

Вы исходный код ядра давно видели ? Все более менее значимые участки на ассемблерных вставках..

Ответить | Правка | Наверх | Cообщить модератору

306. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Онаним (?), 15-Сен-19, 10:48 
> Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
> на C стали переписывать. Причем тогда у них были более весомые

Осиль уже разницу между транслятором мнемоник машкода и таки ЯВУ, потом бредь.

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

257. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от мяя (?), 13-Сен-19, 19:52 
И как часто эти драйвера вызываются? У тебя из основного:
Драйвер контроллера (накопители)
Видео драйвер
Аудио драйвер
Сетевой драйвер
Итого ~10% просадок неравномерно по времени распределённых. Остальные драйвера вызываются очень редко если нет какой-то специализации.
Вы на браузере написанном нам c++ и сайтиках тратите гораздо больше тактов чем на этих драйверах. Когда та же лиса или хром в фоне ощутимо жрут ЦП на всяком мусоре.
Обычно производительность во многом зависит от архитектуры драйвера, даже если там числодробилки надо их с умом использовать и бывает так что умный код на высокоуровневом языке оказывается производительнее кода байтоёба, банально байтоёб забил на асинхронность и синхронно долбит вызовы просирая кучу времени на эту синхронность. Так что сравнивая языки надо учитывать ещё и лёгкость написания умного кода. Когда язык требует большой осторожности то неминуемо он сожрёт время на это, когда как это время можно было потратить на более продуманный код.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

275. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Онаним (?), 14-Сен-19, 11:02 
Для каждой машины, которая отдаёт тебе статический например видеоконтентик, который ты смотришь в том самом браузере, этот самый драйвер чуть ли не основа основ.
Ответить | Правка | Наверх | Cообщить модератору

289. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от svsd_valemail (ok), 14-Сен-19, 20:18 
>[оверквотинг удален]
> чем на этих драйверах. Когда та же лиса или хром в
> фоне ощутимо жрут ЦП на всяком мусоре.
> Обычно производительность во многом зависит от архитектуры драйвера, даже если там числодробилки
> надо их с умом использовать и бывает так что умный код
> на высокоуровневом языке оказывается производительнее кода байтоёба, банально байтоёб
> забил на асинхронность и синхронно долбит вызовы просирая кучу времени на
> эту синхронность. Так что сравнивая языки надо учитывать ещё и лёгкость
> написания умного кода. Когда язык требует большой осторожности то неминуемо он
> сожрёт время на это, когда как это время можно было потратить
> на более продуманный код.

И так начнём, представьте что Вы используете видео драйвер который написан на этом деле со своими просадками в производительности и отзывчивости, используется он как ни странно 99% рабочего времени пользователя... Конечно если Вы не юзаете сервер без видео вывода. Получаем что производительность и отзывчивость системы в целом да и в мультимедиа упадёт не на 10%. Так как системе и приложению ещё нужно использовать винт, сеть, звук, устройства ввода, каждый драйвер со случайной просадкой производительности и отзывчивости... Будете играть и со скоростью эмуляторов плоек и задержками на каждом вводе ...

А вот про правильный код, тут вопрос открыт, у всех он свой... у проприетарщиков работает на костылях - правильный код.

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру