Ускоряем Node.js с помощью Rust

Синтетический пример:

extern fn foo(input: &T);

fn bar(input: &T) { ... }

fn baz(input: &T) {
    foo(input);
    bar(input);
    foo(input);
}

Здесь в коде есть одна внешняя функция с неопределенным контрактом и две внутренние которые пользуются ссылкой на T.

В Rust если функция принимает &T это значит, что объект на момент выполнения является замороженным и гарантировано не будет меняться где-то еще. Поэтому оптимизатор может с чистой совестью один раз прочитать значение из памяти и положить его в регистр (если это выгоднее и не создаст нежелательного register pressure).

Функция bar() сможет быть заинлайнена внутрь baz() и пользоваться тем же значением из регистра, потому что компилятор может быть уверен, что input случайно не поменяется (interior mutability — отдельная история). То есть компилятору тут даже escape анализ проводить не нужно, чтобы это понять.

Разумеется в C++ все сильно сложнее и в общем случае const T& не является достаточным основанием для подобных оптимизаций. Алиасинг указателей вообще больная тема.

Я веду к тому, что Rust, в отличие от C++, может грамотно распорядиться своей системой типов и инвариантами, которые из нее можно вывести.

А может и не распорядиться и работать с трайтами, как с таблицей виртуальных функций, а так же выполнять все bound checks и возвращать через Result пользовательские enum-ы размером в сотни байт, при этом ничуть не избавляясь от цепочки if-ов, которые спрятаны за синтаксическим сахаром try! и?..

Зачем вы увиливаете от ответа?

Ответ вам был дан. Почему вы не можете его прочитать и понять?

Я вас спрашиваю, какая реализация сортировки в общем случае используется в С?

Тогда позвольте вас спросить: мы будем под общий случай выдавать конкретную ситуацию? Тогда давайте посмотрим на такой вот «общий» случай:

void f(char * b, size_t i) { b[i] = 0; }

Значения b и i определяются в run-time, заранее они не известны.

Ну и, видимо, нужно более четко обозначить свою точку зрения, ибо очевидно, что для местных комментаторов она не очевидна:

— в Rust-е не так уж много особенностей, которые бы не позволили компилятору Rust-а сгенерировать такой же эффективный код, как и компилятору C. Одна особенность — это включенный по умолчанию bounds checking, вторая — это генерация таблиц для обработки panic (хотя это лишь косвенное влияние оказывает). А так, в принципе, у компилятора Rust-а достаточно информации, чтобы сгенерировать даже более оптимальный код;
— однако, производительность кода будет определяться не столько возможностями компилятора, сколько программистом. Rust является языком более высокого уровня, позволяет решать более сложные задачи, что дает возможность разработчику использовать более высокие уровни абстракции. Чем выше, тем меньше внимания уделяется тому, что внизу, откуда и проявляется некоторый проигрыш в производительности/ресурсоемкости по сравнению с более низкоуровневыми языками. Это не уникально для Rust-а, это уже проходилось, на моей памяти, как минимум с Ada, Eiffel и C++ (если говорить про то, что транслируется в нативный код);
— под общий случай лучше брать не какой-то микробенчмарк и уж тем более не часть микробенчмарка (вроде упомянутой вами сортировки), а решение какой-то большой задачи. Например, реализация MQ-шного брокера (хоть MQTT-брокера, хоть AMQP) или сервера СУБД. На таком объеме языки более высокого уровня сильно выигрывают в трудозатратах, качестве и надежности, но на какие-то проценты проигрывают в производительности тому же C (причины см. в предыдущем пункте). Если не верите, попробуйте пообщаться с разработчиками PostgreSQL или Tarantool-а.