Комментарии 11
Варианта "другое" не хватает в опросе. У меня StringZilla живёт, в общем не жалуюсь. Правда не .net, а LabVIEW и Раст. А вот то, что у i9-10900KF нет аппаратного AVX512 — не знал, надо будет побенчмаркать на досуге, если до такого камушка доберусь.
Вы сравнивает производительность процессора 5.3 ГГц avx2 и 3.4 ГГц avx-512 на двух разных процессорах с разным кешем и удивляетесь тому что вторые медленнее?
Спасибо за коммент, тут и я частично не прав, не все учел и вышло не очень.
Я только отметил, что первая причина частота, а не ширина регистра. Кеш тут вообще ни при чём ведь 64 килобайта целиком сидят в L1/L2 на обеих машинах.
Частота объясняет большую часть разрыва, но не весь, тут понятно. Десктоп на такт кинет порядка 22 байт, но ксеон порядка 13 — а потому он медленнее даже с поправкой на гигагерцы, и не забываю про вдвое широкие регистры, конечно.
Остаток — задержки масочных сравнений AVX-512 (vpcmpeqw в k-регистр + kortest).
Для чистоты прогоню на том же ксеоне с DOTNET_PreferredVectorBitWidth=256 — машина та же, кеш тот же, меняется только ширина вектора. Цифры добавлю чуть позже.
А зачем вообще в строке искать символ через IndexOf, сразу сделать s.AsSpan().IndexOf(с)
А незачем — это одно и то же. IndexOf(char) в исходниках это одна строчка: SpanHelpers.IndexOfChar(ref _firstChar, value, Length), цитата из String.Searching.cs есть в статье. AsSpan().IndexOf(c) приходит в тот же SpanHelpers, машинный код идентичный, разница ноль. AsSpan даёт выигрыш только на перегрузке со строкой, а там дефолт CurrentCulture, а спан ординал. Но о таком я отдельно писал и решение — указать StringComparison.Ordinal.
Отличная серия, спасибо.
...эту ещё не читал, но одобряю ;)
Очень хорошая серия статей.
Примите мои восхищения)
ни у Zen 3, ни у Comet Lake аппаратного AVX-512 нет
Вне dotnet, но при тормозах на фронт-энде как раз могут быть быстрее, чем 1:1 с поправкой на ширину SIMD. Где-то такой результат теста видел.

Бенчмаркая поиск по строке: самописные циклы проигрывают от ×14 до ×154