Группа исследователей из немецких университетов опубликовала результаты эксперимента, в ходе которого на разных языках программирования было разработано 10 вариантов типового драйвера для 10-гигабитных сетевых карт Intel Ixgbe (X5xx). Драйвер работает в пространстве пользователя и реализован на языкаъ C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript и Python. При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка. По функциональности все варианты идентичны и состоят примерно из 1000 строк кода. Наработки проекта распространяются под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51475
о, ну так в конечном счёте всё будет переписано на C# ? (и раст тоже)
как там был один из доводов (в прошлой статье про написание драйверов в Linux на Rust): "...для команд у которых нет достотачных ресурсов для тестирования кода..." или как-то тактак от C# эффективные менеджеры вообще в экстазе будут
> для команд у которых нет достотачных ресурсовПри наличии рынка труда проблема достаточных ресурсов не существует.
А деньги на найм этих людей для тебя уже не ресурс?
То есть переводя на человеческий: при наличии спроса, предложения всегда будут?
Или даже проще: если все хотят бентли, то конечно все их получат. Да?
</sarcasm>
Да, но игрушечные
Какого именно рынка труда, уточни.Есть очень много гнилых шараг с вантузомакосью и низкими зарплатами, например.
Конечно хорошему специалисту захочется работать там где лучше, а не в первой попавшейся.
> (код выполнялся с использованием CPython 3.7 и не был совместим с PyPy, но отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз).это как там получается 0 на 10 надо умножить?
*точнее не драйверов, а модулей ядра*
Рад, что СИ - лидер. Нужность раста по-прежнему остаётся крайне туманной.
это то да, но ты на опенете такое громко не кричи, а то и тебя перепишут на расте
Ваша фраза, сэр, заставила вспомнить сериал, который я смотрел в глубоком детстве еще на черно-белом ламповом телевизоре, он назывался "капитан пауэр и солдаты будущего". Там людей в прямом смысле в цифровой код переводили. Вот и сейчас с развитием всякого рода нейроных сетей нашу личность можно воплоить в цифре (очень-очень приблизительно), и да, ради эффективности можно воплотить и расте, но лучше на СИ :)
Почему же, я вот этот топик прочитал и процентов 15 отписавшихся спокойно могу, как кодеров, одной цифрой оцифровать :) без потери их качеств и вы эту цифру знаете. Кстати, спасибо за название, одно время пытался вспомнить как же он назывался.... По 2*2 вроде шел когда-то, пойду поищу посмотреть..
Да, да, давайте лучше продолжать писать дырявые программы из-за стек оверфлоу, буфер овверан и так далее, да и еще вместе мемори ликами... А потом еще команды нанимать чтобы такой код вычистить.
Если писать сейчас начинать - то только на Rust, этот тест тому доказательство.Вы с С возитесь как те луддиты в конце 19 века, бросьте труп, надо уже понимать что времена те прошли.
> Если писать сейчас начинать - то только на RustЧто, когда мозилловцы наиграются с растом, переписывать на что-то другое?
>> Если писать сейчас начинать - то только на Rust
> Что, когда мозилловцы наиграются с растом, переписывать на что-то другое?там что-то не так с лицензией компилятора или патентами?
Думаю, речь про: c мозгами у фанатов Rust.
> Вы с С возитесь как те луддиты в конце 19 века, бросьте
> труп, надо уже понимать что времена те прошли.А что, сделать СИ удобным и безопасным нельзя ?
Может просто написать rust.h и делать #include <rust.h> и в СИ все будет так же хорошо, удобно и надежно как в rust но без rust ?
то фактически все ядра известных ОС (не свитяа Redox, конечно же гг) - один болшой memleak ? мда, что называется, "этому миру нужен супергерой". вроде такого смузи-ыксперта вроде тебя
Метлу в руки и гастарбайтерам помогать, так как походу ни в программировании ни в уборке территорий у тебя эффективность низкая.
> Нужность раста по-прежнему остаётся крайне туманной.О, свидетели сегфолта подъехали
так и вижу Rаспятие на крыше их общины
С# принудительно за гранты продвигаемый язык. В техническом плане нет никакого смысла его использовать.
Сначала похороните Java и всякое бейсико-паскалевское, по сравнению с ними даже C# великолепен
Это цитата из рекламного буклетика от MS? Очень похоже.
Нет. Мы студенты и это цитата из спец гайда.
Это понятно. Далеко не всякий студент способен на самостоятельное мышление.
что конкретно не так с C#? религиозные штуки? с эстетической/технической точки зрения он вполне ок.
С технической и экономической точки зрения. Когда ты создаешь решения на продуктах с открытым исходном кодом. Плюс переносимость конечно и мобильные девайсы. Сегодня госы, банки и крупный бизнес топит за такие решения, а они не строятся на продуктах от MS.
вообще-то с точностью до наоборот, крупный заказчик готов платить за проприеритарщину. говорю так, потому как работал с госами и банками.
> вообще-то с точностью до наоборот, крупный заказчик готов платить за проприеритарщину.
> говорю так, потому как работал с госами и банками.а потом этому заказчику мучительно больно от проприетари, ибо подрядчика к этой проприетари - один, и гонит вал фуйни, срывает сроки, выставляет огромные ценники за мелкие доработки
опыт показывает что брать лучше открытое, даже если к нему студента цепями приковать - часто оказывается качественнее чем проприетарь с авторским суппортом(а тендеры это полный мрак)
> на продуктах с открытым исходном кодом..net core открыт, я ж недавно с гитхаба кидал исходник ГЦ сюда
> Плюс переносимость и мобильные девайсы.
Xamarin native
ты не поверишь, но даже разработчики Unity и Unreal Engine 4 (в котором система сборки подвязана на Mono) с тобой категорически не согласятся. не считая кучи Xamarino-водов и dotNET-товодов
Там определенно что-то не так с думалкой на основании того что в его умозаключении нет логики, как у некоторых отметившихся , с шарпом все в порядке, язык хороший.
> С# принудительно за гранты продвигаемый язык. В техническом плане нет никакого смысла
> его использовать.Пока жабья IDE запускается, кодер на Сисярпе напишет, отладит и запустит в продакшын 3,5 программы.
C# на порядок лучше Java как язык, он даёт очень много инструментов для оптимизации. Поэтому и быстрее. Смиритесь. Иногда MS делает хорошие продукты.
Понимаете, ваше знание Шарпа и незнание Явы не делает первый лучше второй. Ява и Шарп, в общем-то, одинаково плохие языки. Причём, Ява раньше была лучше. А после 8-ки стала такой же плохой, как и Шарп.
Я вообще C/C++-разработчик, но имел возможность попрограммировать и на C#, и на Java.C# — это учли ошибки Java (так как была возможность изучить её опыт), поработали над оптимизацией (те же дженерики в Java нормальные так и не завезли за столько лет), дали богатый набор инструментов для программистов, которые понимают разницу между стеком и кучей (например, stackalloc позволяет память на стеке выделять). В C# без смены языка в unsafe-блоках можно даже с C-подобными указателями работать, со всеми их плюсами в производительности и минусами в возможности случайно отстрелить себе конечности. Но если в коде вдруг есть какой-то очень чувствительный к производительности фрагмент — всегда есть возможность оптимизировать его, оставаясь в рамках C#, а не переписывая код на C/C++ и вызывая его из основной программы. Хотя, смешивать C/C++ и C# в одной программе тоже очень удобно, если нужно — MS тут тоже постаралась на славу, добавив расширения в C++ для прозрачной работы с объектами из мира .NET.
А вообще, больше всего в Java меня раздражало банальное отсутствие нормальных signed/unsigned интов на выбор, это же кошмар, они своего среднего разработчика совсем за идиота что-ли держат, который не сможет разобраться с знаковыми и беззнаковыми интами? =)
>больше всего в Java меня раздражало банальное отсутствие нормальных signed/unsigned интовТак хорошо начал и так жидко слился. Можно сделать вывод, что c# ты вроде знаешь, не писал бы про java совсем, был бы неплохой пост.
По ссылкам не ходил и не пойду, предположим данные сферические драйверы написаны почти полностью в unsafe, но ладно, флаг в руки. Ты если в ынтырпрайзе начнёшь такое повторять, тебя на британский флажок порвут. Нормальный архитектор просто железо потолще возмёт, а не unsafe будет лепить.
Пишу на дотнете уже черти знает сколько времени. Ни разу не доходил до небезопасного кода.
NullReferenceException, забытые подписки делегатов, арифметическое переполнение, двойной Dispose, дедлоки, гонки и прочие мелочи постреливают периодически.Но боже, как я рад, что это не неопределённое поведение в повреждённой памяти. Кто все эти люди, которые могут позволить себе писать на c++ - я не представляю.
> Но боже, как я рад, что это не неопределённое поведение в повреждённой памяти.valgrind в помощь.
До него было тяжеловато, да.
> C# на порядок лучше Java как язык, он даёт очень много инструментов
> для оптимизации. Поэтому и быстрее. Смиритесь. Иногда MS делает хорошие продукты.это что за инструменты оптимизации такие волшебные? можно компилятору/jit-у что-то подсказать?
Например, value-типы, unsafe с указателями и другой низкоуровщиной, P/Invoke для вызова функций в нативных библиотеках без промежуточных обёрток а-ля JNI.
Эксперты Opennet наверно опечалены, что паскаля нет 😃
Bash.
вместо него петон
Кому то и Perl, а кому то и .BAT,
а остальным 99.9% - вообще ничего перечисленное ненужно :)А, тут я обширно чуть коснулся скорсоти Rust
http://www.opennet.ru/opennews/art.shtml?num=51837
(и даже этого теста - "очередного Rust-бенчмарка..." как я его именую)
Да не-е-ет. Дельфи же. Паскаль - это то, от чего их универские преподы пёрлись.
Ну так он и создавался как язык для обучения программированию
Создавался-создавался, да не высоздался. Есть Python для обучения
Обучение программированию, а не мастурбации.
Плюсов тоже нет...
да и кроме C одни минусы...
К сожалению нет реализации на ассемблере
Для какого именно процессора вас интересует ассемблер?
из новости CPU Xeon E3-1230 v2 3.3 GHz
>Для какого именно процессора вас интересует ассемблер?Решил блеснуть эрудицией? Тогда тебе должно быть извесно, что проц выбирается под задачу. В статье у парней была задача СРАВНИТЬ производительность программ. Соответственно главное не то, на каком, а то, чтоб на нем запустились все написанные варианты.
P.S Ну и удачи вам конечно в добывании железа в которое можно вставить сетевую карту описанную в статье, с архитектурой отличной от x86 или AMD64
А в ARM-машинах разве нет PCI-express?
Я не сказал, что нет, но добыть такое железо - интересный квест :)
А запускать тесты в эмуляторе - не будут показательны в плане сравнения
==> К сожалению нет реализации на ассемблере
Вас бы устроил кривооптмизирвоанный или вообще антиптимизирвоанный вариант для пиара Rust?
Ну так и не просите.
Куда больше прикалывает, что кого-то от паскаля столь припекает, что над ним продолжают глумиться лет двадцать спустя, как утихли холивары про него.
> от паскаля столь припекает, что над ним продолжают глумиться лет двадцать спустя, как утихли холивары про него.ну да, ну да... https://www.opennet.ru/openforum/vsluhforumID3/118392.html#16
Go есть.
Какая-то ангажированная муть.
C# не может быть настолько быстрее Java, Swift, OCaml, по той простой причине, что он не быстрее.
В неокрепших умах, наверное, C# все же не быстрее Java и пр.
Не быстрее. Смысл его использования вообще стремится к нулю. Только постоянно вливаемое бабло в его пиар создает видимость его востребованности.
Ты сейчас полностью описал историю приобретения популярности у Java
Java не нуждается в популяризации, она прочно удерживает определенные ниши. Это ее недокопию пытаются везде втюхивать, ибо за так нафиг никому не нужна.
Лол. А как по твоему это безобразие получило популярность в "определённых нишах"? Долго пиарили, втюхивали всем подряд и ездили по ушам, всё по вышеуказанной методике. Чуда не случилось
Кому что впаривали? Бизнес посчитал деньги и принял на вооружение.
По сути тоже самое и с C#, только он огорожен MS продуктами за которые ты будешь платить в довесок.Чуда не случилось у MS, которая скопировала технологию и вынуждена по сей день ее ногой пропихивать. У жавы все прекрасно - энтерпрайз(веб, сервисы) + андройд.
На рынке все распределено. Были PHP, Java. Пришли в этот сегмент нода, руби, питон, го. Все они ввиду своих особенностей освоили часть рынка, а C# это огороженный клон Java без внятного обоснования для его применения.
Все что делает MS для серверного сегмента можно спокойно заменить на более качественные решения, зачастую бесплатные и с открытым исходным кодом. Сишарп разраб обязательно потянет за собой винду и т.д, как и свифт разраб - макось.
Например, госы и банки сегодня отдают приоритет серверным решениям на основе продуктов с открытым исходным кодом. Винда везде выпиливается на корню.
> Сишарп разраб обязательно потянет за собой винду и т.д, как и свифт разраб - макось.rider одинакого запускается как на linux, так и на macos.
исполняемая среда есть mono и .netcore, + контейнеры если так пожелаете. Чего вам еще нужно?
>> Сишарп разраб обязательно потянет за собой винду и т.д, как и свифт разраб - макось.
> rider одинакого запускается как на linux, так и на macos.
> исполняемая среда есть mono и .netcore, + контейнеры если так пожелаете. Чего
> вам еще нужно?сколько лет этому "одинаково"?
вот прям щас - возможно
Бизнес развесил уши и в 2002-2003 особо деффективные манагеры, в основном банков, радостно глотали "работает на миллиардах устройств", хотя тех устройств на тот момент и было то винда, да siemens m55. С тех пор решения этих дефективных манагеров либо приходится болезненно поддерживать в хоть каком-то состоянии, либо переписывать на руби, пайтон, asp.net. Go это всё-таки меньше про веб, больше про отдельный инструмент сегодня, хотя он конечно отлично набирает обороты и будет успешнее жабы.Андроидовцы уже не раз пожалели что взяли за основу жабу. Особенно после того как окакл половину купленного у санок похоронил, а за вторую начал кидать необоснованные претензии. Т.е. это тоже была большая ошибка какого-то манагера.
PHP в приличных конторах выпиливается, особенно если есть реальный бэкенд, остаётся максимум лэндинг на отдельном хосте на котором манагеры играются в ребрендинг, редезигн и СЕО, благо для того же WP тем навалом, да и разработчики считай дармовые, готовы работать почти за еду (в соответствии с квалификацией).
Всё что сделано на жабе можно спокойно заменить на более качественные открытые решения. Шарп давно есть и в никсах, и на мобилках, но основной вектор их развития - веб, там вообще до шарабана какая у тебя ОС. И да, он уже достаточно давно абсолютно открытый и любой адекватный пользователь может в него накоммитать чего-нибудь полезного.
> Лол. А как по твоему это безобразие получило популярность в "определённых нишах"?
> Долго пиарили, втюхивали всем подряд и ездили по ушам, всё по
> вышеуказанной методике.кросплатформенность, неплохой сам язык, легко учить, легко писать, при этом достаточно быстрый, дофига всяких нужных энтерпрайзу либ, отличная IDE (у c# была сильно хуже)
я не видел особой рекламы и втюхивания, выбор был java/c# и как только слышали "высоконагруженный отказоустойчивый сервер на винде" - выбирали жаву и невинду
Ты походу еще не родился в то время когда JAVA появилась. И не в курсе что она практически первой и единственной виртуальной машиной с переносимым исходным кодом и работавшей практически везде где работала виртуальная машина что и нужно было бизнесу.
Популярность Java приобрело как решение удешевляющее разработку ПО. Единственное, на начальном этапе у нее была очень унылая производительность.
на начальном этапе... а на следующем этапе осталась такой же
просто железо доросло до ей потребностейпростите, но динамическая природа примитивных типов и полное остуствие статики - это за гранью добра и зла
JIT появился не сразу. Так же на протяжении всего времени вносились оптимизации.По второму пункту - да, это вносит некоторый оверхед, но не критично.
> динамическая природа примитивных типов и полное остуствие статикиЧто под этим подразумевается?
Под этим подразумвается, что https://openjdk.java.net/projects/valhalla/ всё ещё в разработке, а без этого всё, кроме примитивных типов, выделяется в куче, а не на стеке.
И каким образом аллокации в куче относятся к "динамическая природа примитивных типов и полное остуствие статики"?
> на начальном этапе у нее была очень унылая производительность.И этот "начальный этап" продолжается и прогрессирует.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...M$ подкупила Debian через своих наймитов RH (IBM)? А может просто шапочка из фольги обзор закрывает?)
Тест-то сами смотрели? Где преимущество в скорости у C#?Идут один в один, за исключением одного теста, что тоже не факт что сделано оптимально.
По моему ясно, что технологически у них схожая реализация соответстввенно и производительность будет сопоставима.Также производительность зависит от сборщика мусора. Под JVM их есть несколько штук.
Поэтому не следует очаровываться насчет C#. По сравнению с JVM он обладает только известными недостатками. Кто его использует сам на себя накладывает ограничения.
По сравнению с JVM он обладает ещё и известными (не вам) преимуществами. Например, большим количеством низкоуровневых обёрток. Поэтому в драйвере на C# 39 строк кода на С, а в драйвере на жавке куда больше.
Это частный случай, не меняющий общего тренда. При необходимости можно скомпилять нативно либу и дергать, что собственно и разумней всего сделать если вы хотите высокую производительность без оговорок.
При необходимости можно и на ассемблере написать. Здесь же рассматривается другой случай, а именно тот, которым является заголовок статьи. Читаем внимательно и без "необходимости".
Без необходимости можно написать на чем-то другом. Осваивать бесперспективный язык ради написания драйвера, как-то глупо что ли.
> преимуществами. Например, большим количеством низкоуровневых обёрток.А ещё дженериками без type erasure, value-типами, перегрузкой операторов (не всем нравится, но лично я предпочитаю читать/писать `a + b * c` вместо чего-то вроде `a.add(b.mul(c))`, и, чем сложнее формула, тем трэшовее вариант с "обычными" методами), паттерн матчингом, именованными и опциональными параметрами методов, async-await и другими ништяками, появление которых в Java находится, в лучшем случае, на стадии планов и обсуждений. Дотнет можно ругать за некоторую завязанность на MS вообще и винду в частности, по части языковых фич он давно обошёл жабу.
Нет, в этих бенчах отражено ожидаемое поведение. Если запускать программу очень много раз на 5 секунд и каждый раз очищать файловый кеш между запусками.
> 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 тупо массив потоков, пишушщих в несколько массивов с "синхронизацией" через атомарную переменную.
Насчёт качества реализаций пусть каждый решает сам, но различия, не обусловленные ограничениями (например, отсутствием требуемой функциональности в стандартной библиотеке) той или иной платформы, сводят в ноль репрезентативность полученных результатов.
Люблю запах пригоревших догм по утрам
Смотрите с пригоранием поосторожней там, так можно и воспламенится. К ожогам прилагайте рекламные буклеты от MS.
В Java по любому использовали какой-то легаси stop-the-world GC иначе я не могу объяснить такой слив С-диез не только по throughput, но и по латенси.
Нет никакого разумного объяснения такого прорыва C# и Go. Тоже подозрения, что тупо тормоза GC или условия тестирования кривые.
Value types в Java есть? Нет. Вот и в исследовании предполагают, что из-за этого.
Уже реализовано, но не протолкнули в мейнстрим.
https://medium.com/@ramtop/a-taste-of-value-types-1a8a1...
Кто медиум читает - тот себе зла желает
Даже с Epsilon тормозит: https://github.com/ixy-languages/ixy-languages/blob/master/J...
У них там pdf-ка с разъяснениями есть. В C# есть unsafe блоки, указатели, value типы, можно почти полностью избежать GC. А в Java не выходит избежать, все время аллокации, потому на сборку мусора больше времени уходит.
тогда это тест только тех, у кого "не выходит избежать"
Есть техника работы со своими memory pool - выделяете массив, а дальше работаете с ним.На Ocaml'е народ из Jane Street занимается автоматическими спекуляциями примерно в этой технике - вполне нормально получается. Я не очень понимаю, почему они пишут low latence программы не на C, но тем не менее.
> C# не может быть настолько быстрее JavaХорошая мантра. Повторяй неустанно.
Зачем повторять. Видел своими глазами как банк переехал C# на Java, весь процессинг был полностью переписан. Сервера перешли на Linux. После чего пазл сложился и наконец-таки все стало работать как следует, стабильно и с достаточной производительностью.Такое зрелище будет помощнее любой мантры.
> весь процессинг был полностью переписан.Думаю, основная причина все-таки в этом. И особо не важно было, что «на Java».
В процессе любого переписывания выявляются узкие места, проводится наболевший рефакторинг.
Но убедить руководство переписать с “C# на C#” практически невозможно. А вот перейти на «более стабильную и проверенную технологию» шанс есть.
Ну и «сервера перешли на Linux» намекает, что это был ещё .Net Framework на Windows. В бумаге же наверняка фигурирует .Net Core, который совершенствуется на глазах и показывает себя молодцом.
C# будет быстрее Java в сетевом стеке как минимум потому, что там есть unsigned и на 8-битно число не нужно заводить 16-битное, на 16-битное, 32-битное и т.д. по списку.
Ну если авторы умели писать быстрые программы на C# и не умели на java, то вполне
нужно добавить 1С! ...просто чтобы питон не был замыкающим
Но для этого им (немцам) пришлось бы выучить русский язык, а это, кмк, уже слишком :-)
Ходят мифы, что в 1С таки есть англ.яз :D. Но российским 1с-писакам он неизвестен :D.
Чёт они про жопоскрипт забыли. Ну и ассемблера нету, для полноты веселья :D.
Это не миф, наверное. Лет 15 назад для 1С 8 сам писал модуль связи с БД. Визуал бейсик.
есть то он есть, но переводили имена функций и объектов там "промтом" и буквально, так что ни один здравомыслящий англоговорящий не поймет, или будет ловить лулзы с этих "названий"
Я писал на чистом бейсике.
1C как бы не тюринг полный язык.
пруф есть?
Чёт сомнительно, потому что даже странный css никогда не предназначенный для программирования является Тьюринг-полным.
Да что там говорить по css, даже в игре Factorio фанаты делали клон i8080.
Только C. Недавно свои архивы просматривал. Извлек программу - вьювер снимков для одного из первых отечественных томографов, написанную в 1995 году на языке C для MS-DOS. Запустил в 10-ке. Работает! И даже позволяет картинки захватывать в буфер обмена.
Может ещё C умеет платформо-зависимые компоненты писать переносимыми? В основном не язык определяет долговечность проекта, а голова и руки программиста.
Видимо на винде было написано. Но скорее всего с прямой работой с WinAPI, вот и совместимо.
16-разрядная DOS-программа? С 64-битными виндами уже несовместимо, там эмулятор WOW16 выпилили давным-давно.А в 32=битных запуститсч, чего б нет.
Программа, написанная на Си под DOS, и работает копирование картинки в буфер обмена Windows 10? Если честно, то верится с трудом (точнее - не верится).
Может вы имеете ввиду просто скриншот экрана, где помимо прочего есть так же и окно с вашей чудо-программой, которую вы каким-то образом запустили в Win10 (что тоже странно, т.к. ЕМНИП оттуда выпилили режим совместимости с DOS) с заголовком, рамкой и т.д. ?
Не могли бы вы больше технических подробностей привести?
Звездобол, откуда в 10-ке поддержка DOS'а?!
А как же brainfuck?
> А как же brainfuck?При чём тут твоя жена?
[-3] + 11 = 14 школоты
Остальные в курсе.
сюда, для полной картины, еще бы статистику по потреблению памяти
Еще время разработки и зп программиста. Для написания драйвера на С привлеки гуру, который на С лабает 20 лет. Фрика на расте, который в немецкий университетах из сабжа был один. И первокурсник который скачал экзампл драйвера на Го и поправил пару переменных.
Блин, я стесняюсь спросить - а КАК они написали драйвер сетевой карты на всех языках, кроме C, Rust и Go? На питоне например? Это как вообще?Где код посмотреть?
написали внешний подгружаемый модуль, работающий примерно как обычная программа в пространстве пользователя. там жек написано
> внешний подгружаемый модульнаписанный на чем?
я тоже с небольшим оптимизмом отношусь к драйверам на интерпретируемых языках. но они писали на всем)) там же описано. а о внешних подгружаемых модулях полагаю все слышали. еще со времен elf такие существовали. просто опять раст впихали.... ну не знают как и где его пропиарить.
А в чём проблема Rust, кроме того, что ты его ненавидишь по религиозным соображениям? Как видишь, он показывает себя отлично.
> Где код посмотреть?https://github.com/ixy-languages
Например
https://github.com/ixy-languages/ixy.py
https://github.com/ixy-languages/ixy.js
А, спасибо, не осознал что отдельные репозиторииЧерез mmap и memoryview общаются...
Офигеть, открытие - до этого я в юзерспейсе видел только Intel DPDK, а он работает через vfio-pci / uio_pci_generic, т.е. через специальный драйвер ядра. А тут вроде напрямую
Главное — никакой низкоуровневой работы с памятью!
Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность при использовании OCaml и Haskell?
> Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность
> при использовании OCaml и Haskell?Смотря как писать, думаю. Вообще, там есть копирование массивов, кмк, излишнее - см.
https://github.com/ixy-languages/ixy.ml/blob/master/lib/ixy....https://github.com/ixy-languages/ixy.ml/blob/master/lib/iXGB... и т.д. немного не идиоматично. По мне лучше бы
| RDT i when i < 64 -> 0x01018 + (i * 0x40)
| RDT i -> 0x0D018 + ((i - 64) * 0x40)С одной стороны, это идиоматический код, а с другой - там же всё равно DMA, и надо писать аккуратно. С третьей - зачем эмулировать язык C на Ocaml/Haskell? Возможно срезы (Slice), будь они реализованы в камле, помогли бы избавиться от копирования массивов.
----------------------------
По Haskell - ну беглый взгляд говорит, что почему-то не везде newtype стоят, можно директивы INLINE расставить, опять-таки, копирование буфера.
>> Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность
>> при использовании OCaml и Haskell?
> Смотря как писать, думаю.Я думаю, что писать надо, как криворукая обезьяна. То бишь как все.
Ну, вероятно, копирование буферов там и правда зря. А вот на идиоматиччность наплевать -- никто на неё смотреть не будет.Спасибо за разбор, Vkni. Если Вы ещё поиграетесь с этим куском кода, и сможете снизить потери производительности, дайте плиз знать, до каких пределов удалось оптимизировать.
> Я думаю, что писать надо, как криворукая обезьяна. То бишь как все.Тогда, в теории, нужен Rust. Но он слишком наворочен. И, конечно, на С удобнее писать - всё-таки С прямо предназначен для таких штук.
> Если Вы ещё поиграетесь с этим куском кода
Увы, нет времени.
Rust one love
Кто проплатил исследователей, тот и в топе.
Единственное нельзя было сделать победителем Go или C#, это бы не зашло.
Где С++?
Там есть ссылки на код: https://github.com/ixy-languages/ixy-languagesЕсли на каком-то языке сделано неправильно, то есть смысл предложить PR. Ну или хотя бы поделиться соображениями тут в комментариях.
> отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 разА что тут предлагать? По моему очевидно какая цена этому «исследованию».
> Если на каком-то языке сделано неправильно, то есть смысл предложить PR.А можно и не предлагать. Пусть их поделку дописывают и раскручивают за свой счёт те, у кого не хватило ума плюнуть и пройти мимо.
То есть по существу сказать нечего? :)
По существу авторы теста сами отписались, добавить тут абсолютно нечего. Просто одного наличия как минимум двух вариантов и отсутствие асемблера и еще, как минимум, плюсов делает это произведение как минимум похожим скорей на измышления неокрепшего кодера над выбором самого офигенного языка программирования в мире, дабы точно не пролететь с карьерой в мире информационных технологий. Ну пусть ковыряется, жалко чтоль, однозначно плюс к за труд, но с выводами лучше было вот так вот, в открытый мир, пока не лезть ;) ну или хотябы убрать пару вариантов, чтобы не выглядеть клоуном.
> Где С++?Не провоцируй: честный ответ на опеннете забанят.
> Где С++?Пока все еще компилируется.
Rust - рулит, что и требовалось доказать.
Это си рулит. Сорцы открой своего хруста.
Открыл.Rust 97.5% Python 0.6% JavaScript 0.4% C++ 0.3% Makefile 0.3% Yacc 0.2% Other 0.7%
Молодец, теперь посмотри как это сделано.
Посмотрел. Все на Rust, иногда дергаются библиотеки типа libc, но дурашка других в линюхах-то нет.
То есть, если я буду дёргать из js библиотечный код, то можно сказать, что у меня всё на js?
Драйвер на руст - это unsafe вызовы libc. Короче это - драйвер на си. Растоадепты, как обычно, всё украли и выдали за своё.
Позорище, даже в сорцы не глядел, а такие же безмозглые хейтеры плюсики ставят, поддакивают.$ loc
--------------------------------------------------------------------------------
Language Files Lines Blank Comment Code
--------------------------------------------------------------------------------
Rust 9 6344 895 631 4818
Markdown 1 143 47 0 96
Toml 1 13 2 0 11
Bourne Shell 1 10 0 1 9
--------------------------------------------------------------------------------
Total 12 6510 944 632 4934
--------------------------------------------------------------------------------$ grep -r unsafe | wc -l
55
А можно больше аргументации в пользу раст? - из перевода неясно, почему же такой вывод. Мне интересен раст, но вот именно в драйверах критична скорость, нет смысла переходить с С.
Памятебезопасность. Если у тебя неограниченное количество программистов с опытом на С в железках, тебе не надо.
Я вот удивляюсь, зачем в офисах С программистов всякие перила на лестницах, двери в лифтах понатыканы? Где-то даже таблички "мокрый пол" ставят. Внимательно смотри куда идёшь и всё будет в порядке. Unsafe означает: "Наткнулся на перила, подумал и решил, что стоит перепрыгнуть".
Вот ведь в "Одноклассниках" люди мучаются с явой, и не знают, какая она медленная для сетевых задач..
Исходнички бы посмотреть, как эти тестеры с сетью работали...
Ну открой да посмотри, исходники есть для всех тестов.
В исходниках не написано с какими параметрами запускали виртуальную машину.
о да, любимая отмазка свидетелей джавы: джава тормозит не из-за кривизны рук разработчиков, а из-за неправильных параметров запуска ВМ
Внезапно, так и есть. Авторы Java-версии открыто признают, что не заморачиваются и аллоцируют по объекту на пакет ("we still allocate around 20 bytes on average per forwarded packet"). Т.е. вместо самой программы они бенчмаркают сборщик мусора. А ещё они зачем-то используют Unsafe и volatile-поля, тем самым не давая JVM выполнять большинство оптимизации.
Самый интересный комментарий
Большинство жаверов кстати действительно не знают, какая она медленная.
На эрланге есть?
Возьми сишный драйвер, завяжи обмен с устройством на stdin/stdout, прикрути к порту evm и померяй.
Звучит глупо? Да, потому что эрланг не для этого.
А драйвер на джаваскрипте это не глупо? К тому же я слышал что эрланг используют там где нужно low latency.
Не смеши мои памперсы. EVM в усмерть ужирает память и особенно CPU на задаче чутьболее сложной и выходящей из Си рантайма. Так что так только звонки форвардить...
Насчёт low latency не скажу, есть среди его характеристик некая "soft real-time", так это просто возможность сообщить об ошибке, если воркер не вернул результат запроса в течение заданного таймаута.
Главная фишка Эрланга, как принято считать - в неубиваемости. Ошибки и непредвиденные ситуации возникнут по-любому, а значит давайте не избегать ошибок, а быть к ним готовыми. Отсюда парадигма "Let it crash" - "Пусть грохнется".
Ерундой занимаются, а ничего что есть специализированый язык Vala для создания кода с безопасной работой с памятью, и компилируемый/интерпретируемый в чистый C, почему то не включили в обзор, случайность ? не думаю ...
А они точно про него слышали? Ищем "LANG_NAME programming language" в гугле. Количество результатов: Vala - 3,740, Ada - 107,000, C - 4,880,000, C# - 721,000, D - 557,000, Nim - 8,990, Rust - 201,000.
Вот D интересно увидеть в подобном сравнении.
Ну наконец-то https://imgur.com/NFinaiK
Зато переносимость.
Где C++ в тестах?
Почти все противники С++ в разработке железа и оборудования. Не видать вам классов в драйверах как своих ушей =)
Я сам противник плюсов в драйверах и низкоуровневых библиотеках, но если эти "утырки", додумались запихнуть в тест решётку, жабу и даже пихон с JS, то отсутствие плюсов можно объяснить не иначе что они добавили их, но они уделали ржавого по всем пунктам, и их пришлось удалить из графика.
Блин. На JavaScript нельзя писать драйвера. Обидно :(
> язык Rust является лучшим кандидатом для разработки драйверовсначала культурные люди напишут на расте а потом какой-то бородач перепишет всё на сях и снова все будут пользоваться нормально написанным драйвером потому что он быстрее
2% тормознутости растового драйвера помноженные на годы использования не стоят того чтоб экономить на нормальном программисте
ох уж эти мифические нормальные си-программисты, которые никогда не ошибаются. Пока твой нормальный си-программист будет ошибки отлавливать в своем драйвере, растовый нормальный программист напишет десяток работоспособных приблуд с минимумом ошибок.
> Замкнул рейтинг драйвер на языке Python, который смог обработать всего 0.14 млн пакетов в секунду.GIL всех схоронил
Нет, почитай новость, они _специально_ сделали драйвер на питоне самым медленным.
По всей видимости они просто ниасилили написать на питоне. Но ведь это же такой простой язык на котором напишет и макака...
Недавно делал программу на питоне с хитрым перемножением-сложением матриц. Работает, но медлено. Переписал с использованием фич питона, с использованием list-ов, yielld-ов и zap-ов. Не помогло. Переписал, заменив всё вызовами numpy. Ускорилось на 3 порядка.Вывод: оптимизации в питоне — вещь неочевидная.
Вывод - использовать нативный код, что и было сделано с numpy
Про то и речь, что написали вычислительное ядро на Си. И обернули питоном.
numpy использует библиотеки blas / openblas , в большой части написанные на фортране (например https://github.com/xianyi/OpenBLAS/wiki/Installation-Guide)
Не порите чушь, ей больно. Исторически BLAS действительно был написан на фортране, но сейчас от фортрана там остался только API (которым и не пользуется никто, все давно переехали на сишное API, CBLAS). Тот же OpenBLAS написан на сях с ассемблерными вставками, SSE и AVX для выжимания каждой капли производительности из железа.
> При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка.
> Реализация на Python была использована для оценки скорости работы интерпретаторов без JIT и без специфичных оптимизаций (код выполнялся с использованием CPython 3.7 и не был совместим с PyPy, но отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз).Мне одному кажутся эти два абзаца противоречащими друг другу?
А, ну понятно.> Performance is not the primary goal of this (Pytohn - прим. меня) version of our driver, it is the only implementation presented here that is not explicitly optimized for performance. It is meant as a simple prototyping environment for PCIe drivers and as an educational tool
То есть, если использовать еще один вариант питона, и подключить нормальные Си библиотеки, то он тоже сможет потягаться.
Получается, что питонистам нужно знать си, чтобы писать на нём библиотеки для питона, если нет нужного функционала?
Получается, что питонистам как я и яваскриптистам с явистами, в целом вообще незачем писать дрова для сетевых карт. Это все равно что шуруповертом гвозди забивать. Ну да, возможно, в принципе и, наверное, весело.
Тестирование производительность, но этот вариант мы делаем без прицела на производительность. Не то что бы я за дрова на питоне, но это какой-то бред.
Ну так ни у кого не было сомнений, что чисто интерпретируемый язык будет работать медленно.
Тут не всем это очевидно, это очевидно.
> almost matches the speed of the C implementation but with the added features of Go (~10% performance loss, depending on batch sizes and CPU speed)Как я и говорил, у Go оверхед в 10-15%, если писать оптимально.
>Как я и говорил, у Go оверхед в 10-15%, если писать оптимально.А если писать на С, то вообще нет.
...но вместо оверхеда появляется букет ошибок, некоторые из которых находятся и фиксятся через десятилетия.
Есть там оверхед. https://github.com/ixy-languages/ixy-languages/blob/master/R...Там статья берёт вопрос "почему раст оказался медленнее", переформулирует его в формат "почему раст так мало отстал -- не на десятки процентов, а на единицы" (приводя аргументы в пользу того, что это более правильная постановка вопроса), и предлагает ответ, основываясь за замерах профайлера. Часть ответа -- C очень неэффективно работает с кешом, мажет мимо L1 три раза из четырёх.
Правда это про конкретную реализацию, конкретной программы, и может если переписать этот сишный код, сделав его более кеш-френдли, то будет лучше. Но мне лень, если честно, может я и доберусь посмотреть на код, чтобы понять как это выходит, но делать лучше я не буду в любом случае. Ты можешь попробовать, если ты сделаешь лучше -- закинь свой код исследователям, чтобы они пофиксили результаты.
minix3 уже все сделал.
А не Rustовый Redux все уже сделал
> Предоставляемые в Rust возможности позволяют избавиться от проблем, возникающих из-за низкоуровневой работы с памятью,Через использование 49 unsafe блоков с низкоуровневой работой с памятью? Классно избавились, зачёт.
Раст более безопасен. Но не полностью) Читай впитывай https://news.ycombinator.com/item?id=16962551
unsafe используется для взаимодействия безопасного кода rust с "внешним миром", здесь - API ядра Linux.
Для желающих разобраться с unsafe есть https://doc.rust-lang.org/nomicon/index.html
Дело в том, что когда ты используешь unsafe ты знаешь что на самом то деле оно безопасно..Типа ты понимаешь что творишь.
Это как указатель что "я знаю что тут возможно выйти за границы буфера, но этого по моему индексу никогда не случится"Поэтому да, так безопасно
Дело в том, что когда ты используешь Си ты знаешь что на самом то деле оно безопасно..
Типа ты понимаешь что творишь.
Это как указатель что "я знаю что тут возможно выйти за границы буфера, но этого по моему индексу никогда не случится"Поэтому да, так безопасно
Дело в том, что когда ты пишешь каждую строчку на Си ты знаешь что на самом то деле оно безопасно..Это как указатель "Я - супермен, я - делаю в 500 раз меньше ошибок, чем всякие там прочие".
Поэтому да, так безопасно
Вот это очень странно слышать от вроде как специалистов. Понятно, когда речь идёт про детский сад и предметы там делают безопасными, хотя даже там не всегда это разумно для всего делать. Но когда специалисты голосуют за безопасные инструменты жертвуя эффективностью и что ещё хуже - удобством инструментов - это что-то совершенно за гранью и возникает вопрос в адекватности специалистов то есть специалисты ли они вообще? Ведь всегда, с начала времён люди старались делать удобные, эффективные инструменты. Все остальные параметры шли после этих двух основных. Порой параметр безопасности был важен, но только там где он был сильно важен, он учитывался. Скажем поварские ножи делают максимально острыми и это идёт в разрез с безопасностью, потому что неосторожным движением можно фалангу отрезать, а тупым ножом максимум будет порез глубокий.В общем что-то странное с миром происходит, сбрендили.
Программисты режут пальцы в основном юзерам, это не так чувствуется и ощущение полноты контроля и эффективности инструмента есть.
Да замучались просто CVE латать. Уж сколько пишут-пишут, исправляют-исправляют, даже самые специалисты, а все равно дырка за дыркой обнаруживается, и в большинстве случаев - именно некорректная работа с памятью. Вот и решили что-то кардинально поправить, сколько можно дырками дырки латать.
Так ведь же без хлеба останутся.
Не посмотри на синтаксис и сложность Rust там еще и на икру можно
> голосуют за безопасные инструменты жертвуя эффективностьюЯсен день, деньги же считаем и данные обрабатываем.
Жаль что не все деньги сосчитаны и не все обработаны,
но у конкурентов будет лучше не преживайте
Эта позиция, мол если взять достаточно квалифицированных C программистов, то не будет проблем с памятью -- это очень старая позиция, и она в общем разрушена. Особо упёртые продолжают стоять на руинах и по принципу "ссы в глаза -- божья роса" талдычить одно и то же, мол ищите специалистов.Если ты не веришь, покажи мне какую-нибудь из своих программок на C, размером от 10k строк, я потрачу выходные и найду тебе там проблемы с памятью или UB. Ну, это на тот случай, если ты думаешь что ты являешься примером C программиста, который не совершает ошибок, то я покажу тебе, что ты ошибаешься как минимум в двух случаях: тогда, когда пишешь код на C, и тогда, когда оцениваешь свои способности.
> Ведь всегда, с начала времён люди старались делать удобные, эффективные инструменты. Все остальные параметры шли после этих двух основныхНу да, все удобные и, главное, эффективные инструменты уже изобрели в каменном веке. Прогресс остановился, ведь ничего не изменяется, правда? Как вы умудрились с помощью палки-копалки и скребка написать коммент на опеннете?
>> Ведь всегда, с начала времён люди старались делать удобные, эффективные инструменты. Все остальные параметры шли после этих двух основных
> Ну да, все удобные и, главное, эффективные инструменты уже изобрели в каменном
> веке. Прогресс остановился, ведь ничего не изменяется, правда? Как вы умудрились
> с помощью палки-копалки и скребка написать коммент на опеннете?Очень просто. Он запустил Emacs и включил M-x butterfly-mode.
> Но когда специалисты голосуют за безопасные инструменты жертвуя эффективностью и что ещё хуже -
> удобством инструментов - это что-то совершенно за гранью и возникает вопрос в адекватности специалистов
> то есть специалисты ли они вообще?Не, не возникает такого вопроса. Потому что есть простое объяснение: не существует такого количества специалистов, чтобы удовлетворить всесь спрос рынка IT.
Так что рынок добирает недостающее посредственностями, и их, увы, большинство. Чтобы эти посредственности делали полезную работу и не мешались -- мы проголосуем за то, чтобы пожертвовать эффективностью в пользу удобства и безопасности.
Так что не сбрендили мы, всё закономерно.
PS. А ещё, давайте будем честными хотя бы перед собой: даже специалисты ошибаются.
почему с++ нет?
С++ это не нужная надстройка. Тот же раст только с другим синтаксисом. Заодно посмотри в ядре сколько строк на С++ удивись.
> С++ это не нужная надстройка. Тот же раст только с другим синтаксисом.
> Заодно посмотри в ядре сколько строк на С++ удивись.любой язык надстройка над ассемблером. так мне интересно кто лучше раст или с++
Над машинным кодом, а не асмом.
Если ты программируешь на С++ и зарабатываешь на этом, то лучше конечно С++ для тебя.А если тебе интересна фишечка Rust, так это хранение vtable отдельно от типа и соответсвенно экономия пары сотни байт на этом. А ну и так по мелочи всякого добавили там защиты всякой.
Вот только когда в Rust сделают нормальное наследование, только тогда он сможет заявлять о себе как о замене C++. А так ни разу не замена.
На кой оно вам сдалось? Привести пример кода можете, где прям без наследования ну никак нельзя?
Зачем тебе наследование? Это мертворожденная фича, которой практически никто уже не пользуется ни в каких языках. Даже для UI. Трейты рулят. Композиция.
Радует участие OCaml.
Университет же, единственное место где его возможно встретить
Есть мультиклиент различных P2P-сетей на нём http://mldonkey.sourceforge.net/
Не единственное - Facebook/Jane Street и другие по-мелочи.
Тест по пороизводителность...
Но, где тест по нагрузке на процессор и тест по потреблению памяти?
Можно предположить они съели все ресурсы от 3 Ггц проца.
Они не думают что 2-10% это тоже много, если 1 драйвер - это не страшно а теперь представляем ОС состоящую только из подобных драйверов и все с такими "просадками" производительности ... в итоге получим черепаху которая "нормально" будет работать разве что на дорогих компах ...
Люблю Раст, но плюсую что просадки производительности 2% для драйвера это многовато..
Все эти исходники могут сильно различаться по степени оптимизированности. Ну и плюс это сравнение не языков, а компиляторов и рантаймов. Которые ещё разных версий бывают. Раст должен работать без оверхеда над си, если где-то проседает значит либо код неоптимальный либо в компиляторе есть что улучшить.
Нельзя забывать что ОС - это куча других разных вещей. Взять тот же Clear Linux - при тех же самых исходниках умудряется иногда производительность выжимать в несколько раз больше. Если ОС сама по себе не будет давать большого оверхеда, то драйвер медленнее линуксического на 2-10% не будет такой большой проблемой.
>о драйвер медленнее линуксического на 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-Очевидно, что "идиоматический" стиль, особенно для критичных частей, типа дров, можно и не выдерживать.
Ну и вообще, делать выводы из разницы в пару процентов в _таком_ тесте я бы поостерегся.
> Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-Т.е. экономические затраты датацентра (на электричество) при переходе на такой вот драйвер вырастут.
> > 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).
То есть целых 10% производительности надо отдать за возможность хипстерков писать на моднявом язычке? С учётом того, что стоимость разработки на C/хрусте выйдет примерно одинаковой, а толковых программистов на первом больше - не, спасибо.
Когда-то давно хипстеры Керниган и Ричи переписывали UNIX с ассемблера на наколенную поделку, которая позже стала языком C. Наверно тоже сколько-то процентов производительности потеряли. Оптимизатора в компиляторе С тогда особо не было.
Впрочем, из-за чего там эти 10% в статье особо не разбирались, а предположили, что из-за bounds checking. Но, если что, bounds checking можно и отключить.
> Когда-то давно хипстеры Керниган и Ричи переписывали UNIX с ассемблера на наколенную
> поделку, которая позже стала языком CЕщё один, не осиливший разницу между транслятором ассемблера и реальным ЯВУ.
У хруста например такой разницы нет, скорее даже хуже стало.
> У хруста например такой разницы нет, скорее даже хуже стало.(разницы с сями, естественно) - просто ещё одна потуга на предмет "альтернативного" яву, на тему "а вдруг выстрелит - тогда личный профит".
помнятся мне эти "нормально", там дорогой компа даже не спасает из-за wait for response.
Менеджеры и так софт в говно превратили ради быстрой разработки, и продажи. Теперь за саму ОСь взялись.
0.98*a + 0.98*b + 0.98*c + 0.98*d = 0.98*(a+b+c+d)
Если каждый компонент просядет на пару процентов, общая скорость тоже лишь на пару процентов должна.
Скорее: 0.98 * 0.98 * 0.98 * 0.98 ~= 0.92 (если эти модули используются последовательно)
> Скорее: 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 стали переписывать. Причем тогда у них были более весомые аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые С-компиляторы наверняка генерировали не самый оптимальный код.
> Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
> на C стали переписывать. Причем тогда у них были более весомые
> аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые
> С-компиляторы наверняка генерировали не самый оптимальный код.Вы исходный код ядра давно видели ? Все более менее значимые участки на ассемблерных вставках..
> Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
> на C стали переписывать. Причем тогда у них были более весомыеОсиль уже разницу между транслятором мнемоник машкода и таки ЯВУ, потом бредь.
И как часто эти драйвера вызываются? У тебя из основного:
Драйвер контроллера (накопители)
Видео драйвер
Аудио драйвер
Сетевой драйвер
Итого ~10% просадок неравномерно по времени распределённых. Остальные драйвера вызываются очень редко если нет какой-то специализации.
Вы на браузере написанном нам c++ и сайтиках тратите гораздо больше тактов чем на этих драйверах. Когда та же лиса или хром в фоне ощутимо жрут ЦП на всяком мусоре.
Обычно производительность во многом зависит от архитектуры драйвера, даже если там числодробилки надо их с умом использовать и бывает так что умный код на высокоуровневом языке оказывается производительнее кода байтоёба, банально байтоёб забил на асинхронность и синхронно долбит вызовы просирая кучу времени на эту синхронность. Так что сравнивая языки надо учитывать ещё и лёгкость написания умного кода. Когда язык требует большой осторожности то неминуемо он сожрёт время на это, когда как это время можно было потратить на более продуманный код.
Для каждой машины, которая отдаёт тебе статический например видеоконтентик, который ты смотришь в том самом браузере, этот самый драйвер чуть ли не основа основ.
>[оверквотинг удален]
> чем на этих драйверах. Когда та же лиса или хром в
> фоне ощутимо жрут ЦП на всяком мусоре.
> Обычно производительность во многом зависит от архитектуры драйвера, даже если там числодробилки
> надо их с умом использовать и бывает так что умный код
> на высокоуровневом языке оказывается производительнее кода байтоёба, банально байтоёб
> забил на асинхронность и синхронно долбит вызовы просирая кучу времени на
> эту синхронность. Так что сравнивая языки надо учитывать ещё и лёгкость
> написания умного кода. Когда язык требует большой осторожности то неминуемо он
> сожрёт время на это, когда как это время можно было потратить
> на более продуманный код.И так начнём, представьте что Вы используете видео драйвер который написан на этом деле со своими просадками в производительности и отзывчивости, используется он как ни странно 99% рабочего времени пользователя... Конечно если Вы не юзаете сервер без видео вывода. Получаем что производительность и отзывчивость системы в целом да и в мультимедиа упадёт не на 10%. Так как системе и приложению ещё нужно использовать винт, сеть, звук, устройства ввода, каждый драйвер со случайной просадкой производительности и отзывчивости... Будете играть и со скоростью эмуляторов плоек и задержками на каждом вводе ...
А вот про правильный код, тут вопрос открыт, у всех он свой... у проприетарщиков работает на костылях - правильный код.
> При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка.У авторов действительно есть хотя бы несколько лет профессионального использования каждого из этих языков. Профессионального в смысле при написании высокопроизводитнльного софта (Google, Netflix,..).
Было бы гораздо интереснее, если бы был объявлен открытый конкурс на более эффективную реализацию для каждого из языков. Я думаю, что результаты были бы достаточно другими. Те же сорцы на го — там есть что оптимизировать…
ассемблера не ?!?
а было бы смешно увидеть графиках даже асм который бы сливал русту)))
намекая на явно заказные тесты от мозиллы
Ассемблер далеко не всегда быстрее.
в большинстве прямые инструкции будут куда быстрее того же си-шного кода. единственный вариант, что драйвер на сях или любом языке будет собран с особым упором на поддержку всех инструкций процессора, а ассемблерный код будет пользоваться основным множеством инструкций имеющихся во всех процах(моделях). но даже так при сборке такого драйвера будет несколько лишних инструкций из за особенностей языка. но интерпретируемые языки? и специально ограниченные самой медленной конфигурацией? правда попахивает заказом))
> Ассемблер далеко не всегда быстрее.Ну если уровень теоретической подготовки низок, если нет знаний о процессе оптимизации, то есть если писать на асме в стиле модного смузихлеба - то конечно не всегда. Во всех остальных случаях - всегда.
Оригинальный способ проводить сравнение компиляторов с интерпретаторами.
на Lua было бы быстрее
Если сравнивать с питоном и js
Сравнивали Lua на какие-то сотые проценты лучше Python,
с JavaScript в 9 - 15 раз быстрее ...
С JS корректно сравнивать LuaJIT.
https://github.com/Griggorii/linux-image-5.2.11_X86_64_zstd_...
Вне рабочая просьба у кого systemd не версии 240 , а выше проверить это ядро и написать работает или нет , у меня в ходе разработки возникли опасения что род более новые системд нужно конфигурировать по другому. Интернет ваифая вот что надо что бы работал этот подпункт если исчез дайте знать. Ядро там v11 деб пакетами ниже скачайте.
Не понимаю, как свифт может работать со скоростью жс? Он же компилируемый. И эппл его продвигал для приложений и прочего. Получается, что они должны быть +- как на электроне?
Они там в pdf-ке с анализом пишут:Swift increments a reference counter for each object passed into a function and decreases it when leaving the function. This is done for every single packet as they are wrapped in Swift-native wrappers for bounds checks. There is no good way to disable this behavior for the wrapper objects while maintaining an idiomatic API for applications using the driver. A total of 76% of the CPU time is spent incrementing and decrementing reference counters. This is the only language runtime evaluated here that incurs a large cost even for objects that are never free’d.
76 процентов, Карл!
Тормоз этот ваш свифт.
Что-то полная жесть. Точно не помню, но по-моему видел намёки на то, что чуть ли не бэкенд писать на нём можно. Но кому оно надо в таком виде.
Интересно, Objective-C не имеет такого косяка? Если нет, то переход на более медленный язык выглядит так себе. Разве что для смузихлёбов.
в swift есть struct и class, struct - это тип-значение, а class - это ссылочный тип, возможно они классы использовали вместо структур?
и вроде если структуры использовать, должно быть быстрее?
а с другой стороны, может сама реализация ARC нелучшая, с какими-то недостатками?
https://github.com/ixy-languages/ixy.swift/tree/master/ixy/S...Они сделали все как class. Если поменять на struct летать будет.
Class: reference counting + lock for multithreading.
Struct: no reference counting, no safe multithreading(should be immutable)
Пистон провалился, я не удивлен. Этот монстр скоро вообще забудет, что такое скорость о обрастет жиром.
Зато он гламурный, а ты просто завидуешь.
народ в угаре от этого теста и не может остановиться. ржет и падает. у нас не 1 апреля случаем? вроде нет. тогда тут либо тестеры дауны, либо они недоученные прогеры. и то и то не очень солидно)) и правда почему плюсы не использовали? полагаю было бы один в один с Си.
"ржём, падаем, в угаре, 1 апреля, дауны, недоученные"Всё, что нужно знать об уровне дискуссий фанатов "языка, доступного каждому".
знаешь если питон применять с умом он очень даже хороший язык. ну если пихать его туда где солнце не светит , то да)) ресурсоемкими задачами должны заниматься компилируемые языки. и если тестеры даже этого не понимали, то извини кроме как недоучек их не назвать.
> этого не понимали, то извини кроме как недоучек их не назвать.Питон там как представитель интерпретируемых языков без JIT. Поэтому они ни PyPy не использовали, ни оптимизацией особо не занимались - и так ясно, что на этой задаче он сольёт.
> знаешь если питон применять с умом он очень даже хороший язык. ну если пихать его туда где солнце не светитУ Питона есть некоторая неочевидность семантики. А главное - фоннаты Питона пихают его вообще везде. Когда я рассказываю, что не надо на нём писать сложную бизнес логику с большим количеством ветвлений (при этом кол-во тестов комбинаторно увеличивается), на меня смотрят с вытаращенными глазами. В лучшем случае поддакивают из вежливости.
А про то, что тесты, включая юнит-тесты, это, вообще-то некоторый код, который приходится поддерживать - за гранью понимания. Можете проверить сами - спросите, какие есть минусы у юнит-тестов у коллег. Вот и выясните, кто там "программист минус инженер".
Это язык для прототипирования нетребовательных к производительности интерпретатора программ (всё скоростное должно быть вынесено в С или другие языки).И если не заниматься закручиванием гвоздей отвёрткой, то всё будет нормально.
Годный убедительный тест.
Но однозначно не хватает FPC. Есть подозрения, что, внезапно, он асимптотически сходился бы с кодом на Раст.
Да, было бы не плохо в такой тест включить Free Pascal, который развивается семимильными шагами. Что удивительно.Не пришлось бы отсылать к вопросу скорости Паскаля на ресурсы вроде такого: https://www.quora.com/Is-Pascal-faster-than-C?share=1
Было бы более объективно.
Напиши. 1000 строк кода при возможности подглядывать в C'шный код -- это при худшем раскладе займёт выходные за месяц. Если писать вечерами и на выходных, можно управится за неделю.
Бедный питон :)И да - не хватает варианта C++
> Дополнительно были проведены тесты на время задержки, которые показывали эффективность буферизации и влияние сборщика мусора.Они хотя бы погоняли драйвер в рабочем состоянии несколько часов прежде чем снимать показания? А то на прогреве любое гогно может рисовать неплохие числа .. кроме питона.
Блин, не могу, придётся потеститьvirtio оно говорите поддерживает...
Why C and not a more reasonable language?It's the lowest common denominator that everyone should be able to understand -- this is for educational purposes only. I've taken care to keep the code simple and understandable.
When should I use this?
To understand how a NIC works and to understand how a framework like DPDK or Snabb works.
Отсюда вопрос - а зачем они сравнивали на скорость нечто, что создавалась как учебное пособие? Т.е. я так понимаю, что это для всех языков примерно такой подход.
Всех с Днём Программиста! (^_^)/
Python красава. Даже на это го@#о голову не поднял, посмотреть че там его за хвост тягают. Это не царское дело.
На JavaScript?!.
Мсье знает толк...
Да блин, Rust, GO вся проблема в руках!!!
В результате что на Rust что GO будут использовать unsafe и получится таже фигня.
я бы хотел такой же драйвер на Dlang увидеть в вариантах без GC и с ним
те же плюсы получатся))насколько помню даже один из разработчиков плюсов у них язык развивает. так что думаю получится тоже самое в чуть более удобной обертке. и то хорошо. а скорость по идее не должна уступать С. хотя ничего не скажу , я его только мельком глянул.
> те же плюсы получатся))насколько помню даже один из разработчиков плюсов у них
> язык развивает. так что думаю получится тоже самое в чуть более
> удобной обертке. и то хорошо. а скорость по идее не должна
> уступать С. хотя ничего не скажу , я его только мельком
> глянул.вот тут внезапно c# и java оказались сильно разными, а c и rust сильно одинаковыми
хотелось бы результатов тестов
Попытку захайпать хруст как язык в т.ч. для низкоуровневых приложений оценил, но спасибо, нет. Костыль на костыле и костылём погоняет.
Я уж молчу про то, что код на сях в оx*иллиард раз читабельнее и очевиднее. Пока что потуги придумать что-то лучше сишного синтаксиса около которого вертятся всегда востребованные C,C,Java,PHP,etc. успехом не увенчиваются, увы.
C++ в тестах отсутствует. Нечестно, всё-таки, широко известный ЯП.
Удивило оставание OCaml, который в машинные коды, от Java, которая в JIT и в виртуальной машине.
OCaml показал себя лучше явы: пропускная способность на уровне, а задержки значительно меньше.
По первому графику совпадение тоько при 64-х пакетах, в других точках отставание.
Разница незначительная.
Я подозреваю, что Ocaml можно сильно разогнать, убрав аллокации - народ в Jane Street пишет low latency код на Ocaml для спекуляций. Но это не идиоматично.Второй момент: JIT - это же и есть машинные коды. Just-In-Time compile. То есть, на hot path и Ocaml, и Java скомпилированы одинаково.
его к сожалению мало кто хорошо знает)) хотя пишут много кто, но он разросся в такого монстра, что страшно. чистый Си выглядит куда проще)) хотя у плюсов есть плюсы))) ахаха хорошо загнул.
А где мои любимые php и vba?
ты их через браузер погонишь? хотя погоди, запросы будут через внутренний сервак отправляться? помилуй железо оно и так страдает))
питон через солнце запускали что-ли?
> питон через солнце запускали что-ли?Через ж*... да, через солнце.
Не, кроме шуток, его вроде компилировали, если я их текст правильно понял.
Не-а. Как раз-таки в интерпретаторе его гоняли.
> Сетевой драйвер работает в пространстве пользователяХрень какая-то. В пространстве пользователя ничего с картой сделать невозможно, ни сконфигурировать, ни обслужить.