gо
ripgrep быстрее grep не потому, что Rust быстрее C, а потому что многопоточный код с mmap'ами на C нормально написать настолько сложно, что до этого ни у кого не дошли руки
Size: a a a
2021 June 19
gо
если ты сидишь и медитируешь над каждой строчкой по сто лет, то ты можешь написать на C такой же быстрый код, как на Rust
gо
но код, который ты просто сел и написал, на Rust легко может оказаться быстрее, потому что Rust делает написание производительного кода проще
C
Спасибо за разъяснение. Следует ли из этого, что на любом компилируемом языке программирования, можно написать код близкий к скорости исполнения с таковым на Ассемблере?
gо
на любом компилируемом языке без GC плюс-минус ещё какие-нибудь ограничения
gо
C, C++, Zig, Rust, ZZ — можно получить примерно одинаковую скорость, и примерно максимальную
gо
руками ассемблер писать это вообще обычно плохая идея, потому что ассемблер компиляторы давно пишут в среднем лучше, чем люди
C
Спасибо за уточнение!
gо
надо также понимать, что «быстрее» зависит от задачи. чудовищно медленный сам по себе эрланг может быть «быстрее» в задаче, требующей массивной конкурентности, потому что он под это подстроен, а на другом языке для этого придётся писать ещё один эрланг.
11
множество людей, которые могут на ассемблере обогнать современный компилятор, практически не пересекается со множеством тех, кто об этом рассуждает. чаще всего результатом прямого переписывания на асме бывает просадка в скорости раза в полтора-два.
gо
SIMD до сих пор пишется без пяти минут на ассемблере
gо
только что регистры сам не аллоцируешь
11
что всё-таки заметная часть геморроя
gо
хотя во многих случаях «убедить компилятор засимдить код» может быть проще и эффективнее, чем вручную это сделать.
gо
тут, опять же, плюс Rust — он довольно много знает про твой код, так что автовекторизацию делает охотно.
C
Я бы наверное и не задался таким вопросом, продолжая рукожопить на Python и JS (которые я начинал изучать методом тыка в готовые примеры), пока не столкнулся с чудовищно медленным Nfqueue
gо
в C, например, нет деструкторов, поэтому стандартный паттерн работы с типами, которые нужно уничтожать специальным образом — сделать функцию, которая делает маллок + отдаёт PIMPL, и другую, которая выполняет кастомную логику уничтожения и делает free. Можно заметить, что это обязательно включает в себя аллокацию.
gо
если ты не делаешь аллокацию на своей стороне, то её должен сделать клиент твоей библиотеки, а для этого он должен знать размер твоего типа. что обычно нежелательно, потому что на него кто-нибудь завяжется и ты не сможешь его поменять потом.
gо
в Rust есть деструкторы, и ещё приватные поля, и ещё не принято работать с чужими структурами как с байтами — поэтому необходимости в этом паттерне нет и аллокаций становится меньше.
несмотря на то, что технически C может делать то же самое.
несмотря на то, что технически C может делать то же самое.
C
Спасибо🙏