LINUX.ORG.RU

uutils 0.2.0 и 0.2.2, вариант GNU Coreutils на языке Rust

 , , , ,

uutils 0.2.0 и 0.2.2, вариант GNU Coreutils на языке Rust

1

5

6 сентября опубликован выпуск 0.2.0 проекта uutils coreutils (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia.

Rust Coreutils применяется в дистрибутивах AerynOS (Serpent OS) и Apertis, а также будет задействован по умолчанию в осеннем выпуске Ubuntu 25.10. В отличие от GNU Coreutils реализация на Rust распространяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL. Дополнительно той же командой разработчиков развиваются написанные на Rust аналоги наборов утилит util-linux, diffutils, findutils и procps, а также программ sed и login.

В новой версии Rust Coreutils:

  • Пакет признан полностью готовым для рабочего применения в Ubuntu. Устранены все проблемы, мешавшие переходу Ubuntu по умолчанию на Rust Coreutils.

  • Добавлена поддержка локализации и интернационализации. Введена в строй инфрастурктура для поддержания переводов сообщений на разные языки. Учтены параметры локали при форматировании вывода и начат перевод на разные языки сообщений об ошибках. Для поддержки многоязычности задействована система локализации Fluent, развиваемая Mozilla и используемая в Firefox.

  • Добавлена поддержка Unicode. Символы Unicode, в том числе emoji, теперь могут применяться при обработке содержимого и параметров, например, в качестве разделителей полей: echo "🍔🍟🥤" | cut -d"🍟" -f1.

  • Проведена оптимизация производительности утилит tr, sort и cat. Производительность утилиты tr повышена в 15 раз - ранее данная утилита была медленнее GNU tr в 9.8 раз, а теперь быстрее в 1.58 раза.

  • Улучшена совместимость с эталонным тестовым набором GNU Coreutils, при прохождении которого успешно выполнено 538 тестов (в прошлой версии 522), 52 (65) теста завершилось неудачей, а 27 (31) тест был пропущен.

  • Улучшена совместимость с GNU Coreutils для утилит date, du, fmt, ls и sort.

  • Расширены возможности, устранены проблемы и добавлены недостающие опции для утилит basenc, basename, cat, chmod, chown, cksum, cp, split, date, dd, du, echo, env, expr, factor, fold, hashsum, head, install, ln, logname, ls, mkdir, mkfifo, mktemp, more, mv, nice, nl, od, pr, printf, pwd, realpath, rm, shred, sort, stat, stdbuf, stty, sync, tail, tee, timeout, touch, tr, uname, unexpand, uptime, users и who.

Версия 0.2.2 содержит исправления критических ошибок. Эти исправления обеспечивают безопасное распространение и развёртывание на разных платформах. Разработчики также улучшили производительность base64, сделав её в 1.56 раза быстрее, чем в версии GNU.

>>> Подробности на opennet



Проверено: dataman ()
Последнее исправление: hobbit (всего исправлений: 6)
Ответ на: комментарий от tiinn

Очень странный комментарий. Люди переписывают критически важный код с питона на си совершенно не для того, чтобы упростить дальнейшую поддержку. Это, наоборот, ухудшает дальнейшую поддержку - почему, разговор отдельный.

Люди переписывают код с питона на си только и исключительно для того, чтобы улучшить скорость работы и распределение ресурсов. То есть прямо противоположно тому, о чем вы говорите.

VIT
()
Ответ на: комментарий от rumgot

Если бы все было так просто! Проблемы производительности безусловно связаны с алгоритмом, но дополнительно к самому алгоритму, важным является и реализация алгоритма, и условия выполнения программы, и возможности железа, и вообще много чего. Первая задача специалиста по производительности - определить, что именно является причиной ограничения ожидаемой производительности. А для этого надо хотя бы иметь представление, а что ожидается увидеть. Так что все не так просто, как хотелось бы.

VIT
()

Coreutils, переписанные на Rust внедряют в Ubuntu…

Ждём, когда Линуса торкнет…

PunkPerson
() автор топика
Ответ на: комментарий от VIT

Если бы все было так просто

Ты это «просто» сам увидел и героически опроверг. Разумеется все сравнения проводят на одном и том же железе в одной операционке, чередуя вызовы разных тестов. Если это не очевидно, то мои поздравления, продолжай бороться с мельницами.

rumgot ★★★★★
()
Ответ на: комментарий от sarumeister

Все ж у Zig проблемы в иной плоскости. Не в плоскости оптимизаций и быстроты.

Я не утверждал обратного. Ты сам с собой споришь? Моя мысль, если не получается понять: простое переписывание утилит с C на Rust/Zig ничего принципиально не поменяет в произвдительности. А утилиты из coreutils получили буст не от переписывания самого по себе, а от дополнительно проведенной оптимизации, которую можно было сделать и исхдным версиям на C.

Я хз, за каким бесом ты еще Zig преплел.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от rumgot

Вообще неочевидно. В расте при небольших усилиях можно получить код, который легко векторизуется компилятором, и даже ансейфа не потребуется. В си семантика языка часто не даёт провести аналогичные оптимизации.

unC0Rr ★★★★★
()
Ответ на: комментарий от anc

Выше писали, что есть два варианта - либо один бинарь (по типу busybox), либо каждая тулза в своем бинарнике. Один бинарь компилить гораздо быстрее, поэтому я для тестов установил себе именно его.

provaton ★★★★★
()
Ответ на: комментарий от sena

умение загрузить ядра ЦПУ - это фича, а не баг. Программу, которая грузит все ядра, можно запинить на одно ядро, можно поставить найс, чтоб понизить приоритет в шедулинге. Вариантов куча. Но если программа не умеет эффективно юзать железо, то ты уже сторонними средствами ее никак не ускоришь.

provaton ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Я заранил стандартный релиз билд, который там из коробки. Он динамически залинкован с глибц, так что статический musl тут никак не поможет. Можно было бы поиграться с флагами компилятора, но у меня есть более интересные варианты вечернего времяпровождения)

provaton ★★★★★
()
Ответ на: комментарий от unC0Rr

Часто не даёт, а часто даёт. И в итоге нам показывают разницу в бенчмарках между языками в пределах 1% (при том, что в разных тестах разные языки лидируют), тогда как в теме упоминается разница в 15раз. Стопудово исключительно переход на раст повлиял, и больше ничего.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от dunmaksim

С ним то все так, просто нытья-то сколько было?

Zlogene ★★
()
Ответ на: комментарий от provaton

Это проблема

Это возможность... ;P

«Это не баг, это фича!» © :))))

Somebody ★★★
()
Ответ на: комментарий от rumgot

простое переписывание утилит с C на Rust/Zig ничего принципиально не поменяет в произвдительности

Почему здесь раст и зиг через слэш? Переписывание на первый не будет быстрее кода на Си, пока не рассуешь unsafe тут и там. Второй сразу из коробки быстрее кода на Си (оптимизации llvm vs gcc; комптайм, статическая линковка, struct of arrays, хитрые аллокаторы).

Однако не советую бросаться переписывать утилиты с С на Zig, там буквально месяц назад опять все поломали в пользу бесцветного async.

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 2)
Ответ на: комментарий от tiinn

Повторяется история с Devuan: нитакуськи придумали сами себе проблем, не будем переходить на systemd, говорят, будем без него.

Была даже шутка что Devuan разрабатывают по методике BDD: Butthurt Driven Development.

Сейчас тут то же самое происходит: не будем с C на Rust переписывать, не будем уже переписанное использовать, сейчас мы вам покажем как на C безопасно писать.

пишет свой Hello World портит структуры ядра получает kernel panic

Зато не Rust, зато не Rust! Там unsafe! Там боровы! Там сложный синтаксис! А там! А там! А там! Нельзя указатели складывать, вычитать и умножать! Нет 254 функций копирования строки!

dunmaksim
()
Ответ на: комментарий от rumgot

Концептуально проблемы производительности софта при сравнении двух компилируемых языков возникают из-за неоптимальных алгоритмов.

Если бы было так, производительность софта на Си никак не зависела бы от версии и ключей компилятора, ведь один и тот же исходник очевидно реализует один и тот же алгоритм. Однако зависит, причём на порядки.

monk ★★★★★
()
Ответ на: комментарий от monk

Да нет там никаких порядков. 90% софта практически не зависит от ключей компилятора. И от версии не зависит.

tiinn ★★★★★
()
Ответ на: комментарий от tiinn

Предлагаешь компилировать всё с -O0? Надёжней ведь будет, а скорость, по-твоему, практически не изменится.

monk ★★★★★
()
Ответ на: комментарий от GAMer

Собери софт с -O0 и -O2 и посмотри, в чем разница машинного кода. Там как раз набегает «в разы».

А вообще в целом - тормозит не программа целиком, а несколько конкретных горячих точек. Для повышения скорости достаточно оптимизировать их. Холодные части ПО не оказывают заметного влияния на производительность.

wandrien ★★★
()
Ответ на: комментарий от monk

я вообще ключей не знаю, всё с дефолтом компилирую, меня всё устраивает.

tiinn ★★★★★
()
Ответ на: комментарий от tiinn

Вот хороший пример:

https://habr.com/ru/articles/647165/

Без изменения алгоритма, только изменяя типы переменных и положение функций в файлах, время выполнения снижается с 223 секунд до 7. Полтора порядка. И это сравнивается оптимизированная версия с оптимизированной.

monk ★★★★★
()
Ответ на: комментарий от monk

О, да, на специально подготовленных примерах это так и будет работать. А на 90% обычного ПО - нет.

tiinn ★★★★★
()
Ответ на: комментарий от VIT

Нет, ты пытаешься подчеркнуть некую свое превосходство используя снисхождение. Причём получается только в собственных глазах.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от GAMer

В разы, это тоже как-то подозрительно. Чем такое объяснить? Векторизацией?

Начиная с того, что при O0 каждое состояние памяти программы должно быть устойчиво и восстановимо. Это требование родилось, когда строилась формальная теория компиляции и к вопросам корректности относились с математической точки зрения. Во что выливается такой подход? Ну например в то, что когда ты пишешь

for ( int i=0; i>N; i++ )

переменная i хранится в памяти и каждый раз, когда ты к ней обращаешься - генерируется memory load, а при модификации - memory store. Оптимизирующий компилятор такие переменные обычно кладет в регистры. А ещё существуют архитектуры, например IBM Power, которые позволяют организовать цикл вообще без переменной.

Векторизация при формальной корректности вообще запрещена как неопределенная. Вот и считай эффект от оптимизации. В разы? Да в сотни раз легко. В разы я получаю ускорение простой правкой ассемблера исправляя косяки компилятора.

VIT
()
Ответ на: комментарий от rumgot

Просто перечитай вдумчиво

Бывает так, что человеку показываешь 50%, а он видит 1%. На ютубе синтетический тест deno vs. node.js vs. bun — как раз про 50%.

sarumeister
()
Ответ на: комментарий от sarumeister

Перечитай и озвучь тезис, с которым ты споришь. Серьёзно. Ты не понимаешь, с чем ты споришь.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

Занялись оптимизацией - буст x15.

Но согласись, код на Си оч не оч. Иногда хочется простых обычных ссылок вместо указателей.

sarumeister
()
Ответ на: комментарий от sarumeister

Разумеется да. Но меня коробит, что постоянно выходят очередные убийцы и что-то начинают на них переписывать. При этом новые языки решают какие-то проблемы, а какие-то привносят. А разработчики теперь при желании сменить работу вынуждены прыгать с языка на язык. Или знать сразу несколько. Как например с позициями на Rust, там как правило нужны также знания C и C++. Или чудо изобретение от Qt под названием Qml: теперь на позицию C++ десктоп разработчика нужно знать C++/Js/Qml кайф.

rumgot ★★★★★
()

А зачем это нужно?

Я понимаю, кто-то захотел практики, но плеер, редактор или змейку не осилили.

Но почему это приняло такой серьезный оборот?

Не запилить ли в таком случае дистрибутив из рандомных github реп? А лучше билдить случайный образ из таких реп при каждом скачивании.

water_closed
()
Ответ на: комментарий от provaton

умение загрузить ядра ЦПУ - это фича, а не баг. Программу, которая грузит все ядра, можно запинить на одно ядро, можно поставить найс, чтоб понизить приоритет в шедулинге. Вариантов куча. Но если программа не умеет эффективно юзать железо, то ты уже сторонними средствами ее никак не ускоришь.

Умение загрузить все ядра вместо одного может быть полезным. Но если программа загружает 16 ядер вместо одного и при этом ускоряет работу всего лишь в полтора раза по сравнению с программой, которая загружает одно ядро, то эффективность на стороне однопоточника.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.