Як можуть бути точними "затримки, які повинен знати кожен програміст" Джеффа Діна в контексті різної реалізації апаратних засобів?

Я маю на увазі цю діаграму затримок , приписану Джеффу Діну в Google.

Те, що я не розумію, полягає в тому, чи не змінюються ці номери від одного обладнання до іншого? Як вони можуть бути точними для всіх типів оперативної пам'яті, процесора, материнської плати, жорсткого диска тощо?

Ці цифри (перелічені також у програмі Norvig’s Teach yourself Programming за 10 років ) є приблизними, корисними лише як (порядок) масштабу.

Насправді сьогоднішнє обладнання (принаймні для настільних ПК та ноутбуків) не відрізняється навіть від дешевого ноутбука на 300 євро та робочої станції високого класу в 10 тисяч євро. Швидкість змінюється приблизно в 2 або 4 рази. Така робоча станція може мати більший диск, більше ядер, кеш-пам’яті та оперативної пам’яті. Однак це не має особливого впливу на необроблені однопоточні характеристики.

Подивіться на деякі дані на http://openbenchmarking.org/ або в деяких порівняльних процесорах.

Так званий закон Мура буде вмирати . Мій робочий стіл віком 3+ років вдома (i3770K) можна було б замінити (сьогодні, в березні 2016 року) деяким i6700, що лише на 20% швидше.

Цифри не мають бути точними. Саме співвідношення між порядками між рівнями мають значення.

Однак, коли з’являється руйнівна технологія (наприклад, хмарні обчислення, 10 Гб / 100 ГБ ефірної мережі, новий модуль ядра мереж, мережі зберігання SSD, віртуалізація та контейнерізація), ці номери можуть бути визнані недійсними через появу, зникнення або переміщення нових рівнів.

Програмування на дуже високому рівні - де всі обчислення, мережа, розбір тощо виконуються за допомогою бібліотек, які не були написані вами самостійно, знаючи показники ефективності операцій низького рівня, можливо, не дуже допоможе, оскільки ваша можливість покращити кожен Продуктивність бібліотеки досить обмежена або відверта неможлива.

Натомість уважно прочитайте документацію, що стосується продуктивності кожної бібліотеки. Якщо бібліотека не має таких, запитайте їх - зробіть це проблемою. Або навчитися правильно орієнтувати програмне забезпечення.

Базове розуміння номерів затримки важливо, коли вас наймає компанія, яка розробляє та виготовляє програмні компоненти. Порівняйте це з компанією, яка розробляє та виготовляє автомобілі та кожен компонент, що міститься в ній, - прислів’я "винаходити колесо" (гума, тиск в шинах, протектори тощо).

Більшість програмних компаній не працюють на рівні компонентів - цілі функціональні програмні системи можуть бути побудовані з складання компонентів. Цим програмним компаніям не потрібно зосереджуватися на тому, як розробляти компоненти за термінами; натомість їм потрібно оцінити якість обраних компонентів.

Підсумовуючи, (1) цілком можливо, що вам не потрібно знати затримки; (2) якщо ви не хочете наймати компанію, яка виробляє програмні компоненти (бібліотеки), для продажу або для внутрішнього використання (як у деяких найбільших програмних компаній світу), (3), якщо вам потрібні ці номери, ваша робота - робити еталони самостійно, науково правильним способом, інакше ви не повинні працювати над програмними компонентами.

Ніхто не стверджував, що ці номери точні для будь-якого обладнання.

Однак вони набагато, набагато точніші, ніж сліпі здогадки. На чому багато людей, на жаль, ґрунтуються на своєму коді.

Вони не зовсім точні, і вони насправді не призначені.

Вони (особливо у менших числах) трохи кращі, ніж просто порядок. Ще один момент полягає в тому, що це може допомогти зрозуміти, які речі знаходяться близько один від одного, що люди іноді неправильно трактують як набагато далі, ніж є насправді. Одним із очевидних прикладів, мало хто припускає, що неправильне передбачення галузей часто є великою справою. Це може бути велика справа , якщо це повторюється багато, але це не обов'язково варто жертвувати величезні суми в будь-якому місці і скрізь тільки , щоб отримати краще пророкування розгалужень (наприклад, якщо ви читаєте з основної пам'яті, або навіть L2 кеш , щоб поліпшити пророкування розгалужень, це, мабуть, чистий збиток).

У той же час, так, порядкові розміри можуть бути найкориснішими частинами. Наприклад, для доступу до даних із основної пам'яті потрібно приблизно в 100 разів більше, ніж з реєстру. Так, на одній машині це може бути приблизно в 97 разів довше, а на іншій - ближче до 127 разів довше. Це майже напевно буде ближче до 100, ніж до 10 або 1000, хоча.

Особисто я схильний вважати більшість із них схожими на острови, скажімо, в Тихому океані. Швидкість жорсткого диска (наприклад) може бути островами Гавайських островів. Швидкість SSD - Філіппінські острови. Це показує карту в досить малому масштабі, щоб кожен з них виглядав як одна точка. Якщо ми збільшуємо масштаб, це явно не вірно - але відстань між двома ланцюгами в багато разів більша, ніж відстані між островами в будь-якому ланцюжку.

Звичайно, цифри не можуть бути точними для кожної машини. І я здогадуюсь, ніколи цього не мали. Однак вони показують різницю в порядку величини між декількома видами операцій.

Ви можете знайти ще кілька корисних посилань та даних у коментарях до пов’язаних даних.