The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Для ядра Linux предложена реализация функции memchr, работающая до 4 раз быстрее

12.07.2022 09:10

Для включения в состав ядра Linux предложен набор патчей с оптимизированной реализацией функции memchr(), применяемой для поиска символа в массиве. В отличие от старого варианта, в котором применялось побайтовое сравнение, предложенная реализация построена с учётом полного использования 64- и 32-разрядных регистров CPU. Вместо байтов сравнение осуществляется с использованием машинных слов, что позволяет за раз сравнивать как минимум 4 байта.

При поиске в больших строках новый вариант оказался быстрее старого примерно в 4 раза (например, для строк в 1000 символов). Для строк небольшого размера эффективность новой реализации не столь значительна, но всё равно выше по сравнению с исходным вариантом. В ядре Linux размер обрабатываемых в memchr() строк достигает 512 байт. Прирост производительности для 512 байтовых строк, в ситуации, когда искомый символ находится в конце строки, составляет 20%.

Тестирование ядра 5.18 с новым вариантом "memchr()" для 32- и 64-разрядных архитектур не выявило каких-либо проблем. Общий прирост производительности подсистем ядра при использовании оптимизированного варианта "memchr()" пока не оценивался, как не анализировалась и целесообразность замены реализации (в коде ядра вызов функции memchr() встречается 129 раз, в том числе в коде драйверов и файловых систем).

  1. Главная ссылка к новости (https://www.phoronix.com/scan....)
  2. OpenNews: В состав Glibc включено исправление уязвимости в memcpy, подготовленное разработчиками ОС Аврора
  3. OpenNews: Критическая уязвимость в реализации функции memcpy для ARMv7 из состава Glibc
  4. OpenNews: Линус Торвальдс опроверг проблемы с планировщиком задач, всплывшие в тесте производительности
  5. OpenNews: Опубликованы результаты тестов производительности файловой системы Reiser5
  6. OpenNews: Сравнение производительности различных реализаций WebAssembly
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57493-kernel
Ключевые слова: kernel, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (162) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:26, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Я думал и так уже оптимизировали все что можно для 64бит
     
     
  • 2.8, n00by (ok), 10:06, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Оно и оптимизировано уже более 10 лет. Называется аппаратная предвыборка данных (prefetch). Почему заявивший "The optimized "memchr()" is nearly 4x faster than the original one for long strings" не знает, что на больших блоках узким местом является скорость чтения из памяти - это другой вопрос.
     
     
  • 3.10, _hide_ (ok), 10:11, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Вы немного ошибаетесь. Никакие prefetch и прочие не избавят числодробилку от побайтового перебора. Ну да, память надо прочитать и загнать в кэш, но никто не говорит, что ядро стало работать в 4 раза быстрее, просто -1 узкий момент.
     
     
  • 4.14, n00by (ok), 10:24, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ещё я немного смотрю, чего оно там числодробит:

    nl = memchr(line, '\n', end - buffer);

     
  • 4.158, Аноним (158), 02:09, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сразу видно человека не разбирающегося в теме
     
  • 3.29, Аноним (-), 12:51, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда-то давно сравнивал свою реализацию strlen (это почти memchr, только чуть другой)

    Побайтовый наивный алгоритм проиграл по скорости около 4 раз 8-байтовому. Еще написал не совсем правильный sse-алгоритм, он еще в 1.5-2 раза быстрее.

    Это к разговору про скорость подсистемы памяти.

     
     
  • 4.35, n00by (ok), 13:13, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    То есть не догадались посчитать теоретический предел чтения из памяти и сравнить с ним результаты измерений? Это к разговору об измерениях. Про год и тип процессора не спрашиваю, как и про использование команды prefetchnta.
     
  • 3.48, Аноним (48), 14:34, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Называется аппаратная предвыборка данных (prefetch).

    А в Эльбрусах, Итаниках и прочих VLIW такой есть?

     
     
  • 4.54, n00by (ok), 14:49, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Попробуйте дочитать моё сообщение до конца - там вся суть. Что касается вопроса, если нет аппаратной предвыборки - можно обеспечить программную, как делали раньше на IA32. Для этого есть либо специальная команда, либо читают память с шагом равным размеру линейки кеша.

     
  • 3.89, Аноним (-), 03:25, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Называется аппаратная предвыборка данных (prefetch).

    Интересно, а как предвыборка может изменить тот факт что телепать по 1 байту за раз вместо 4 означает в 4 раза больше инструкций на это самое? Инструкции все моментально чтоли выполняются, такты не занимают? Без предвыборки вы еще и память бонусом к этому дофигища подождете. И там упоминабтся строки до 512 байтов, чтоли. Это наверное не настолько ужасно?

     
     
  • 4.92, n00by (ok), 09:16, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для недочитавших моё сообщение повторяю цитату автора for long strings Больша... большой текст свёрнут, показать
     
     
  • 5.105, Аноним (-), 11:19, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > REP SCASB

    Насколько помню, этот вариант проиграл варианту на (условных) переходах.

    Продолжай теоретизировать.

     
     
  • 6.106, n00by (ok), 11:30, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> REP SCASB
    > Насколько помню, этот вариант проиграл варианту на (условных) переходах.

    Как бы не важно, кто и что там якобы помнит, когда вот код из реального мира:



    #ifdef __HAVE_ARCH_MEMCHR
    void *memchr(const void *cs, int c, size_t count)
    {
    int d0;
    void *res;
    if (!count)
    return NULL;
    asm volatile("repne\n\t"
    "scasb\n\t"
    "je 1f\n\t"
    "movl $1,%0\n"
    "1:\tdecl %0"
    : "=D" (res), "=&c" (d0)
    : "a" (c), "0" (cs), "1" (count)
    : "memory");
    return res;
    }
    EXPORT_SYMBOL(memchr);
    #endif


    > Продолжай теоретизировать.

    Гипотетически Аноним уделал разрабов ядра, а практически он сравнивает свой воображаемый мега-код с "ускорением в 4 раза", которое уже дважды отклонили, как нерабочее.

     
     
  • 7.108, Аноним (-), 11:49, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это было сказано про мое сравнение реализаций strlen.
    В ядре линукс мало кого интересует производительность, особенно мало используемых дублирующих функций.
    Специально искал этот допотопный memscan?
     
     
  • 8.113, n00by (ok), 12:06, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет никакого сравнения ни цифр, ни подробностей о железе А на самом деле анони... текст свёрнут, показать
     
     
  • 9.115, Аноним (-), 12:17, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    производительностью которого заинтересовались и предлагают варианты ... текст свёрнут, показать
     
     
  • 10.127, n00by (ok), 13:49, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пока нет никаких измерений производительности С какой целью Вы упорно пишете чу... текст свёрнут, показать
     
     
  • 11.144, ммнюмнюмус (?), 22:46, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может, он и там тупил, ну они его и того ... текст свёрнут, показать
     
  • 5.132, Аноним (-), 16:15, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я что-то не уверен что ядро в принципе таким оперирует Там длинное это наверное... большой текст свёрнут, показать
     
     
  • 6.139, n00by (ok), 20:05, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Разумеется, не оперирует Но автор написал long Вспоминаем определение кеш-памя... большой текст свёрнут, показать
     
  • 2.9, _hide_ (ok), 10:08, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тут, курица или яйцо. Работает медленно -- ищем решение без поиска в лоб, не используем поиск в лоб -- нет оптимизации и работает медленно.

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

     
  • 2.12, Аноним (12), 10:12, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот всегда было главное единообразие чтобы обеспечить переносимость. Наоптимизировать под конкретное железо это к другим проприетарным производителям.  
     
     
  • 3.45, Аноним (45), 14:17, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно имеются в начичии и оптимизированные варианты для известных архитектур, и неоптимизированные для любых, если оптимизированного не нашлось.
     
  • 2.17, Ананас (?), 10:54, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Раздуто, а не оптимизированно
     
     
  • 3.19, Аноним (12), 10:55, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Было бы оптимизировано, то не получилось бы сделать раздуто. Было бы супермеганеподдерживаемораздуто.  
     
  • 3.42, Аноним (42), 13:46, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В итоге получат, что толстое ядро тормозит сильнее, чем микроскопическое ускорение от поиска в строках.
     
  • 2.79, Аноним (79), 20:54, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оно оптимизировано. Просто надо ещё мест, где можно очереднус спектр запустить по сторонним каналам. Обращение за пределы выделенной памяти и прочие плюшки.
     

     ....большая нить свёрнута, показать (26)

  • 1.2, pashev.ru (?), 09:29, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Вместо байтов сравнение осуществляется с использованием машинных слов, что позволяет за раз сравнивать как минимум 4 байта.

    Как в glibc 🤗

     
     
  • 2.4, Аноним (-), 09:39, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Там разве не sse и avx(512) с "до 64 байтами" за раз?
     
     
  • 3.28, Онаним (?), 12:50, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    avx(512) в здравом уме в ядре использовать никто не будет, потому что на интелах оно имеет риск проложить производительность всей числодробилки, а не только одного ядра.

    "Linus Torvalds: I hope Intel's AVX-512 'dies a painful death'"

    Ядро поддерживает софт, работающий с AVX512, но это на жуткого любителя.

     
     
  • 4.33, Аноним (-), 12:59, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > avx(512) в здравом уме в ядре использовать никто не будет

    Это монолит, нет смысла апеллировать к здравому смыслу.

     
     
  • 5.69, Онаним (?), 19:11, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, бОльшая часть ядра до последнего времени таки здравому смыслу соответствовала.

    Последние веяния в виде иоурины, ёбпф и хруста - да, заставляют напрячься. Это то, что в монолит ну никак не вписывается, да.

     
     
  • 6.90, Аноним (-), 03:28, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что за урина? Это uring чтоли так назвали? Оно может и брейнфак, но ОЧЕНЬ БЫСТРЫЙ брейнфак. И когда вы хотите всякие там 100Gig сеточки, сторажи типа оптана и проч - окей, но этот брейнфак быстрее обычных способов в разы! Поэтому с ним и канителятся.
     
  • 4.73, иисус господь евреев (?), 19:34, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    спасибо за инфу! смысул этих инструкций и новых процев околонулевой. пожалуй , пока останусь ка на коре2дуо.
     
     
  • 5.135, Аноним (135), 16:32, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://colfaxresearch.com/skl-avx512/
     
     
  • 6.136, Аноним (135), 16:33, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Английского не знаю. Судя по тексту "Я" сайт перевёл хорошо если не отлично.
     
  • 4.147, ммнюмнюмус (?), 15:17, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А что правда не так с avx-512? Я то наоборот стараюсь использовать векторизацию, вот только железа, поддерживающего что-то выше SSE так и не опробовал (у меня максимум SSE-4.3). Так что тут я слегка профан, и был бы рад пофиксить ещё немного пробелов в знаниях.

    Что в нём не так - неоптимальная реализация работы с 512-битными векторами или бессмыссленность такого подхода из за неизбежных узких мест? Насколько я заметил, самая частая ошибка при векторизации - это разложить по вектору элементы некоей сложной обработки вместо того, а не сами группы (на уровне которых линейность таки прослеживается).

     
     
  • 5.148, n00by (ok), 17:18, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Когда контекст исполнения (поток) переключается, регистры процессора надо сохранять. Операция не мгновенная, требует место в ОЗУ и может марать кеш. Было 16 штук 32-х байтных регистров (256 бит), стало вдвое больше и в количестве, и по размеру. Помножьте 2К на 1000 потоков. Интел выиграла в каком-то тесте, а система в целом просела, да ещё и ядро надо допилить.
     
  • 5.156, Онаним (?), 22:11, 15/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не так в нём то, что оно превращает в кипятильник весь камень, и частоты падают на всём кипятильнике, а не на конкретном ядре.
     
  • 5.157, Онаним (?), 22:11, 15/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    (и это не так из эксплуатационного)
    Ещё с ним не так то, что разные процы поддерживают разные несовместимые субсеты оного...
     
  • 3.30, Онаним (?), 12:51, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А так да, скорее всего оптимизации касаются как раз SSE(2) и AVX(2) - но честно скажу, не смотрел.
     
     
  • 4.31, Онаним (?), 12:52, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В принципе и даже на стандартных регистрах можно через поиск нуля после вычитания, но изврат тот ещё.
     
     
  • 5.32, Онаним (?), 12:54, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В принципе даже просто выровненный забор и 4-8 сравнений на стандартных регистрах должны дать хороший прирост, если там до этого оно побайтово делалось.
     
  • 3.70, с22 (?), 19:30, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В ядре не используются команды фпу, ссе и авх
     
     
  • 4.72, Аноним (-), 19:32, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    glibc используется?
     
  • 4.74, Аноним (-), 19:43, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Первый найденный случайный файл

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x

    Найди отсутствие AVX

     
     
  • 5.93, n00by (ok), 09:33, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Первый найденный случайный файл
    > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x
    > Найди отсутствие AVX

    Нашёл баш-программиста ядра. Смотрим не Makefile, а первый найденный случайный код. Что бы это значило и зачем? ;)

    kernel_fpu_begin();

    crypto_aegis128_aesni_init(&state, ctx->key.bytes, req->iv);
    crypto_aegis128_aesni_process_ad(&state, req->src, req->assoclen);
    crypto_aegis128_aesni_process_crypt(&state, &walk, ops);
    crypto_aegis128_aesni_final(&state, tag_xor, req->assoclen, cryptlen);

    kernel_fpu_end();

     
     
  • 6.102, pavlinux (ok), 10:39, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Что бы это значило и зачем? ;)

    напечатай из ядра sin(M_PI/19)

     
     
  • 7.104, Аноним (-), 11:08, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > напечатай из ядра

    "В ядре не используются команды" печати.

     
     
  • 8.120, pavlinux (ok), 12:53, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    открой для себя printk https www opennet ru man shtml topic printk DESCRIPTI... текст свёрнут, показать
     
     
  • 9.122, Аноним (122), 12:59, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, чёрт ... текст свёрнут, показать
     
  • 7.125, n00by (ok), 13:45, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что бы это значило и зачем? ;)
    > напечатай из ядра sin(M_PI/19)

    Ну вывести 0.16459459028 как бы не проблема. Вопрос был к утверждавшим, что FPU можно и нужно.

    The kernel's printf does not support %n. Floating point formats (%e, %f,
    %g, %a) are also not recognized, for obvious reasons. Use of any
    unsupported specifier or length qualifier results in a WARN and early
    return from vsnprintf().

     
  • 4.82, 67332 (?), 21:43, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Еще как используются, всякие там хеш-функции и прочие подобные вещи в нескольких вариантах есть.
     
     
  • 5.94, n00by (ok), 09:40, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите, _как_ оно во "всяких там" используется. Человек прав в принципе, но сформулировал некорректно. Не принято использовать. Криптопреобразования работают с данным достаточно больших объёмов и в специфичных случаях, потому имеет смысл озадачиться с сохранением контекста.
     
  • 2.22, n00by (ok), 11:22, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Специально скопирую сюда из glibc string memchr c что бы люди могли почитать ко... большой текст свёрнут, показать
     
     
  • 3.26, Аноним (-), 12:25, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Покажи ещё sysdeps/x86_64/multiarch/memrchr-evex.S

    https://sourceware.org/git?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memrc

     
     
  • 4.36, n00by (ok), 13:15, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Суть вот где:

      /* Handle the first few bytes by reading one byte at a time.
         Do this until CHAR_PTR is aligned on a longword boundary.  */

    На этом основании предлагаемому в ядро "в четыре раза быстрее" влупили NAK.

     
     
  • 5.38, Аноним (-), 13:35, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Давай так. Напиши свой наивный побайтовый алгоритм memchr (можешь даже префетч присобачить). И сравни с glibc, который будет использовать оптимизированный под твой процессор. На данных до одного гигабайта, чтоб уж наверняка вылезти за пределы всех уровней кеша.
     
     
  • 6.55, n00by (ok), 14:51, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё раз, для не уловивших суть: предлагаемое в ядро в общем случае НЕ РАБОТАЕТ, в отличие от реализации из glibc и остальных наивных.
     
     
  • 7.58, Аноним (-), 16:38, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вернемся к нашим скачущим баранам. Тогда зачем в ветке про glibc ты приводишь код из glibc, и приводишь код не всех реализаций/оптимизаций?

    Про твое "замечание" про чтение начальных нескольких невыровненных байт. Как эта O(1) операция повлияет на скорость, особенно при очень больших N?

     
     
  • 8.60, n00by (ok), 17:13, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В ответ на заявление Как в glibc 129303 я показал, что оно - ложно Затем, ... большой текст свёрнут, показать
     
     
  • 9.62, Аноним (-), 17:32, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    как в glibc , было сказано на счет позволяет за раз сравнивать как минимум 4 б... текст свёрнут, показать
     
     
  • 10.96, n00by (ok), 09:44, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз в данном случае оно не сравнивает, оно даже прочитать память не может, ... текст свёрнут, показать
     
     
  • 11.101, Аноним (-), 10:37, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя вообще ничего не работает, и ты сидишь на оффтопе и рассуждаешь, что долж... текст свёрнут, показать
     
     
  • 12.128, n00by (ok), 14:01, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дублирую цитаты I think you re missing the point Loads at unaligned addresses ... большой текст свёрнут, показать
     
     
  • 13.129, Аноним (-), 14:07, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тем временем существует оптимизированный memchr_inv ... текст свёрнут, показать
     
  • 3.81, achtosluchilos (ok), 21:26, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  On 32-bit hardware, choosing longword to be a 32-bit unsigned
    >     long instead of a 64-bit uintmax_t tends to give better
    >     performance.

    ох уж эта сишка и ее проблемы с типами на разных архитектурах.

     
     
  • 4.95, Онаним (?), 09:42, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хрустик как-то спасёт тебя от разного размера регистров в проце?
     
  • 4.97, n00by (ok), 09:51, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, может ли Rust защитить от реальной проблемы предлагаемого "ускорения" - невозможность чтения двойных слов по невыровненым адресам на некотором железе?
     
     
  • 5.133, Аноним (-), 16:20, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кстати, может ли Rust защитить от реальной проблемы предлагаемого "ускорения" - невозможность
    > чтения двойных слов по невыровненым адресам на некотором железе?

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

     
     
  • 6.137, n00by (ok), 19:20, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, можно ли нарушение alignment requirements поймать на этапе трансляции. Люди то увидели. А автор даже не знал.
     

     ....большая нить свёрнута, показать (43)

  • 1.3, pashev.ru (?), 09:31, 12/07/2022 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     
  • 1.5, Аноним (5), 09:39, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –19 +/
    Такого количества багов, костылей и рудиментов не было даже в ранней винде после перехода с мсдос
     
     
  • 2.6, Аноним (6), 10:05, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а что ты хотел, 31 год идёт ядру, его ещё причёсывают хотя бы хоть как-то
     
     
  • 3.51, Аноним (5), 14:41, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    а что ты хотел, 1031 год идёт ядру, его ещё причёсывают хотя бы хоть как-то

    P.S. где-то в далеком далеком интернете тысячу лет спустя

     
  • 2.11, n00by (ok), 10:12, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну да, в то время люди задавались вопросом "какие такие строки, как часто и зачем надо сравнивать в ядре".
     
  • 2.13, КО (?), 10:14, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты ещё исходники индусской 11 не видел.
     
     
  • 3.24, Аноним (5), 12:08, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Я нормальный линукс десктоп не видел... хотя бы на уровне XP
     
     
  • 4.25, commiethebeastie (ok), 12:13, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ага, мы уже все видел тулчейн в исходниках XP, можешь не продолжать, вот где костыли так костыли.
     
     
  • 5.27, Аноним (5), 12:47, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Плохому линуксоиду виндоус мешает
     
     
  • 6.34, Аноним (6), 13:00, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    ЛЮБОМУ линуксоиду виндоуз мешает)
     
  • 6.44, Аноним (45), 14:12, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А виндузоид не видел десктопа лучшего, чем XP.
     
     
  • 7.49, Аноним (5), 14:36, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это классика, это знать надо
     
     
  • 8.53, Аноним (45), 14:46, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да знаю - синдром утёнка ... текст свёрнут, показать
     
     
  • 9.84, Тот_Самый_Анонимус (?), 22:24, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Переходи на армянский алфавит Как не хочешь У тебя синдром утёнка Логика ... текст свёрнут, показать
     
  • 8.159, Конь Антон (?), 06:08, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это некрофилия а не классика Тупой ты баран ... текст свёрнут, показать
     
  • 3.59, Аноним (59), 16:47, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ты ещё исходники индусской 11 не видел

    Кстати! Я, старый линуксовод (не помню XP, то есть перешёл до появления XP) недавно купил подержанный неттоп, а на нём обнаружилась 11-я винда. И, знаете ли, даже понравилось! Гламурненькая система. Только обновляется, сцуко, без спроса.

     
     
  • 4.65, Аноним (-), 18:36, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В поддержанных неттопах Windows 7 есть, 11-я в новых.

    >И, знаете ли, даже понравилось! Гламурненькая система.

    Будь осторожен это начало признака деградации.

    >Только обновляется, сцуко, без спроса.

    Знаете ли вы, что Windows периодически делает скриншоты вашего Рабочего стола и отправляет их на непонятные сервера.

     
     
  • 5.85, Тот_Самый_Анонимус (?), 22:25, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >>И, знаете ли, даже понравилось! Гламурненькая система.
    >Будь осторожен это начало признака деградации.

    Это что-то со скрижалей фанатиков.

     
  • 2.46, Аноним (45), 14:26, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе M$ тогда исходники показывал ранней Венды?
     
     
  • 3.50, Аноним (5), 14:38, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Уж лучше чем у этой студенческой подделки

    Just for fun! Как говорится...

     
     
  • 4.52, Аноним (45), 14:43, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так показывал или фантазёр?
     
  • 3.63, Аноним (63), 17:32, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На изучай сколько угодно хоть вин2000 хоть нт4

    magnet:?xt=urn:btih:66a26447f563c3dc2336de74ae37dc14d11dd8b9&dn=windows_nt_4_source_code.zip

    magnet:?xt=urn:btih:82658c6baab65a855f804a534e55f64fbb2ec977&dn=Windows_2000_source_code.rar

     
     
  • 4.66, Аноним (-), 18:37, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лютое не нужно.
     
  • 4.118, commiethebeastie (ok), 12:39, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > На изучай сколько угодно хоть вин2000 хоть нт4
    > magnet:?xt=urn:btih:66a26447f563c3dc2336de74ae37dc14d11dd8b9&dn=windows_nt_4_source_code.zip
    > magnet:?xt=urn:btih:82658c6baab65a855f804a534e55f64fbb2ec977&dn=Windows_2000_source_code.rar

    Гораздо новее есть исходники, windows server 2003 :)

     
  • 2.134, Аноним (-), 16:22, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Такого количества багов, костылей и рудиментов не было даже в ранней винде
    > после перехода с мсдос

    Это ты погорячился и просто не видел в Win3.x/9x их типа-кернелы - настолько раздристаное месиво что состояло из примерно трех не особо связанных между собой частей.

     

  • 1.16, Бывалый смузихлёб (?), 10:43, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Вместо байтов сравнение осуществляется с использованием машинных слов,
    > что позволяет за раз сравнивать как минимум 4 байта.

    Очень интересно, и каким же образом это делается с учётом что ожидается некоторая универсальность для разных архитектур

     
     
  • 2.18, Аноним (12), 10:54, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Он ифдефов конечно же напихал. Но ничего хорошего в этом нет имхо.  

    >> if defined(CONFIG_ARCH_HAS_FAST_MULTIPLIER) && BITS_PER_LONG == 64

     
  • 2.20, n00by (ok), 10:58, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Способ назван "сломаным"

    > I think you're missing the point. Loads at unaligned addresses may not
    > be allowed by hardware using conventional load instructions or may be
    > inefficient. Given that this memchr implementation is used as a fallback
    > when no hardware-specific version is available, you should be
    > conservative wrt. hardware capabilities and behavior. You should
    > probably have a pre-alignment loop.

    Exactly!
    The initial code is broken, NAK.

    P.S. At least you may look into strscpy() implementation to get a clue.

    https://lkml.org/lkml/2022/7/11/1329

     
  • 2.23, Sw00p aka Jerom (?), 11:59, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Очень интересно, и каким же образом это делается

    параллельный аппаратный компоратор, хотя тут есть один момент для строк вида, abac, aaaa и т. д. если ишем a.

     
  • 2.47, Аноним (45), 14:32, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С помощью #ifdef ... #else ?
     

  • 1.21, n00by (ok), 11:11, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Осталось понять, что он там оптимизировал:

    $ grep -R "e __HAVE_ARCH_MEMCHR" *
    arch/powerpc/include/asm/string.h:#define __HAVE_ARCH_MEMCHR
    arch/s390/include/asm/string.h:#define __HAVE_ARCH_MEMCHR /* inline & arch function */
    arch/arm/include/asm/string.h:#define __HAVE_ARCH_MEMCHR
    arch/alpha/include/asm/string.h:#define __HAVE_ARCH_MEMCHR
    arch/x86/include/asm/string_32.h:#define __HAVE_ARCH_MEMCHR
    arch/arm64/include/asm/string.h:#define __HAVE_ARCH_MEMCHR
    arch/sh/include/asm/string_32.h:#define __HAVE_ARCH_MEMCHR

     
  • 1.37, Аноним (37), 13:30, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > до 4 раз быстрее

    Это же не реклама, зачем употребтять "до"? Тем более, что в оригинале написано "около" - "around ~4x".

     
     
  • 2.40, Аноним (42), 13:41, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > "around ~4x"

    Каков радиус этого эраунда?

     
     
  • 3.41, Аноним (37), 13:44, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это не важно, главное что центр в районе 4х
     
     
  • 4.87, Аноним (42), 01:32, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > центр в районе 4х

    Точно-точно центр? Судя по цифрам из топика - это теоретический край.

     

  • 1.39, Аноним (42), 13:40, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > в больших строках новый вариант оказался быстрее старого примерно в 4 раза (например, для строк в 1000 символов)

    В 4 раза - что планируем получить...

    > В ядре Linux размер обрабатываемых в memchr() строк достигает 512 байт. Прирост производительности для 512 байтовых строк, в ситуации, когда искомый символ находится в конце строки, составляет 20%.

    Максимум 20% - мягко сказать, уже далеко не в 4 раза.

    > Общий прирост производительности подсистем ядра при использовании оптимизированного варианта "memchr()" пока не оценивался

    В реальности - 0.0X%, что даже постыдились показать.

     
     
  • 2.43, Аноним (37), 13:48, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Максимум 20%

    С какого потолка взял?

    > В реальности - 0.0X%, что даже постыдились показать.

    Русским языком же написано "пока не оценивался", какие буквы ты не понял?

     
     
  • 3.57, n00by (ok), 15:06, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Эта тема обещает быть самой весёлой переписью экспертов. ;)

    If you fix the issue, kindly add following tag where applicable
    Reported-by: kernel test robot <lkp@intel.com>

    All errors (new ones prefixed by >>):

    >> lib/string.c:902:7: error: conflicting types for 'memchr'

       void *memchr(const void *p, int c, unsigned long length)
             ^
       include/linux/string.h:162:15: note: previous declaration is here
       extern void * memchr(const void *,int,__kernel_size_t);
                     ^
       1 error generated.

     
  • 3.88, Аноним (42), 01:33, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С какого потолка взял?

    Перечитай сабж внимательно.

     

  • 1.56, Аноним (56), 15:06, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хоспадя. Сами в 2022 году писать не умеют, так хоть бы списывать учились. http://fastcode.sourceforge.net/
     
     
  • 2.68, pavlinux (ok), 18:58, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > ... так хоть бы списывать учились. http://fastcode.sourceforge.net/

    Эти тоже в Стэнфорде спионерили:  © 1997-2005 Шон Эрон Андерсон  https://graphics.stanford.edu/~seander/bithacks.html

     

  • 1.61, Аноним (61), 17:23, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А зачем в новой реализации исходная строка/указатель двигается?
     
     
  • 2.64, Аноним (63), 17:34, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Имя автора северокорейского засланца прочитай и всё поймешь
     

  • 1.67, pavlinux (ok), 18:53, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/



    void *memchr(const void *p, int c, size_t length)
    {
        u64 mask, val;
        const void *end = p + length;
        c &= 0xff;

        while ((long ) p & (sizeof(long) - 1)) {
            if (p >= end)
                return NULL;
            if (*(unsigned char *)p == c)
                return (void *) p;
            p++;
        }
        if (p <= end - 8) {
            mask = c;  /* <================= это нахуа? */
            MEMCHR_MASK_GEN(mask);

            for (; p <= end - 8; p += 8) {
                val = *(u64*)p ^ mask;
                if ((val + 0xfefefefefefefeffull) & (~val & 0x8080808080808080ull))
                    break;
            }
        }

        for (; p < end; p++)
            if (*(unsigned char *)p == c)
                return (void *)p;

        return NULL;
    }



     
     
  • 2.86, Аноним (56), 22:35, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну наверное для MEMCHR_MASK_GEN
     

  • 1.71, Аноним (71), 19:32, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я уж испугался. Думал на расте переписали и уделали Си )
     
  • 1.75, qwe (??), 20:02, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А я уж думал, что подобное давно оптимизировали. Интересно, а компиляторы хотя бы до такой наивной оптимизации доросли?

    if (strlen(s) == 5) --> if (strnlen(s, 6) == 5)

    Это не сильно актуально при малых строках строках, а при огромных - выигрыш существенен. Тем не менее второй вариант кода - большая редкость.

     
     
  • 2.100, n00by (ok), 10:33, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > А я уж думал, что подобное давно оптимизировали.

    Давно оптимизировали. Предлагаемый код пока вообще не работает.

    > Интересно, а компиляторы хотя
    > бы до такой наивной оптимизации доросли?
    > if (strlen(s) == 5) --> if (strnlen(s, 6) == 5)

           -Wno-stringop-overread
               Warn for calls to string manipulation functions such as "memchr", or "strcpy" that are
               determined to read past the end of the source sequence.


     
     
  • 3.131, qwe (??), 15:26, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >        -Wno-stringop-overread
    >            Warn for calls to string manipulation functions such as "memchr", or "strcpy" that are
    >            determined to read past the end of the source sequence.

    И как сие работает? Сдается мне, что эта опция совсем не для этого. Я имею ввиду, что часто нет необходимости вычислять всю длину строки, и при сравнении длины строки с N можно дальше N+1 байта не ходить, что очень даже полезно в случае, если строка очень большая.

     
     
  • 4.138, n00by (ok), 19:40, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да, опция для другого. Задействованный механизм позволяет иногда оптимизировать чуть лучше:



    $ cat test.c
    #include <string.h>

    int test(const char* s)
    {
      return strlen(s) == 5;
    }

    int main()
    {
      return test("12345");
    }

    $ gcc -o test.s test.c -S -O2
    $ cat test.s

    test:
    subq $8, %rsp
    call strlen@PLT
    cmpq $5, %rax
    sete %al
    addq $8, %rsp
    movzbl %al, %eax
    ret

    main:
    movl $1, %eax // strlen вообще не вызывается
    ret



    В асм листинге вырезал нерелевантный текст.

    То, что Вы предлагаете - это не наивная оптимизация. Подсчёт кол-ва символов в строке помещает всю строку в кеш. Если её длина больше 5 - может именно это программисту и надо?

     
     
  • 5.140, qwe (??), 20:38, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чуть лучше, только если строка - это константа. Что же касается строки

    strlen(s) == 5

    То тут довольно очевидно что именно программисту нужно. По крайней мере когда результат выполнения strlen никуда не сохраняется.

     
     
  • 6.149, n00by (ok), 17:28, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мне не очевидно, даже не знаю, когда такое может потребоваться и почему в реальной задаче нельзя проверить s[5].
     
     
  • 7.153, qwe (??), 18:43, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне не очевидно, даже не знаю, когда такое может потребоваться и почему
    > в реальной задаче нельзя проверить s[5].

    Что если длина строки 2 а память, где хранится строка, перед этим была обнулена? А что если проверяемая длина лежит за границей выделенного блока памяти? Вы точно знаете как именно организованы строки в Си?

     
     
  • 8.154, n00by (ok), 06:33, 15/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот поэтому и пишу в реальной задаче Могу придумать гипотетическую задачу, гд... текст свёрнут, показать
     
     
  • 9.155, qwe (??), 13:16, 15/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я спрашиваю про конкретную оптимизацию при использовании конкретной функции из с... текст свёрнут, показать
     
     
  • 10.160, n00by (ok), 07:17, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А я увидел человека, кто не может сгенерировать ассемблерный листинг и изучить е... текст свёрнут, показать
     
     
  • 11.161, qwe (??), 12:31, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А если человек сгенерировал, изучил, но вам не доложил, как вы его отличите от т... текст свёрнут, показать
     
     
  • 12.162, n00by (ok), 13:18, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Очень просто - априори я верю человеку на слово Если он пишет Интересно, а ком... текст свёрнут, показать
     
  • 2.141, Аноним (141), 20:59, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    По мне, слишком редкая операция - сравнение длины строки с заранее известной константой, чтобы тратить ресурсы на оптимизацию.

    Если уж прям надо часто работать с длиной строки, то лучше использовать паскалевские-, с++- строки с длиной.

     

  • 1.76, Атон (?), 20:03, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сколько раз в секунду ядро линукса ищет символ в массиве?   Чисто для понимания, насколько ускорится вся работа десктопа.
     
     
  • 2.78, Аноним (-), 20:28, 12/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В файловых системах должна часто использоваться. Например, для поиска (отсутствия) слешей.
     
     
  • 3.99, n00by (ok), 10:09, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь прикиньте длину среднего имени файла и затраты на подготовку его быстрой функции (допустим, он в итоге всё-таки напишет рабочий вариант).
     
     
  • 4.103, Аноним (-), 10:55, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > затраты на подготовку его быстрой функции

    Теоретик, ты даже не знаешь какие затраты. Насколько затраты больше, чем побайтовое чтение (невыравненного начала)?

     
     
  • 5.107, n00by (ok), 11:46, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, не знаю. Пока есть два нерабочих варианта "быстрой функции", и один Анонимный эксперт, который замерял rep scasb для 1 байта на i80386, знать как бы и не о чем.

     
     
  • 6.110, Аноним (-), 12:01, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > rep scasb для 1 байта на i80386

    Теоретик, как раз на нем REP SCASB или другие стрковые инструкции с префиксом REP могут быть и быстрее, в отличии от суперскалярных процессоров с внеочередным исполнением команд.

     
     
  • 7.124, n00by (ok), 13:34, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну то есть цифр никаких так и нет, один трындёж.
     
  • 3.109, n00by (ok), 11:53, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > В файловых системах должна часто использоваться. Например, для поиска (отсутствия) слешей.

    Если бы анонимный эксперт отвечал за свои слова, то поиск в тексте ext4 выдал бы ему следующее из fs/ext4/ioctl.c



    if (memchr_inv(head.fmh_reserved, 0, sizeof(head.fmh_reserved)) ||
        memchr_inv(head.fmh_keys[0].fmr_reserved, 0,
           sizeof(head.fmh_keys[0].fmr_reserved)) ||
        memchr_inv(head.fmh_keys[1].fmr_reserved, 0,
           sizeof(head.fmh_keys[1].fmr_reserved)))
    return -EINVAL;



     
     
  • 4.112, Аноним (-), 12:05, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, что отвечаешь за мои слова, а то было лень искать примеры.
     
     
  • 5.123, n00by (ok), 13:29, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Отвечаю. Вы, сударь, пустозвон:

    * memchr_inv - Find an unmatching character in an area of memory.

     
     
  • 6.126, Аноним (-), 13:46, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > memchr_inv

    кстати, оптимизированный, не побайтовый

     
  • 2.91, thhh (?), 07:04, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Логика в чем по твоему? Если каждое звено по отдельности не в носит существенного вклада в производительность всей системы, то оптимизировать ничего не нужно?
     
  • 2.98, n00by (ok), 10:05, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто чувак захотел стать знаменитым. Там стоит почитать ответы. Он как бы исправил исходную ошибку (код вообще нерабочий изначально), вот новое:

    Have you had a chance to read how strscpy() is implemented? Do you understand why it's done that way?

     
     
  • 3.142, Атон (?), 21:36, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это просто чувак захотел стать знаменитым. Там стоит почитать ответы. Он как
    > бы исправил исходную ошибку (код вообще нерабочий изначально), вот новое:

    20 лет никто не замечал что код не работает. этим не рабочим кодом никто не пользовался. теперь им никто не будет пользоваться до 20% быстрее.

    ну, ок.

     
     
  • 4.151, n00by (ok), 17:40, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пишу же - там читайте ответы. Исходная - в смысле в предлагаемом "ускорении" была ошибка и оно не собиралось даже на каких-то архитектурах. Потом была вторая попытка. Его вежливо спросили, понимает ли он вообще, что пишет. Вроде бы автор уже скис.
     
  • 4.163, Аноним (163), 14:06, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >20 лет никто не замечал что код не работает

    Вся суть линукса в одной фразе

     
     
  • 5.164, n00by (ok), 14:39, 16/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >>20 лет никто не замечал что код не работает
    > Вся суть линукса в одной фразе

    Вся суть анонимных экспертов. Код не видели, ничего не поняли, но уже что-то мнят.

     

  • 1.77, Аноним (77), 20:21, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Fedora 36.

    uname -a
    Linux 5.18.10-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 7 17:21:38 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

     
  • 1.80, _kp (ok), 21:00, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хмм. А что интенсивный поиск в больших строках в ядре делает?
    Ну, если экзотический драйвер, понятно, можно в сам драйвер поместить недостающее.
    Но, это не должна быть массовая функция.
    Но, видимо кто то хочет 0нанизм с поиском и интенсивным копированием в ядро переместить.
     
  • 1.83, кубрик (?), 22:04, 12/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да, растишке такое и не снилось.
     
  • 1.111, pavlinux (ok), 12:02, 13/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    чот я не нашёл профита :)
    # ./a.out
    ARRAY SIZE: 1048576
    LIB: 20754
    NEW: 25628




    #include <stdio.h>
    #include <stdlib.h>
    #include <linux/types.h>
    #include <string.h>
    #include <ctype.h>
    #include <time.h>
    #include <sys/time.h>

    #define A_SZ 1024*1024

    unsigned char str[A_SZ] = { '\0' };

    long long tv = 0;

    unsigned long long _rdtsc()
    {
    union ts {
    unsigned long long tx;
    struct dword {
    long tl, th;
    } dw;
    } t;

    asm("rdtsc\n":"=a"(t.dw.tl), "=d"(t.dw.th));
    return t.tx;
    }

    void gen_array()
    {
    int i, c;
    srand(time(NULL));

    for (i = 0; i < A_SZ;) {
    c = rand() % 255;
    if (!isprint(c))
    continue;
    str[i] = c;
    i++;
    }
    printf("ARRAY SIZE: %d\n", i);
    }

    #define MEMCHR_MASK_GEN(mask) (mask *= 0x0101010101010101ULL)

    void *new_memchr(const void *p, int c, size_t length)
    {
    __u64 mask, val;
    const void *end = p + length;

    c &= 0xff;

    /* write(1, "strchr\n", 7); */

    while ((long)p & (sizeof(long) - 1)) {
    if (p >= end)
    return NULL;

    if (*(unsigned char *)p == c)
    return (void *)p;

    p++;
    }

    if (p <= end - 8) {
    mask = c;
    MEMCHR_MASK_GEN(mask);

    for (; p <= end - 8; p += 8) {
    val = *(__u64 *) p ^ mask;
    if ((val + 0xfefefefefefefeffull) & (~val & 0x8080808080808080ull))
    break;
    }
    }

    for (; p < end; p++)
    if (*(unsigned char *)p == c)
    return (void *)p;

    return NULL;
    }

    int main()
    {
    unsigned char ch;
    char *ret = NULL;
    int count = 0;

    gen_array();

    /* glibc */
    tv = _rdtsc();
    for (ch = 0x20; ch < 0x7E; ch++)
    ret = memchr(str, ch, A_SZ);
    printf("LIB: %lld\n", _rdtsc() - tv);

    /* new */
    tv = _rdtsc();
    for (ch = 0x20; ch < 0x7E; ch++)
    ret = new_memchr(str, ch, A_SZ);
    printf("NEW: %lld\n", _rdtsc() - tv);

    return (0);
    }


     
     
  • 2.114, Аноним (-), 12:12, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что с чем сравниваешь?

    При чем тут ядро линукс?

    > /* glibc */

    Угадай с 3 раз, какая в glibc реализация memchr: побайтовая, пословная, sse, avx?

     
     
  • 3.116, pavlinux (ok), 12:26, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Угадай с 3 раз, какая в glibc реализация memchr: побайтовая, пословная, sse,
    > avx?

    Да пофиг, быстрее и всё.  

     
     
  • 4.117, Аноним (-), 12:30, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, надо glibc запихать в ядро.
     
     
  • 5.119, pavlinux (ok), 12:44, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Согласен, надо glibc запихать в ядро.

    )))

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

    В жлибсе вот эта юзается https://www.felixcloutier.com/x86/pcmpistri.html

     
     
  • 6.121, Аноним (-), 12:53, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Не, просто поступил запрос на возможность впаять эту фичу в юзерспейс...

    Облом, кто-то оказался шустрее.

    В musl такая же пословная реализация memchr, вроде. Можешь сравнить.

     
  • 2.130, n00by (ok), 14:34, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > чот я не нашёл профита :)
    > # ./a.out
    > ARRAY SIZE: 1048576
    > LIB: 20754
    > NEW: 25628

    Если чего ещё не нашли - они там "ускоряют" drivers/misc/lkdtm/heap.c
    то есть вот это:



    if (memchr(val, 0xAB, 512) == NULL) {
    pr_info("Memory appears initialized (%x, no earlier values)\n", *val);
    } else {
    pr_err("FAIL: Slab was not initialized\n");
    pr_expected_config_param(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, "init_on_alloc");
    }

    ...

    if (memchr(val, 0xAB, PAGE_SIZE) == NULL) {
    pr_info("Memory appears initialized (%x, no earlier values)\n", *val);
    } else {
    pr_err("FAIL: Slab was not initialized\n");
    pr_expected_config_param(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, "init_on_alloc");
    }



     
     
  • 3.146, pavlinux (ok), 00:17, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > ... они там "ускоряют"

    printk выкинули бы, вот это был бы профит )))

     
     
  • 4.150, n00by (ok), 17:38, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще в шоке.))) А если партия даст миллиону китайцев задание отправить такие ускорения?
     

  • 1.143, Непростое кино (?), 22:38, 13/07/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я посмотрел код, непонятная магия сравнения байта со словом, если кто может, объясните плиз методу.
     
     
  • 2.145, pavlinux (ok), 23:48, 13/07/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот тут почитай: https://graphics.stanford.edu/~seander/bithacks.html#ValueInWord
    пункт "Determine if a word has a zero byte" и за ним "Determine if a word has a byte equal to n"


     
  • 2.152, n00by (ok), 17:53, 14/07/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На русском есть книга Генри С. Уоррен мл. "Алгоритмические трюки для программистов", см главу "поиск в слове".
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру