LINUX.ORG.RU

Я с утра чёт сломался. Я правильно понимаю кэши?

 , , ,


1

1

Я правильно понимаю что…

$lscpu
$...
L1d cache:    384 KiB
L1i cache:    384 KiB
$cat /proc/cpuinfo
cache_alignment	: 64
  • L1d - кэш данных 384 KiB *2^10 == 393216 байт
  • L1i - кэш инструкций 384 KiB *2^10 == 393216 байт
  • L1 - общий объём 768 KiB *2^10 == 786432 байт

Меня интересовать должно только L1d

  • Итого ((384 * 2^10)/64) == 6144 кэш линии в L1 кеше

Если я теперь в цикле буду крутить многократно эти два массива и они будут друг в друга что-то вычислять и писать

тут оба займут 50% L1d кеша?

uint64_t A[1536]; //  6144÷4
uint64_t B[1536]; //  6144÷4

То как бы я могу надеяться что они оба на втором полном проходе окажутся целиком в L1? Или я вообще сейчас херню спорол как ебобо?


P.S. Кто у нас вандалит теги? ECS стёрли, cpu cashe стёрли и кучу всего другого. Ничего точно указать нельзя. Одну банальщину в тегах оставили. Теги на то и теги что-бы точечно указывать. Вот я указал «память» и чё? Толи про оперативную пишу то ли про склероз свой.

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

на твоём тормозном феноме вообще насрать, всё равно будет тормозить

anonymous
()

L1d cache: 384 KiB

Это же на все 6 ядер. Твоей же программе будет доступен кэш только того ядра, на котором она выполняется.

gremlin_the_red ★★★★★
()

Нет, не правильно, эта архитектура с кешами простая только на картинках передающихся по наследству с начала 2000х, современные процы это почти магия, они используют сотни ковееров и довольно эффективно пытаются предугадать последующие инструкции/обращения к памяти, выполняя их в порядке в котором удобно им, т.е. по сути если у тебя в коде a=4, а b=9, это не значит что процессор выполнит присвоение именно в этом порядке, он сделает это так как посчитает удобным в данный момент, поэтому и используют сейчас идеологию «барьеров памяти» ( читать тут ). В тему кешей там творится полнейшая вакханалия, лучше не пытаться упростить довольно сложный механизм, если реально хочешь с ними разобраться читай про spectr, meltdown и пр прелести, уже не трогая cache per core и cache per cpu, т.е. поведение будет разное в зависимости от проца)) И ещё раз, лучше не начинай упрощать сложные вещи, это путь в никуда, если интересно и хочешь разобраться то начинай ковырять с верху в низ и используя технлогии хотябы 10ти летней давности

sparks ★★★★
()
Ответ на: комментарий от gremlin_the_red

Тьфу! Вот оно. Чую что-то не так, а никак не мог понять что. 1024 линии на ядро получается. Тему можно закрывать, спасибо.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от sparks

У меня суть в том как организовать данные удобные для cpu (man ECS или дата оринтед программинг :D или тип того) Я же недавно что-то подобное спрашивал (Про выравнивание). По итогу да вакханалия. Но мне не точетно под проц конкретный, а просто продумать общий подход, неидеальный, но всё же. Но при этом хочу не потерять гибкости, а то так каждую софтину можно свести к итерациям по массивам если упороться на 100% (хотя часто так и надо)

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Ну тут по сути, чем предсказуемее твой код для проца, тем эффективнее он его будет выполнять)))) Так же это и многих оптимизаций касается, тот же GCC исчисляет их тысячами, пытаясь чтото оптимизировать руками может принести больше головняков чем пользы

sparks ★★★★
()

Если я теперь в цикле буду крутить многократно эти два массива и они будут друг в друга что-то вычислять и писать

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

alysnix ★★★
()

Чистая ecs это миф. Её нельзя использовать в реальности ни для чего кроме демонстрации презентаций упоротых ecs-адептов.

Ecs это в первую очередь почти бесконечная расширяемость с сохранением адекватной сложности обслуживания кодовой базы.

В любой мало-мальски адекватной игре не существует независимых проходов по отдельным массивам. Всегда приходится делать косвенную адресацию минимум для одного из операндов n-арной операции.

Забудь про два массива и их сложение по n-му элементу. Это вырождённый случай, в дикой природе не встречающийся.

anonymous
()
Ответ на: комментарий от alysnix

Эффективный алгоритм в моей основе это hashmap. Я же разбиваю его/их на чанки. Ибо мне в одном месте надо по ключам пройтись, это одно, а в другом месте последовательно топать по всем элементам (включая link-list или b-tree в зависимости от типа mashmap который автоматически подбирается в зависимости от типа данных, где то есть смысл перестроить таблицу если степень заполнения больная или list вырос сильно, а где то смысла нет и проще b-tree влепить) Но суть не про это.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

так оно и сделано во всяких k k+ и тому подобных повёрнутых БД - где кортежи не хронятся как записи-рекорды а размазанны каждое поле в отдельном массиве - т.е данные агрегированны не по «строчно» а по «столбово»

simd для того и …

ваще первые 80% пользы от простейших эвристик достигается

дальше идёт ад падения возврата на инвестиции

ака 95% - затем нет пути

99% это уже уровень больших тиражей где на миллионы изделий зашитый код

т.е оптимизация под конретный степинг.

иначе базовые эвристики - начиная с уменьшения косвенности - которой так характерны ооп-астронавты.

qulinxao3 ★★
()

Ты же, наверное, любишь всякую дичь бенчить?

Может быть заведём уголок для юных сишников? Было бы прикольно какую-нибудь задачку хотя бы раз в пару недель решать, бенчить и обсуждать.

Что-то типа Codewars только в формате форума. Как тебе?

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Ты же, наверное, любишь всякую дичь бенчить?

Ну да в принцпе. :D Оно правда в практические цели потом уходит. Но так то да.

Может быть заведём уголок для юных сишников?

Ну можно, чё бы нет.

Было бы прикольно какую-нибудь задачку хотя бы раз в пару недель решать. Бенчить и обсуждать.

Норм. Только в идеале ещё и прикладную. Хотяяя. Любой ужас мысли если он работает быстро можно приспосабливать к чему то.

Что-то типа Codewars только в формате форума. Как тебе?

Норм. Важно помнить только что конкретно я не программист, а любитель. Буду с серьёзными щами втирать неопровержимые домыслы :D А иногда пропадать

Надо

  • 1 придумать название PRAGMA_TEAM,LORCWAR,CConsilium,AnskillDebill,CWHACK,CSRC,CNULL или иное. По барабану в принципе, но было бы прикольно если бы было прикольное название.

  • 2 Завести тег, помечать как-то надо

  • 3 Каждая новая тема должна быть именована похоже. Типа CSRC(0x0) - Название темы 1,CSRC(0x1) - Название темы 2

  • 4 Ну и всё, если есть задача какая то создаётся тред.

Как задачи выбирать? Откуда брать. Хотя на лоре порой они сами рождаются то там то там можно из активных срачей идею брать и фигачить :D. Или своё. Вот например в опросе «Какой кусок кода больше ван нравится» к слову чёт опрос пропал из истории тоже вопрос простой, но развернулось широко, я даже сидел придумывал , код писал решения всякие интересные и полезные вроде как.

Типа такого как я раньше делал Happy Programming. Eposode 0x01 - нарисуй слоника ::) ?

Говори как называться будем и да задачи надо как то называть… Хммм пусть будут «клоки» «clock». Те кто задачи решают «клокеры» «сlockers» решения это «тики» «ticks».

Потом можно будет говорить «В 0xfa 12 клокеров 40 тиков сделали, клок был про создание коллекций данных на основе хештаблиц, наилучший тик выдал бисти, наилучший, но с использованием CPU расширений выдал анон» :D

Как то так :D Немного пафоса, сленга и псевдоилитарности не помешает, юморно прикольно, стильно молодёжно :D Это же игра по сути.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Как вариант — C_BATYAS, и это в качестве гимна. Хорошо бы ещё репозиторий запилить с папочками под каждый новый «эпизод». И обязательно нужно хаять остальные языки, чтобы адепты тоже подтягивались и свой хлам бенчили, или более элегантные реализации запиливали.

А задачки сами образуюся, если это кому-то интересно будет. Можно даже альтернативный батя-скор завести и список интересных тем BATYAS APPROVED.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Давай. Ток какую пока даже понятия не имею. Или придумаю такую что сам хер пойму как решать… нон оно наверное даже прикольнее будет. Тупить мне не привыкать :D

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от WitcherGeralt

Давай, тогда на следующей неделе постараемся какую-нибудь задачку родить, чтобы угареть на выходных

Видимо, не судьба. Пока Segmentation Fault (core dumped) не разлучит нас, как говорится.

Разорванный Флакон

anonymous
()

Ничего точно указать нельзя. Одну банальщину в тегах оставили.

Иди против системы, пиши теги в заголовке темы.

Nervous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.