StringZilla 3.8.1

Languages
C++ 60.6%
C 21.5%

И да будет ***ч!

Однако, функциональность не одинакова для всех языков.

С этого места поподробнее, дискриминируете китайцев или японцев?

Разве не очень видно, что речь о языках программирования?

SIMD- и SWAR-

Я даже посмотрел непонятное второе слово в википедии, оказалось что в контексте х86 эти два слова - синонимы, а архитектуру где SIMD без регистров (т.е. не SWAR) ещё надо поискать.

Разве непонятно, что именно эта неоднозначность топикстартового текста и сподвигла меня на написание комментария? Ведь не ясно, поддерживаются ли только двухбайтные символы для китая, или эмоджи для японии поддерживаются тоже, то есть символы четырёхбайтные.

сподвигла меня

Зря. Иногда лучше лежать.

Нет там никакой неоднозначности. Допускаю, что она может появиться для тех кто по-русски нативно не читает.

И да будет ***ч!

Rust 4.1%

Без этого не выйдет.

Разве не очень видно, что речь о языках программирования?

Без просмотра репы - не очевидно, поскольку строковые операции с юникодными алфавитами содержащими модификаторы - вот прям очень сильно разные как по скорости, так и по результатам, Кстати как там со сравнением таких строк?

Без просмотра репы - не очевидно

Тогда встречный вопрос: что такое функциональность и биндинги человеческих языков? :)

Кстати как там со сравнением таких строк?

Не разбирался.

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

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

сишники тут? вот так зачем делать:

sz_string_view_t haystack = {your_text, your_text_length};
sz_string_view_t needle = {your_subtext, your_subtext_length};

// Perform string-level operations
sz_size_t substring_position = sz_find(haystack.start, haystack.length, needle.start, needle.length);

были перечислены и отработаны до перечисления

Этот текст очень плохо написан.

я не могу принять решения о том, использовать ли мне библиотеку

Это хорошо. Чем меньше таких пользователей у библиотеки, тем спокойнее будет её автору.

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

Ну я вот ХЗ как расстояние левенштейна для иероглифов считать. Точнее какой в этом смысл и учитывая то как это кодируется в юникоде с этим ещё и технические трудности.

А что не нравится то? Не понял. sz_string_view_t, sz_size_t, sz_find это всё какие-то внутренние абстракции этой библиотеки. Ну нет в сишке ООП нормального вот и извращается как может.

расстояние Левенштейна, расстояние Хэмминга

До кучи: https://github.com/rapidfuzz/rapidfuzz-cpp.
Тоже SIMD, но алгоритмов побольше.

sz_string_view_t haystack = {your_text, your_text_length};

Дедушка Вирт был прав во всём!

Тогда встречный вопрос: что такое функциональность и биндинги человеческих языков? :)

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

Суть в том, что «ну вот спасибо на#уй!» спецификациям юникода, что некоторые символы могут собираться из двух и более юникодных последовательностей. Нпример буква «Й» может быть передана одним юникодным символом, а может быть передана юникодным символом «И» и еще одним юникодным символом который добавляет верхний умлаут, человек конечно такое не набуйвертит (трезвый), а вот библиотеки распознавания - запросто. А что касается нефонетических иероглифических языков (кантонский например) - это вообще ад и израил. Поэтому все кто работает с текстовой инфой всегда возбуждаются на такие вопросы.

Я не программист, но неужели за столько времени нельзя было всунуть нормальные функции\операторы в С\С++?

Добавлять что-то новое в сишечку? Да тебя как еретика сожгут на костре.

В плюсишечку чего только не добавили уже

Туда периодически что-то добавляют https://www.iso-9899.info/wiki/The_Standard

Предполагаю, что windows10 под «нормальными» имел в виду более оптимизированные реализации, а не стандарт.

Так я про плюсы и не говорил.

Насколько помню, последние нововведения были в c11, а c17 он про фиксы, а не фичи.

Биндинги к этому предложению не имеют отношения

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

Что именно? Обычный код, разве что просматривается с++-ная манера вызывать какие-то функции в объявлениях.

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

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

Я не про нравится/нет, просто интересно, зачем раскрывать структуру при передаче в функцию и про копирование, передать указатель вроде как выглядит логичнее.

Причин может быть несколько:

1) если передать по указателю - то до полей структуры будет сложнее добираться, как в синтаксисе исходника, так и в машинном коде, а компилятору, возможно, будет сложнее это оптимизировать

2) возможно, вызываемая функция для удобства не должна знать структуру sz_string_view_t и должна работать с простыми типами, например потому что она должна принимать и rvalue тоже

3) контекст кода не видел, но возможно там надо передать именно по значению

Вопросы про «почему раскрывать» и «почему копировать» я объединил, потому что, несмотря на то что современный gcc вроде умеет передавать структуры больше машинного слова по значению, так делать не принято - это запутывает логику работы и программы и компилятора.

Добавлять что-то новое в сишечку? Да тебя как еретика сожгут на костре.

В C99 добавили <stdbool.h>. Никого не сожгли, пользуюсь, нравится. Понятно, что это синтаксический сахар, но читаемость и однозначность выше, это уже хорошо.

Если верить Википедии то SWAR это SIMD не требующий специальных регистров, т.е. умеющий работать с general purpose. Насколько я понимаю ранние векторные процессоры под это не попадали.

Не знаю откуда ты это взял. В статье про SWAR, на которую есть ссылка из стартового сообщения, прямым текстом написано, что pentium mmx под те критерии попадает. И это первый х86 проц, в котором были инструкции для параллельной обработки данных.

Может быть, в начале 90-х и в более древние времена и были процы (не х86) которые simd но не «swar», но упоминать об этих подробностях спустя 30+ лет как-то странно.

в контексте х86 эти два слова - синонимы

Нет. SIMD != packed SIMD.

Смысл этого сообщения от меня ускользает, пояснишь подробнее что тут имеется ввиду?

SIMD это возможность одной инструкцией провести параллельно несколько одинаковых математических операций над рядом расположенными наборами данных и записать рядом ответы (если они есть).

SIMD это возможность одной инструкцией провести параллельно несколько … операций

Да. А SWAR – над упакованными. Например: http://0x80.pl/notesen/2016-01-06-swar-swap-case.html

«Упакованные» всегда про simd говорят, это не какое-то особенное свойство и особого смысла это слово в применении к simd не несёт. Единственное что я там заметил - это то, что для simd-операций используется не специальная simd-инструкция, а инструкция общего назначения, которая по случайности оказалась simd-совместимой (точнее, таковыми являются все побитовые операции - and, or, xor, not, а при дополнительных допущениях о данных можно и арифметику со сдвигами туда прицепить).

Дело в этом? Если да, то никто такое никакими специальными аббревиатурами вообще не называет, это просто «оптимизированный алгоритм». Для strlen в libc давным давно такой например.

никто такое никакими специальными аббревиатурами вообще не называет

Daniel Lemire: https://lemire.me/blog/2022/01/21/swar-explained-parsing-eight-digits/

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

Ну да, автор simdjson, simdutf и т.д. – теоретик, конечно.

Вроде как все sse кроме 4 попадают. 4 либо отсутствовала на момент написания либо не swar

И возможно что тут имеется ввиду не архитектура а характеристика алгоритмов. Насколько я понимаю simd может пользовать и только «свои» регистры

Из README

«Levenshtein and Hamming edit distance are provided for both byte-strings and UTF-8 strings. The latter will output the distance in Unicode code points, not bytes.»

см. https://en.wikipedia.org/wiki/Code_point#In_Unicode

То что технически оно работает не значит что в случае иероглифов в этом много практического смысла.

Все интереснее. С одной стороны таки

https://direct.mit.edu/coli/article/37/4/689/2128/Levenshtein-Distances-Fail-to-Identify-Language

С другой

https://dl.acm.org/doi/pdf/10.5555/1620754.1620782

Подход модифицируется.