Компания Amazon представила криптографическую библиотеку aws-lc-rs, предназначенную для использования в приложениях на языке Rust и совместимую на уровне API с Rust-библиотекой ring. Код проекта распространяется под лицензиями Apache 2.0 и ISC. Библиотека поддерживает работу на платформах Linux (x86, x86-64, aarch64) и macOS (x86-64)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59004
> При тестировании работы протоколов TLS 1.2 и 1.3 библиотека aws-lc-rs заметно опередила по производительности пакет rustlsПолучается, что С++ быстрее Rust, раз биндинги к С++ либе быстрее кода на самом Rust?
Ты думаешь «безопасность» берется из воздуха? Нет для этого надо выполнять дополнительные операции на каждом цикле и на даже на каждом такте.
Но как же так? Люди же везде громко говорят про Раст, что там все проверки на безопасность во время компиляции, в рантайме ничего такого
> Но как же так? Люди же везде громко говорят про Раст, что там все проверки на безопасность во время компиляции, в рантайме ничего такого"Тихо, сам с собою ..."
Всё он правильно говорит. А как же ваши "zero cost abstractions"?
А никто, кроме вас, луддитов-наСИльников с опеннета, и не утверждает, что в расте ВСЕ ДОСТАТОЧНЫЕ проверки ТОКЛЬКО во время компиляции осуществляются. Мир не черно-белый. Часть делается и в рантайме, а часть и в компайл-тайме благодаря системе типов, владению и т.д. И обе эти части наСИльники обязаны были бы делать в рантайме (в отличие от раста), но делают не всегда, ибо "производительность" (а чаще лень или недостаток профессионализма). Потому и имеем 70% ошибок - это профессионалы не смогли или забыли/забили что-то проверить.
> Всё он правильно говорит. А как же ваши "zero cost abstractions"?Ну давай тогда пруфцы на "Люди громко говорят ...", раз не Воен^W балабол?
Только учти, ссылка на попук^W скандирования опеннетных Военов Супротив Раста тут, как бы, не катит.
Пруфец на "дополнительные операции на каждом цикле" тоже не забудь.
Oh, там же типа zero-cost проверки в компайл-тайм. Уже нет что ли?
> Oh, там же типа zero-cost проверки в компайл-тайм. Уже нет что ли?Удивительно ... нет, даже поразительно! Как! Как очередной Опеннетный Эксперт за тройку минут сумел проанализировать и сравнить две разных криптолибы и сделать выводы что сами реализации эквивалентны и вся разница в скорости - из-за "рантайма". Гениальность, не иначе!
Или все проще и никто из Экспердов никуда не глядел, о куче асма и интринсиков в обоих реализациях даже не подозревает, просто прикинули палец к носу "как оно там все должно быть"?
Откуда в чистом растокоде асм код? Ты что тоже еретик?
Более того, у таких экспертов две разные С++-программы одного назначения написанные разными людьми будут работать со скоростью, одинаковой до наносекунды. "Ибо изык порешал, а не прокладки!"
Это они еще оптимизацию -O2 включили как обычно, маркетинг, такой маркетинг.
Ну да, теперь пусть включат -O3 и PGO прогонят. Разрешаю у раста тоже включить.
Да и GCC пусть собирают, а то смешно будет llvm с llvm сравнивать.
https://github.com/aws/aws-lc
> C++ 68.2% Assembly 17.0%
> Получается, что С++ быстрее Rust, раз биндинги к С++ либе быстрее кода на самом Rust?Получается, что оналитега у опеннетных Военов Супротив Раста - как обычно получается.
> aws-lc-rs is a cryptographic library using AWS-LC for its cryptographic operationsAWS-LC (https://github.com/aws/aws-lc): C++ 68.2%, Assembly 17.0%, C 9.2%
> Rustls is a modern TLS library written in Rust. It uses ring for cryptography
ring (https://github.com/briansmith/ring): Assembly 38.2%, C 32.2%, Rust 25.8%
Если не считать сами обёртки (aws-lc-rs и rustls), то библиотека совсем без Раста оказалась быстрее библиотеки, на четверть состоящей из кода на Rust. Что в #1 написано не так?
> Раста оказалась быстрее библиотеки, на четверть состоящей из кода на Rust.Как элегантно ты упустил в своем онализе "а еще на ⅓ из кода на Си и на ⅖ асм".
> Что в #1 написано не так?По этой "логике" у Воена Супротив Раста получается, что C++ так же быстрее сишки и асма, ведь "биндинги к С++ либе быстрее кода на Си/Asm".
В общем, что так, что эдак - выходит "опеннетный онализ" во всей его красе ...
Тому оналитегу указали на то, что в его стаканчике с мороженым есть еще немаленькая ложечка г.вна, а он пытается сравнивать сорта чистого продукта, чего уже достаточно для некорректности сравнения... Но ты пошел дальше. Так взволнованно дышать на конкретные циферьки процентов примесей - это как спорить еще и о сортах добавленного г.вна и о том, что хуже - одна добавленная чайная ложечка или полторы. Да даже капельки достаточно чтобы было бессмысленно сравнивать мороженое!Более того. Ты же понимаешь, что возьми вас, двух непогрешимых опеннетовских экспертов-оналитегов, посади порознь, дай одну и ту же задачу и даже поставь условие ее решить на одном языке - только на С++ или только на асме - то получатся две разные программы по куче показателей, в том числе по производительности и надежности. А тут даже мешанина разных языков. Поэтому неважно, сколько там процентов чего - в каждой этой части кода разными программистами всё будет реализовано настолько по-разному, что сравнивать по полученному результату сами языки - верх глупости. Так ты можешь приблизительно сравнить только самих программистов.
А когда тебе показывают две разные программы одного назначения, написанные _разными_ командами, обе на С++, обе компильнуты GCC и одна быстрее второй, допустим, в два раза - у тебя в таком случае С++ быстрее С++ ?Я может быть принял бы во внимание твой вывод, если бы это одна и та же команда, являясь экспертами одинакового уровня в обоих языках программирования (а как это сравнить?) написала с нуля две одинаковые по фичам реализации одной и той же хни и что-то там замерила.
>and deploy them into AWS RegionsНу что, где крыса зарыта, к какой части кода?
Где крыса заржавела?
Снова на расте, хотя, может это и к лучшему. Сейчас много всего для крипты и криптографии на расте, а это взаимосвязано.
В том то и дело, что нет. Казалось бы, уж где бы в первую очередь применять раст, как ни в криптобиблиотеках? Но нет, они на плюсцах написаны...
язык для создания обёрток
Хахаха! В точку!
Да, С++ он такой.
Почему не было новости что на языке который нельзя называть переписали строян и теперь он более безопасно используя память пролезать на компутеры с виндой?
https://www.hivepro.com/nokoyawa-2-0-a-reworked-rust-based-r.../
> При тестировании работы протоколов TLS 1.2 и 1.3 библиотека aws-lc-rs заметно опередила по производительности пакет rustls, продемонстрировав как сокращение времени установки соединения, так и увеличение пропускной способности (в тестах ECDSA более, чем в два раза).неверифицированный с кучей багов код на раст безопасно проигрывает верифицированному коду на сишке в два раза. Эпичная замена.
> неверифицированный с кучей багов код на раст безопасно проигрывает верифицированному коду на сишке в два раза. Эпичная замена.https://github.com/aws/aws-lc/tree/44a1c471faf65cbfd57e62b8a...
https://github.com/aws/aws-lc/blob/2034e844e5908b14edff66a4b...
vmovdqa xmm14,XMMWORD[r14*8+r13]
vmovdqa xmm13,XMMWORD[16+r14*8+r13]
vmovdqa xmm12,XMMWORD[32+r14*8+r13]
vmovdqu xmm10,XMMWORD[((0-128))+rdi]
https://github.com/aws/aws-lc/blob/44a1c471faf65cbfd57e62b8a...Эпичный пук в лужу от очердных Военов Супротив раста
> movdqa xmm14,XMMWORD[r14*8+r13]
> AWS-LC contains portable C implementations of algorithms needed for TLS and common applications. For performance critical algorithms, optimized assembly versions are included for x86 and ARM.
>> проигрывает верифицированному коду на сишке в два раза.
>> movdqa xmm14,XMMWORD[r14*8+r13]
>> AWS-LC contains portable C implementations of algorithms needed for TLS and common applications. For performance critical algorithms, optimized assembly versions are included for x86 and ARM."Папа, где море?"(c)
"Гляжу в книгу^W код, вижу фигу!"(с)
> вижу фигуhttps://github.com/aws/aws-lc/#algorithm-optimization-support
оптимизированы на асме некоторые алгоритмы для некоторых процессоров и чо ? полная реализация на портабельном С.
> https://github.com/aws/aws-lc/#algorithm-optimization-support
> We ran a set of benchmark scenarios on c7g.metal (Graviton3) and c6i.metal (x86-64)
> We use AWS Graviton processors to test ARMv8 optimizations and Intel CPUs to test x86 and x86-64 optimizations.https://github.com/aws/aws-lc/blob/2034e844e5908b14edff66a4b...
> aesni-gcm-x86_64.Shttps://github.com/aws/aws-lc/blob/2034e844e5908b14edff66a4b...
> aesv8-gcm-armv8.S...
> оптимизированы на асме некоторые алгоритмы для некоторых процессоров и чо ? полная реализация на портабельном С."Папа, где море?" (c)
"... вижу все равно фигу!" (с)
> вижу все равно фигу!раст и есть эпичная фига на данный момент, не исключено конечно что поменяется лет через 10 но это не точно