Как «запаздывающие числа», которые должен знать каждый программист, Джеффа Дина могут быть точными в контексте различных аппаратных реализаций?

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

Вещь, которую я не понимаю, состоит в том, не меняются ли эти цифры от одного набора оборудования к другому? Как они могут быть точными для всех типов оперативной памяти, процессора, материнской платы, жесткого диска и т. Д.?

Эти числа (также перечисленные в 10-летней программе Norvig's Teachself Programming ) являются приблизительными и используются только в качестве (порядка) величины.

На самом деле, современное оборудование (по крайней мере, для настольных компьютеров или ноутбуков) не сильно отличается даже между дешевым ноутбуком за 300 евро и высокопроизводительной рабочей станцией за 10 тысяч евро. Скорость варьируется примерно в 2 или 4 раза. Такая рабочая станция может иметь больший диск, больше ядер, кэш и оперативную память. Тем не менее, это не оказывает большого влияния на производительность однопоточного процессора.

Посмотрите на некоторые цифры на http://openbenchmarking.org/ или некоторые компараторы ЦП.

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

Числа не должны быть точными. Важно соотношение между порядками величин между уровнями .

Однако, когда появляется разрушительная технология (например, облачные вычисления, Ethernet 10 ГБ / 100 ГБ, новый сетевой модуль ядра, сети хранения SSD, виртуализация и контейнеризация), эти числа могут быть аннулированы из-за появления, исчезновения или перемешивания новых уровней.

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

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

Наличие базовых знаний о числах задержек важно, когда вы наняты компанией, которая разрабатывает и производит программные компоненты. Сравните это с компанией, которая разрабатывает и производит автомобили и каждый компонент, содержащийся в нем, - пресловутое «изобретение колеса» (резина, давление в шинах, протекторы и т. Д.)

Большинство компаний, занимающихся разработкой программного обеспечения, не работают на уровне компонентов - целые функциональные программные системы могут быть построены из объединения компонентов. Этим компаниям-разработчикам программного обеспечения не нужно сосредотачиваться на том, как проектировать компоненты с точки зрения задержек; вместо этого им необходимо оценить качество компонентов, которые они выбирают.

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

Никто не утверждал, что эти цифры являются точными для любого оборудования.

Однако они намного, намного точнее, чем слепые догадки. На этом, к сожалению, многие люди основывают свой код.

Они не совсем точны, и на самом деле они не предназначены для этого.

Они (особенно на меньших числах) немного лучше, чем просто на порядок. Другой момент заключается в том, что он может помочь понять, какие вещи близки друг к другу, что люди иногда неверно истолковывают как находящиеся намного дальше друг от друга, чем они есть на самом деле. В качестве одного очевидного примера, немало людей предполагают, что ошибочное прогнозирование ветвей часто является большой вещью. Это может быть большое дело , если это повторяется много, но это не обязательно стоит жертвовать огромные суммы в любом месте и везде только , чтобы получить лучшее предсказание ветвлений (например, если вы читаете из основной памяти, или даже L2 кэш , чтобы улучшить предсказание ветвлений, это наверное чистый убыток).

В то же время, да, порядки величины могут быть самыми полезными частями. Например, для доступа к данным из основной памяти требуется примерно в 100 раз больше времени, чем из регистра. Да, на одной машине он может быть примерно в 97 раз длиннее, а на другой - ближе к 127 раз. Это почти наверняка будет ближе к 100, чем к 10 или 1000, хотя.

Лично я склонен думать, что большинство из них похоже на острова, скажем, в Тихом океане. Скорости жесткого диска (например) могут быть Гавайскими островами. Скоростями SSD являются филиппинские острова. Это показывает карту в достаточно маленьком масштабе, чтобы каждый из них выглядел как одна точка. Если мы увеличим масштаб, это явно не так - но расстояние между двумя цепями во много раз больше, чем расстояния между островами в любой из цепей.

Конечно, цифры не могут быть точными для каждой машины. И я думаю, что они никогда не должны были. Тем не менее, они показывают различия в порядке величины между несколькими видами операций.

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