MTU - насколько я понимаю вообще не локальное свойство а свойство конкретной сети.

Это было-бы прекрасно. Я-бы сидел и кодил под свой Z80.

И предсказывать, куда свернёт переход по JZ/JA...e.t.c.

Данные посты одного мембера были удалены технически т.к. была закрыта учётка. Но контент мне понравился и
я их восстанавливаю из удалённых.

полудуху разных процов разное кол-во кэша, у corei9 под 20мб (и 10/20 ядер), у i7 - 16mb, у i5 - 12mb
а как именно это в коде использовать, чтобы выжать максимум из этих нескольких дополнительных Mb ?


fintank_ruНикак.

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

Важно другое: что единицей обмена с памятью является кеш-линия (упрощённое понимание, но на 90% практически годное)
То есть, проц не может прочитать из ОЗУ 1 байт или 8 байт - только всю кеш-линию.
Отсюда главная мудрость: "раз уж приехало, то использовать".
То есть, если вам из ОЗУ в кеш подвезли 64 байта, потратив 200 тактов, то все эти 64 байта должны быть вам полезны прямо сейчас.
Не надо использовать 8 байт, а потом трогать такой адрес в памяти, который за мегабайт от него.
Надо располагать данные (и код) так, чтобы максимальное количество из загруженной кеш-линии сразу же использовалось.
Идеальный пример: эти 64 байта хранят 8 64-битных чисел, которые вам надо перемножить.
Запись - аналогично.
Плюс межпроцессные коммуникации - если 2 процессора полезли менять память по близким адресам (между которыми меньше 64 байт), то вероятно они трогают одну кеш-линию и будут тратить время на синхронизацию между собой. Нельзя просто так взять и записать из двух разных процов в одно место оперативы. Или нельзя из одного проца прочитать адрес в ОЗУ, который был загружен в кеш другого проца и там изменён.

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

В общем, это единственное, что надо знать про кеш - что обмен с реальной ОЗУ - целыми кеш-линиями.
Если вы читаете по 1 байту с интервалом 1 килобайт, значит шина памяти забита на 98.4% тем, что вам не надо.
Дороги заняты перевозкой батонов, которые никто не жрёт.

Ещё хорошо отделять читающие потоки данных от пишущих.
Не надо в кеш-линию укладывать 7 лонгов которые надо умножить, а 8-й использовать для хранения результата.
Смешивать чтение и запись в одной кеш-линии почему-то плохо, не помню почему.
Ну например потому, что не надо другим процессорам парить мозг по поводу того, что кеш-линия внезапно поменялась, хотя там 90% данных только для чтения.
Короче буфер с исходными данными отдельно от буфера для результатов.

Можно заценить на ютубе лекции С. Майерса или Г. Саттера на эту тему. Там много всяких таких приколов про межпроцессное взаимодействие, false sharing - когда процы друг другу мешают и т.п.

fintank_ruЕсть ещё такое понятие - cache oblivious.
Это такое прилагательное.
Означает "что-то, что в курсе про кеш и делает из этого профит, но плевать хотело на конкретные параметры кеша".
Хотя прямой перевод на русский звучал бы как "не видящий кеш", как будто что-то не оптимизированное.
Слово oblivious буржуи заюзали для той части смысла, которая про "плевать хотело на параметры", а не на сам кеш.
Например: https://en.wikipedia.org/wiki/Cache-oblivious_algorithm
https://en.wikipedia.org/wiki/Van_Emde_Boas_tree - как уложить бинарное дерево так, чтобы от появления кеша она ощущала профит.
Имеет смысл думать в таком стиле, а не про конкретные параметры кеша.
Вкратце - это такие алгоритмы и структуры данных, которые эксплуатируют принцип "скорее всего батоны будут не по одному, а в ящиках и один ящик везти дорого".

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

fintank_ruНе за мгновение ока.
Порядок числа переключений задач в OS обычно в районе 100 с пиками в 1000 в секунду.
Системный таймер, который пинает шедулер ("работай ленивая скотина!") пинается с частотой 250...1000 гц.
Не на каждое такое прерывание происходит переключение задач, часто переключение не нужно.
А иногда переключение делается чаще, если процессу пришли данные из сети или из диска или чё-то такое ещё.
На среднем веб-сервере народ мерял - в районе 100 раз в секунду.
Софтине, которая никакое IO особо не юзает и которая просто чё-то считает в памяти и которая почти одна такая на сервере будут подолгу давать работать.
Но даже при 200 раз в секунду и 3 гигагерцах вам доступно непрерывно 15 млн тактов.
Это можно 75 тысяч раз успеть сходить в ОЗУ промахнувшись мимо кеша и закешировав что-то (поход в ОЗУ считаю = 200 тактов).
И овердофига раз сходить в кеш.
Так что нифига не мгновение ока, а целая вечность - можно успеть много раз поюзать кеш.

Можно попробовать использовать aligned_alloc() и указать в качестве кратного - 8 байтов.

Вот тут пишут.
https://en.cppreference.com/w/c/memory/aligned_alloc

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

Вот анти-тест придумать легко.

Одна из задач над которой я думал в процессе https://www.sql.ru/forum/1173809-1/tyapnichnyy-benchmark-cpu-part-1
это был бенчмарк памяти+кеша. Ноя так и не придумал объективную постановку. Тоесть такую которая хотя-бы
была непохожа на Biosmemory test или на MemTest.

Вобщем я искал нечто прикладное. Лежащее на рубеже языков и железа. Но так и не придумал.

Как альтернативный топик - я предлагаю также поднять
вопрос

что внутри ВАШЕГО бинарника