> у меня достаточно знаний что бы увидеть почему реализация на расте опередила на чуть чуть реализацию на СИ
> и как сольет раст если из реализации на СИ это устранитьПочему же?
У меня нет желания копаться в коде и профайлить его, тем более что у меня есть generic объяснение: это работа оптимизатора. Меньше десяти процентов производительности, на фоне нескольких вариантов C'шной реализации -- это стопудов работа оптимизатора, C просто упёрся в невозможность оптимизировать некоторые вещи, в силу того что он позволяет слишком много свобод программисту. Искусственный интеллект оптимизатора недостаточно интеллект, чтобы сообразить некоторые вещи, а программист недостаточно искусно владеет C, для того, чтобы эти вещи выразить в коде в виде понятном для оптимизатора.
Строгость rust'а позволяет иногда оптимизатору оптимизировать лучше. Или программисту меньше парится о возможных ошибках, потому как они невозможны. Тут ярким примером может служить utf8 строка: rust валидирует эти строки на входе, что с одной стороны замедляет, например, работу BufReader::read_line, но с другой стороны позволяет затем работать со строкой исходя из предположения, что мы имеем дело с валидным utf8, не добавляя в код условных переходов на случай невалидного utf8, и таким образом делая быстрее любой код итерирующий по символам. То есть вместо того, чтобы при каждом проходе по строке производить валидацию параллельно, мы делаем её один раз. И это может проявлятся не только в случае utf8 строк, но и в случае, например, указателей, потому что компилятор rust'а И программист, полагаются на то, что эти указатели ненулевые, в то время как C'шный код вынужден постоянно держать в уме возможность для любого указателя быть нулевым.
Это, кстати, создаёт impedance mismatch на границе между rust'овым кодом и C'шным, потому что получая, например, строку из C'шного кода (то есть char*), мы должны проверить не NULL ли он, проверить валидность этой строки (потому что C запросто может жонглировать невалидными utf8 строками), и только после этого начинать какую-то осмысленную работу с этой строкой (это ещё если не придётся упереться в вопросы lifetime'ов, и не придётся рубить эти проблемы как гордиев узел посредством растового аналога strdup, хотя подобные проблемы, наверное, и в грамотном C'шном коде будет решаться так же, в rust'е они просто ярче проявляются и их сложнее не заметить). Но это я отвлёкся от темы.
Помимо этого может сказываться большая выразительность языка. Например, rust для итерации позволяет использовать не только циклы, но и итераторы с их функционалами, типа map и reduce, которые гораздо удобнее оптимизатору для понимания происходящего, и более того ограничивают программиста загоняя его в узкие рамки, и вынуждая писать код, который легко векторизовать.
Но это всё теоретические сопли, рассуждения из общих соображений. И я бы с радостью посмотрел бы на подробное сравнение C'шного кода и Rust'ового, чтобы с профайлером, ассемблерными дампами и прочими атрибутами, которое бы либо подтвердило мои общие соображения, либо опровергло бы их, дав альтернативное объяснение, которое лучше отражает реальность. Но сам я не готов лезть и тратить час, два или полдня на это.
