Сегодня чего-то где-то всплыла тема про Джеффа Дина.
Наткнулся на любопытную у него вещь -- тут.

Суть:
L1 cache reference: 0.5 ns
Branch mispredict: 5 ns
L2 cache reference: 7 ns
Mutex lock/unlock: 100 ns
Main memory reference: 100 ns
Compress 1K bytes with Zippy: 10,000 ns
Send 2K bytes over 1 Gbps network: 20,000 ns
Read 1 MB sequentially from memory: 250,000 ns
Round trip within same datacenter: 500,000 ns
Disk seek: 10,000,000 ns
Read 1 MB sequentially from network: 10,000,000 ns
Read 1 MB sequentially from disk: 30,000,000 ns
Send packet CA->Netherlands->CA: 150,000,000 ns

Говорят, что собрано отсюда.

Если баян, то снесите топик.

Здравствуйте, Sharov, Вы писали:


S>Сегодня чего-то где-то всплыла тема про Джеффа Дина.

Кто такой Джефф Дин?

Здравствуйте, Sharov, Вы писали:


S>Сегодня чего-то где-то всплыла тема про Джеффа Дина.
S>Наткнулся на любопытную у него вещь -- тут.

You must sign in to read past the first answer.

А ссылки не для копирастов, извините, нет?

S>Суть:
S> L1 cache reference: 0.5 ns
S> Branch mispredict: 5 ns
S> L2 cache reference: 7 ns
S> Mutex lock/unlock: 100 ns
S> Main memory reference: 100 ns
S> Compress 1K bytes with Zippy: 10,000 ns
S> Send 2K bytes over 1 Gbps network: 20,000 ns
S> Read 1 MB sequentially from memory: 250,000 ns
S> Round trip within same datacenter: 500,000 ns
S> Disk seek: 10,000,000 ns
S> Read 1 MB sequentially from network: 10,000,000 ns
S> Read 1 MB sequentially from disk: 30,000,000 ns
S> Send packet CA->Netherlands->CA: 150,000,000 ns

S>Говорят, что собрано отсюда.

S>Если баян, то снесите топик.

Баян или нет — не знаю, но сами по себе цифры достаточно банальные и могут быть найдены где угодно, а практически интересны только основания для первых цифр (скорости доступа к L1/L2 и близкие к этому эффекты). Кстати, насчёт мьютекса — это та статистика, которая хуже лжи: например, если с ним постоянно возится один и тот же процессор, то цифры будут существенно меньше.

Здравствуйте, Sharov, Вы писали:


S>Если баян, то снесите топик.
лажна все это. доступ к кэшу это как мин. две цифры -- пропускная способность и латентность.
кэш-линейка имеет более одного порта чтения/записи, т.е. поддерживается одновременная запись/чтение разных ячеек, если они находятся в одной кэщ линейке.
запросы на чтение/запись ставятся в очереди и планировщик их разрулирвает, причем весьма хитрым образом. в частности, есть отдельная очередь на запись, которая шурует мимо кэша если только проц уверен, что никто в очереди не собирается обращаться к записываемым ячейкам.

впрочем, это мелочи. самое главное это _две_ независимых характеристики прозводительности. латентность указываает сколько времени ждать от подачи запроса (на чтение, скажем) до получения ответа, а пропускная способность -- мак. возможное кол-во обработанных запросов.

очень упрощенно:
// плохой код
а = *(б)
а = а + 666
с = *(б+4)
с = с + 999


// хороший код
а = *(б)
с = *(б+4)
а = а + 666
с = с + 999

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

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

причем, латентность/пропускная способность была еще на самых древних ЦП даже еще когда ИБМ не был персоналкой. конвейер был еще на БЭСМ. так что знать нужно матчасть, а не конкретные цифры, которые к тому же неверные.

Здравствуйте, мыщъх, Вы писали:

S>>Если баян, то снесите топик.
М>лажна все это. доступ к кэшу это как мин. две цифры -- пропускная способность и латентность.

Так... С кэшем разобрались. Как на счет остальных уровней?

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

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

Здравствуйте, Sharov, Вы писали:

Джеффа Дина.
S>Наткнулся на любопытную у него вещь -- тут.

Что за мерзкий ресурс. Вначале надо было войти из под gmail (а если у меня нет?), чтобы доказать, что мне больше 13 лет. Там что-то неприличное что ли или одна расчленёнка?
После этого ещё несколько тупых диалогов. Жесть, скоро 2 НДФЛ заполнять придётся, чтобы на сайт зайти.

Здравствуйте, alzt, Вы писали:

A>Что за мерзкий ресурс. Вначале надо было войти из под gmail (а если у меня нет?), чтобы доказать, что мне больше 13 лет. Там что-то неприличное что ли или одна расчленёнка?
A>После этого ещё несколько тупых диалогов. Жесть, скоро 2 НДФЛ заполнять придётся, чтобы на сайт зайти.

Полностью согласен! С ссылкой ложанулся. Квора на редкость мерзкий ресурс.
И таки да, баян, причем довольно древний -- вот эту ссылку надо было дать.

Здравствуйте, QrystaL, Вы писали:

QL>Кто такой Джефф Дин?

1) http://www.rsdn.ru/forum/humour/5340814.1

Автор: Барбос
Дата: 23.10.13

2) в вики вроде неплохо о нем написано.
3) вот ссылка на статью про него

Вкратце: это дядька, который задизайнил и имплементировал (с коллегой) всю map/reduce-овскую архитектуру
гугла.

Здравствуйте, Sharov, Вы писали:

S>Полностью согласен! С ссылкой ложанулся. Квора на редкость мерзкий ресурс.
S>И таки да, баян, причем довольно древний -- вот эту ссылку надо было дать.

О, тут уже хотя бы для мьютекса цифра получше.

Здравствуйте, мыщъх, Вы писали:

М>лажна все это. доступ к кэшу это как мин. две цифры -- пропускная способность и латентность.
М>кэш-линейка имеет более одного порта чтения/записи, т.е. поддерживается одновременная запись/чтение разных ячеек, если они находятся в одной кэщ линейке.
М>запросы на чтение/запись ставятся в очереди и планировщик их разрулирвает, причем весьма хитрым образом. в частности, есть отдельная очередь на запись, которая шурует мимо кэша если только проц уверен, что никто в очереди не собирается обращаться к записываемым ячейкам.
М>впрочем, это мелочи. самое главное это _две_ независимых характеристики прозводительности. латентность указываает сколько времени ждать от подачи запроса (на чтение, скажем) до получения ответа, а пропускная способность -- мак. возможное кол-во обработанных запросов.

Ты рассуждаешь как архитектор какого-нибудь процессора. Для них эти параметры имеют жизненно важное значение.
Обычно, программисту нужна цифра "сверху", т.е. чтение данных из L1 кэша, которые там, в L1 кэше находятся, занимает столько то.

М>причем, латентность/пропускная способность была еще на самых древних ЦП даже еще когда ИБМ не был персоналкой. конвейер был еще на БЭСМ. так что знать нужно матчасть, а не конкретные цифры, которые к тому же неверные.

Цифры взяты из книги Hennesy&Patterson'а, которая является классикой для архитектуры процессора.

Здравствуйте, Sharov, Вы писали:

S>Суть:
S> L1 cache reference: 0.5 ns
S> Branch mispredict: 5 ns
S> L2 cache reference: 7 ns
S> Mutex lock/unlock: 100 ns
S> Main memory reference: 100 ns
S> Compress 1K bytes with Zippy: 10,000 ns
S> Send 2K bytes over 1 Gbps network: 20,000 ns
S> Read 1 MB sequentially from memory: 250,000 ns
S> Round trip within same datacenter: 500,000 ns
S> Disk seek: 10,000,000 ns
S> Read 1 MB sequentially from network: 10,000,000 ns
S> Read 1 MB sequentially from disk: 30,000,000 ns
S> Send packet CA->Netherlands->CA: 150,000,000 ns

похоже на письмо счастья.
кстати, кому должен каждый программист?

Здравствуйте, neFormal, Вы писали:

F>кстати, кому должен каждый программист?
риторический вопрос...

Здравствуйте, Sharov, Вы писали:

F>>кстати, кому должен каждый программист?
S>риторический вопрос...

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

Здравствуйте, 0x8000FFFF, Вы писали:

FFF>Ты не контролируешь попадание и исполнение своего кода в кеше на ядре...

открой для себя профайлер от интела — будешь сильно удивлён.
в некоторых местах просто поменяв местами чтение из папись можно добиться +20% производительности


FFF>Ты можешь надеяться, но гарантий никаких...
гарантии дают иструкции сериализации