The OpenNET Project / Index page

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



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

Оглавление

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

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


35. "Сравнение производительности сетевого драйвера в вариантах н..."  +2 +/
Сообщение от leap42 (ok), 12-Сен-19, 12:07 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

M$ подкупила Debian через своих наймитов RH (IBM)? А может просто шапочка из фольги обзор закрывает?)

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

47. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Аноним (28), 12-Сен-19, 12:21 
Тест-то сами смотрели? Где преимущество в скорости у C#?

Идут один в один, за исключением одного теста, что тоже не факт что сделано оптимально.
По моему ясно, что технологически у них схожая реализация соответстввенно и производительность будет сопоставима.

Также производительность зависит от сборщика мусора. Под JVM их есть несколько штук.

Поэтому не следует очаровываться насчет C#. По сравнению с JVM он обладает только известными недостатками. Кто его использует сам на себя накладывает ограничения.

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

67. "Сравнение производительности сетевого драйвера в вариантах н..."  +1 +/
Сообщение от Аноним (67), 12-Сен-19, 12:59 
По сравнению с JVM он обладает ещё и известными (не вам) преимуществами. Например, большим количеством низкоуровневых обёрток. Поэтому в драйвере на C# 39 строк кода на С, а в драйвере на жавке куда больше.
Ответить | Правка | Наверх | Cообщить модератору

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

145. "Сравнение производительности сетевого драйвера в вариантах н..."  –1 +/
Сообщение от Аноним (21), 12-Сен-19, 18:37 
При необходимости можно и на ассемблере написать. Здесь же  рассматривается другой случай, а именно тот, которым является заголовок статьи. Читаем внимательно и без "необходимости".
Ответить | Правка | Наверх | Cообщить модератору

159. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Аноним (28), 12-Сен-19, 19:39 
Без необходимости можно написать на чем-то другом. Осваивать бесперспективный язык ради написания драйвера, как-то глупо что ли.
Ответить | Правка | Наверх | Cообщить модератору

200. "Сравнение производительности сетевого драйвера в вариантах н..."  +3 +/
Сообщение от Аноним (196), 12-Сен-19, 23:45 
> преимуществами. Например, большим количеством низкоуровневых обёрток.

А ещё дженериками без type erasure, value-типами, перегрузкой операторов (не всем нравится, но лично я предпочитаю читать/писать `a + b * c` вместо чего-то вроде `a.add(b.mul(c))`, и, чем сложнее формула, тем трэшовее вариант с "обычными" методами), паттерн матчингом, именованными и опциональными параметрами методов, async-await и другими ништяками, появление которых в Java находится, в лучшем случае, на стадии планов и обсуждений. Дотнет можно ругать за некоторую завязанность на MS вообще и винду в частности, по части языковых фич он давно обошёл жабу.

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

167. "Сравнение производительности сетевого драйвера в вариантах н..."  +/
Сообщение от Аноним (167), 12-Сен-19, 20:08 
Нет, в этих бенчах отражено ожидаемое поведение. Если запускать программу очень много раз на 5 секунд и каждый раз очищать файловый кеш между запусками.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

219. "Сравнение производительности сетевого драйвера в вариантах н..."  +6 +/
Сообщение от Аноним (265), 13-Сен-19, 09:24 
> M$ подкупила Debian через своих наймитов RH (IBM)?

Открываем тест "regex-redux" с самой большой разницей по времени выполнения и видим, что реализация на C# для регулярных выражений вместо стандартной библиотеки .NET использует PCRE с JIT-ом и не конвертирует прочитанные из файла байты в строку.

Открываем "k-nucleotide" и видим, что реализация на C# входные данные читает и парсит в байтовых массивах, а реализация на Java через InputStreamReader конвертирует прочитанные байты в строку, а потом эту строку конвертирует обратно в байты.

Открываем "pidigits" и видим, что реализация на C# выводит цифры сразу в stdout, а *однопоточная* реализация на Java теребонькает *потокобезопасный* (бессмысленный оверхед) StringBuffer, создавая новый его экземпляр (бессмысленная нагрузка на GC) на каждые 10 цифр.

В остальных тестах разница составляет доли секунды, поэтому можно ограничиться "mandelbrot", где реализация на C# использует пул потоков и собирает результаты в одномерный массив, который сразу весь и выводит, а в реализации на Java тупо массив потоков, пишушщих в несколько массивов с "синхронизацией" через атомарную переменную.

Насчёт качества реализаций пусть каждый решает сам, но различия, не обусловленные ограничениями (например, отсутствием требуемой функциональности в стандартной библиотеке) той или иной платформы, сводят в ноль репрезентативность полученных результатов.

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

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

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




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

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