>> Для недочитавших моё сообщение повторяю цитату автора "for long strings". Большая строка
>> - это не 512 байт. В современных реалиях это, должно быть, гигабайты.
> Я что-то не уверен что ядро в принципе таким оперирует.Разумеется, не оперирует. Но автор написал long. Вспоминаем определение кеш-памяти - это маленькая быстрая память. Значит не попадает в кеш.
> Там длинное
> это наверное PATH_MAX какой-нибудь. Хоть я и не смотрел какой там
> наихучший случай конечно.
Там ускоряют 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");
}
>> Разницу скорости чтения из кеша и ОЗУ ищите сами.
> Спасибо, Капитан Очевидность.
>> А подготовительные операции мы не считаем, зачем это - вдруг разрушит нашу
>> стройную гипотезу.
> Ну, э, подготовительные операции или нет, а по эн байтов за раз
> обычно эффективнее чем по одному.
На одном байте особенно эффективно будет, ага.
Assembly/Compiler Coding Rule 5. (MH impact, MH generality) Selectively inline a function if
doing so decreases code size or if the function is small and the call site is frequently executed.
Assembly/Compiler Coding Rule 8. (ML impact, ML generality) Favor inlining small functions that
contain branches with poor prediction rates. If a branch misprediction results in a RETURN being
prematurely predicted as taken, a performance penalty may be incurred.
>> И статистику по длине строк не собрали. Просто голословно
>> посчитаем себя умнее автора существующей реализации через REP SCASB,
> Ммм а как сие на ARM и RISCV?
$ 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_MEMCHRuProf
arch/sh/include/asm/string_32.h:#define __HAVE_ARCH_MEMCHR
>> но напишем про это не ему, а вот тут.
> Ага. Усомнившись в некоторых аспектах спича. И автор наверное все же не
> полный рак и побенчил свое добро? И что там реально будет
> лучше - ну я не настолько хорошо все варианты микроархитектур x86
> знаю чтобы рассуждать чего в каком случае лучше и для кого
> из подвидов.
Как бы он это сделал? Вот реально, без синтетики. С тех пор как AMD CodeAnalyst превратился в uProf, не понятно, как симулировать исполнение и посмотреть что там сколько занимает в тактах.
