Кілька нових утиліт написаних на rust

[Володимир Лісівка]

Основна перевага нових утиліт командного рядка, написаних на rust, — це осучаснений, зручніший інтерфейс та значно вища швидкість роботи порівняно з програмами на Сі.

• ripgrep — заміна grep -E. За замовчуванням, рекурсивно шукає у файлах вказаний текст. По тестам, до 5-ти раз швидший ніж grep.
• fd-find — заміна find. За замовчуванням, рекурсивно шукає вказаний текст у назвах файлах. Приблизно у 5-ть раз швидший ніж find.
• exa — заміна ls. Має зручніший кольоровий вивід.

Якщо утиліти відсутні у вашому дистрибутиві, то встановити їх можна командою  cargo install ripgrep exa fd-find .

[Cthulhu]

значно вища швидкість роботи порівняно з програмами на Сі.

Як на мене це трошки пересмикування, ось слова самого автора (наскільки я розумію) - "I'm willing to bet you've got some big binary files in that directory that ripgrep is skipping but that grep isn't." До мови це має стосунок ортогональний, до імплементації - найпряміший. А от бенчмарок я так і не знайшов.

Якщо утиліти відсутні у вашому дистрибутиві, то встановити їх можна командою  cargo install ripgrep exa fd-find .

І легким рухом "make install" ваша система перетворюється на слаку!..  В арчі, до речі, ripgrep і exa є в community:

Код: [Вибрати]

community/ripgrep 0.7.1-1
    A search tool that combines the usability of ag with the raw speed of grep
community/exa 0.8.0-1
    ls replacement

[Володимир Лісівка]

значно вища швидкість роботи порівняно з програмами на Сі.

Як на мене це трошки пересмикування, ось слова самого автора (наскільки я розумію) - "I'm willing to bet you've got some big binary files in that directory that ripgrep is skipping but that grep isn't." До мови це має стосунок ортогональний, до імплементації - найпряміший. А от бенчмарок я так і не знайшов.

Мені не треба щоб grep шукав по двійковим файлам, тільки по текстовим, так що це фіча а не бага.

Якщо утиліти відсутні у вашому дистрибутиві, то встановити їх можна командою  cargo install ripgrep exa fd-find .

І легким рухом "make install" ваша система перетворюється на слаку!..  В арчі, до речі, ripgrep і exa є в community:

Не перетворюється, бо cargo ставить бінарники у ~/.cargo/bin, який треба додати в PATH, або у вказаний каталог. Навіть під рутом він не ставить у /usr/bin чи /usr/local/bin .

[Cthulhu]

Мені не треба щоб grep шукав по двійковим файлам, тільки по текстовим, так що це фіча а не бага.

Мені треба, надто вже часто це виявляється корисним Правда, там інколи дивна логіка, тому часом пошук по бінарях таки треба форсувати з "grep -a" - тобто імплементація справді могла б бути кращою.

Не перетворюється, бо cargo ставить бінарники у ~/.cargo/bin, який треба додати в PATH, або у вказаний каталог. Навіть під рутом він не ставить у /usr/bin чи /usr/local/bin .

Тоді ой, не знав про деталі.

[Re.]

Це ті, що в Redox OS? І чому вони там саме в пʼять раз швидші? Бо пʼять ядер в розробника на машині?

[Cthulhu]

Поставив і трошки потестував. exa файний і кольоровенький, поні схвалюють, замінив alias ll. rg дуже прикольний і таки значно читабельніший за grep для ручного пошуку - звісно, цілковито не потрібен в скриптах. Перформанс не міряв, підозрюю, в середньому майже ідентичний. Один словом, дякую, Володимире, воно таки гарне.

Off-topic:

Якби у новині не було таких дуже підозрілих тверджень, чорта з два я б поліз їх ставити та до них дивитись. Психологія 

[DalekiyObriy]

нарешті дійшли руки спробувати: я часто шукаю фрази в архівах текстів: це десь 20 текстових файлів, разом 250 млн слів (4,7 Гб)

time ./find_with_rg.sh Порошенк.* | wc -l
14834

real    0m0.268s
user    0m0.289s
sys     0m0.823s

time ./find_with_grep.sh Порошенк.* | wc -l
14834

real    0m9.230s
user    0m8.856s
sys     0m0.363s

(i7 - 8 логічних ядер)

чесно кажучи, різниця вражає

[Cthulhu]

нарешті дійшли руки спробувати: я часто шукаю фрази в архівах текстів: це десь 20 текстових файлів, разом 250 млн слів (4,7 Гб)

O_o

Трясця, по чому ви шукаєте? Я був запустив в себе по робочій директорії, де здебільшого ASCII текст і пару бінарів - як grep десь десять хвилин ковбасив, так і rg.

[Cthulhu]

Off-topic:

А під Cygwin воно є?

[Володимир Лісівка]

Це ті, що в Redox OS? І чому вони там саме в пʼять раз швидші? Бо пʼять ядер в розробника на машині?

Не знаю чому швидше — напевно краще написали, плюст rust любить підставляти функції, через що код розбухає в кілька разів, але працює швидше. До того ж там простіший автомат регулярних виразів ніж у grep, тому він багато чого не вміє.

Ще rg автоматично пропускає файли в .git та файли з .gitignore, що допомагає при пошуку по коду.

[Cthulhu]

напевно краще написали

Та 100%. Прямі руки і світла голова автора.

[Володимир Лісівка]

Off-topic:

А під Cygwin воно є?

Трохи танців з бубном, і fd-find та ripgrep під mingw скомпілювалися і навіть запускаються під wine. exa не компілюється бо вона заточена під юнікс.

Закинути кудись двійкові файли чи розказати як компілювати з під Федори?

[DalekiyObriy]

нарешті дійшли руки спробувати: я часто шукаю фрази в архівах текстів: це десь 20 текстових файлів, разом 250 млн слів (4,7 Гб)

O_o

Трясця, по чому ви шукаєте? Я був запустив в себе по робочій директорії, де здебільшого ASCII текст і пару бінарів - як grep десь десять хвилин ковбасив, так і rg.

ну я підозрюю тут є декілька факторів: відношення кількості файлів до їх розміру, також кількості файлів до кількості ядер, типи файлів, чи диск ssd тощо, можливо у вас більшість часу обидві утиліти витрачають у sys а не user

[Khariton]

А чи може хтось порівняти швидкість з "grep -P". Бажано з складними регекспами.
Бо egrep повільніший за перловий. Колись читав тестування на опеннет(чи що?)

Цікаво? а прискорення не пов'язане з використанням всіх ядер? бажано переглянути під час тустування, що там з ядрами в цей час коїться?
Схоже що багатоядерність використовує, бо у протестованного резульатата отаке:
real    0m0.268s
user    0m0.289s
sys     0m0.823s
взагалі real повинно бути більше або рівне user + sys. А тут навпаки. Отже воно скоріш за все використовує threads.

[DalekiyObriy]

https://github.com/BurntSushi/ripgrep

It uses a lock-free parallel recursive directory iterator, courtesy of crossbeam and ignore.