Комментарии 120
идеальная модель, не более того. в реальности все обычно дольше.
Модель для того и существует, чтобы дать приблизительное, максимально близкое, описание чего-либо. Эти данные необходимы когда уже проведена полная оптимизация алгоритмов в Вашей программе. А цифры помнить точно не нужно. Важно понимать, что чтение с диска — это медленно, а передача по сети — еще медленнее и т. д.
>> Важно понимать, что чтение с диска — это медленно, а передача по сети — еще медленнее и т. д.
Пересылка 2Кб по сети со скоростью 1 Гб/с 20,000 нс
Произвольный доступ к жёсткому диску 10,000,000 нс
Пересылка 2Кб по сети со скоростью 1 Гб/с 20,000 нс
Произвольный доступ к жёсткому диску 10,000,000 нс
Скорость передачи по сети зависит от множества факторов, скорость чтения с винчестера таких факторов имеет гораздо меньше. Об этом говорит последняя строка в таблице. «Пересылка 2Кб по сети со скоростью 1 Гб/с 20,000 нс» — скорее всего идеальный вариант без маршрутизации и промежуточных машин на каком-нибудь стенде.
Да, тут речь, конечно, о непосредственно связанных машинах. Но с маршрутизацией и с промежуточными машинами без выхода в Интернет получается что-то ближе к «Передача сообщения туда/обратно в одном дата-центре: 500,000 нс». Всё равно на порядки быстрее чтения с жёсткого диска.
это если учитываь что тот сервер который данные отсылает, сам не работает с диском. Иначе будет скорость доступа к диску + скорость доступа по сети. )
странная у вас математика, чтобы данные передать, их нужно откуда-то получить и нужно это время приплюсовать.
опять же файловая система обладает кэшем и считывание может проходить со скоростью сравнимой со скоростью примерно как с оперативки.
цифры хорошие, только всегда нужно сделовать правилу — доверяй, но проверяй.
опять же файловая система обладает кэшем и считывание может проходить со скоростью сравнимой со скоростью примерно как с оперативки.
цифры хорошие, только всегда нужно сделовать правилу — доверяй, но проверяй.
Что-то мне подсказывает что редко бывает гигабитная сеть
Что-то мне подсказывает, что я сейчас возьму инструмент и пойду ее прокладывать.
У меня провайдер тоже обещает до 100 мб, а правительство обещает хорошую жизнь, а кредиторы обещают хорошие проценты… Я думаю Вы меня поняли =)
не думаю что каждый программист знает скорость передачи пакета из Калифорнии в Нидерланды и обратно :)
А я думал что каждый программист должен знать что 00000010 это 2 и т.д.
Любимое число 101(5) :)
вообще если это в коде си-подобного языка записать, то скорее всего 8 получится ;)
Как не странно я даже половину этих цыфр не знал.
> каждый программист
явно не веб-программист, ему это, по-моему, нафиг не упёрлось.
явно не веб-программист, ему это, по-моему, нафиг не упёрлось.
В CS нет такой специальности как веб-программист. Умение писать говнокод на php не делает человека программистом.
А умение писать говнокод на C++ — делает?
Тут нет даже намёка на CS. Зайдите хотя бы на википедию, программист это не обязательно учёный в CS.
И насчёт «говнокода в php» — это жуткий стереотип, в наше время полно хороших и качественных продуктов, нацеленных на web и выполненных на php.
И насчёт «говнокода в php» — это жуткий стереотип, в наше время полно хороших и качественных продуктов, нацеленных на web и выполненных на php.
Хоть люди и минусуют этот комментарий, но я соглашусь. Зачем программисту на PHP знать скорость обращения к кэшу L1? Он им не может воспользоваться, ибо даже простой $a=1; это десятки(может сотни и тысячи) операций «под капотом». Уверен, что даже «открытие мютекса» в PHP это далеко не один десяток операций (ибо все равно PHP нужно резолвить $mutex_id — это ж не просто указатель на память, а название переменной).
Далее, «Передача сообщения туда/обратно в одном дата-центре» — это мне кажется, сильно зависит от организации дата-центра. Какого размера сообщение, как соединены стойки, какое оборудование на пути, какова загруженность каналов, какая скорость сети?
И что вообще такое «обращение к главной памяти»? Это так RAM нынче называется?
Собственно эти цифры все вообще абсурдны при PHP программировании, запустите простой скрипт, который 100млн раз в цикле сделает примерно следующее: $b=$a; где $a будет либо пустой, либо равной 1МБ строке (по идее — это «чтение 1МБ из памяти» и замерьте ((microtime(1)-$start_microtime)/$number_of_loops) среднюю скорость выполнения.
Результаты у меня (nginx/php-fpm):
"$b=$a", при $a длиной 0 байт = 85ns;
"$b=$a", при $a длиной 1 МБ (str_repeat(«x», 1024*1024)) = 79ns.
Проверял несколько раз — да, чтение 1МБ из памяти быстрее происходит, чем чтение нуля байт!
Собственно, почему так происходит я точно не знаю, но вывод один — среда выполнения PHP делает слишком много операций (и, возможно, внутренних оптимизаций), чтобы заниматься там какими-то предсказаниями по поводу операций чтения из кэша L1.
Первые цифры полезны программистам на C (даже уже на Java думаю они менее полезны ибо там все же на виртуальной машине происходит выполнение).
Большая часть остальных цифр полезна программистам, которые разрабатывают приложения, работающие более чем на 3 физических серверах (а это менее 1% программистов на PHP, я так предполагаю).
99% программистов на PHP ради интереса можно знать, что:
1. чтение с диска примерно в 100 раз медленней, чем чтение из памяти;
2. даже простой mysql_query('SELECT 1') примерно в 1000 медленней, чем обращение к хэшу $array['item'].
Почему ради интереса? Да потому что большей частью все равно самые сильные оптимизации в PHP — это правильно расставленные индексы в базе данных и кэширование в memcached. А те, кто создавали mySQL/memcached знали как правильно использовать L1, L2 и т.п. От того, что PHP программист будет это знать — его соединение с mysql/memcached не ускорится. А по сути mySQL(и аналоги) — это то, что нужно 99% PHP программистов.
Статью бы надо переименовать в «Числа, которые должен знать каждый программист, работающий на близком к системному уровне»
Далее, «Передача сообщения туда/обратно в одном дата-центре» — это мне кажется, сильно зависит от организации дата-центра. Какого размера сообщение, как соединены стойки, какое оборудование на пути, какова загруженность каналов, какая скорость сети?
И что вообще такое «обращение к главной памяти»? Это так RAM нынче называется?
Собственно эти цифры все вообще абсурдны при PHP программировании, запустите простой скрипт, который 100млн раз в цикле сделает примерно следующее: $b=$a; где $a будет либо пустой, либо равной 1МБ строке (по идее — это «чтение 1МБ из памяти» и замерьте ((microtime(1)-$start_microtime)/$number_of_loops) среднюю скорость выполнения.
Результаты у меня (nginx/php-fpm):
"$b=$a", при $a длиной 0 байт = 85ns;
"$b=$a", при $a длиной 1 МБ (str_repeat(«x», 1024*1024)) = 79ns.
Проверял несколько раз — да, чтение 1МБ из памяти быстрее происходит, чем чтение нуля байт!
Собственно, почему так происходит я точно не знаю, но вывод один — среда выполнения PHP делает слишком много операций (и, возможно, внутренних оптимизаций), чтобы заниматься там какими-то предсказаниями по поводу операций чтения из кэша L1.
Первые цифры полезны программистам на C (даже уже на Java думаю они менее полезны ибо там все же на виртуальной машине происходит выполнение).
Большая часть остальных цифр полезна программистам, которые разрабатывают приложения, работающие более чем на 3 физических серверах (а это менее 1% программистов на PHP, я так предполагаю).
99% программистов на PHP ради интереса можно знать, что:
1. чтение с диска примерно в 100 раз медленней, чем чтение из памяти;
2. даже простой mysql_query('SELECT 1') примерно в 1000 медленней, чем обращение к хэшу $array['item'].
Почему ради интереса? Да потому что большей частью все равно самые сильные оптимизации в PHP — это правильно расставленные индексы в базе данных и кэширование в memcached. А те, кто создавали mySQL/memcached знали как правильно использовать L1, L2 и т.п. От того, что PHP программист будет это знать — его соединение с mysql/memcached не ускорится. А по сути mySQL(и аналоги) — это то, что нужно 99% PHP программистов.
Статью бы надо переименовать в «Числа, которые должен знать каждый программист, работающий на близком к системному уровне»
Имхо, цифры кагбэ говорят, что нефига заниматься оптимизацией обращения к кешам L1/L2, пока есть передача несжатых данных по сети, только и всего.
Чисто ради интересна — и как же это на PHP можно оптимизировать кэш L1/L2?
пардон, «интереса»
Не напрямую. Например, знание подобных цифр помогут в нужный момент понять (а лучше заранее), что увеличение количества серверов, например, вдвое не увеличит скорость работы проекта в два раза.
Выше там уже правильно написали — нет понятия «PHP-программист». Либо ты хороший программист, либо нет. А проект создается с использованием оптимальных для него технологий, в том числе учитывая стоимость разработки на них.
Выше там уже правильно написали — нет понятия «PHP-программист». Либо ты хороший программист, либо нет. А проект создается с использованием оптимальных для него технологий, в том числе учитывая стоимость разработки на них.
Ээ, а причем тут php? я думаю тут речь идет о более низкоуровневой разработке.
Хорошо. Нечего заниматься сжатием передаваемых по сети данных, пока присутствует некешированное чтение с жесткого диска. Это на PHP можно оптимизировать?
Цифры говорят, что нефига заниматься оптимизацией, пока профайлер не запустил.
Сорву, наверное, покровы, но во всех современных языках начиная с С++ инструкция $b = $a для строк копирует только указатель на строку, а не саму строку.
Чтобы вызвать копирование строки, добавьте в тест команду $b[0]=«a» или что-то вроде.
Чтобы вызвать копирование строки, добавьте в тест команду $b[0]=«a» или что-то вроде.
Конкретно этот пример про php не совсем корректен, посмотрите на тему php copy on write. Т.е. что для строки 0 байтов, что для строки 1 Мб при таком присвоении не происходит копирования (копирование будет при изменении значения переменной, а так — два имени имеют ссылку на одно значение). Полезная штука кстати — передача здоровенных массивов аргументами функции будет стоить примерно столько же, сколько передача инта, если массивы не меняются.
это конечно всё правильно вы говорите, но таки а почему бы и нет? в смысле на мой взгляд это гораздо более полезное знание чем знание порядка переменных в вызовах функций mysql_ хотябы потому что не написанно в каждой попавшейся доке
P.S.
у меня очень сильное ощущуение что я это где то уже видел на хабре
P.S.
у меня очень сильное ощущуение что я это где то уже видел на хабре
> а это менее 1% программистов на PHP
достаточно много веб-программистов работают над высоконагрузочными проектами, которые имеют в инфраструктуре сотни и тысячи серверов — цифры вполне полезные и отвечают на приличное количество вопросов по оптимизации.
достаточно много веб-программистов работают над высоконагрузочными проектами, которые имеют в инфраструктуре сотни и тысячи серверов — цифры вполне полезные и отвечают на приличное количество вопросов по оптимизации.
Нижняя часть таблицы и веб-программисту пригодится.
Давайте попробую свою версию чисел для программиста:
* Время отведённое на проект
* Уровень жадности менеджеров
* Количество шума и изменений в ТЗ
* Время затрачиваемое на метафизическое превращения проекта в казначейские билеты у вас на руках
* Дату рождения подруги/жены
Остальное — суета. Ну а более серьёзно — время затрачиваемое на обращение к чему либо в железе волнует далеко не каждого программиста. Мало кто вообще может «опуститься» до системщика с верхних уровней прикладников. Я думаю что никому из моих знакомых программистов цифры из вашей таблицы никогда в жизни не пригодятся. Если уж прикидывать время то как отношение одного к другому — чтение с жёсткого быстрее чтения с сети в десять раз (ведь тоже зависит от сети и от диска).
* Время отведённое на проект
* Уровень жадности менеджеров
* Количество шума и изменений в ТЗ
* Время затрачиваемое на метафизическое превращения проекта в казначейские билеты у вас на руках
* Дату рождения подруги/жены
Остальное — суета. Ну а более серьёзно — время затрачиваемое на обращение к чему либо в железе волнует далеко не каждого программиста. Мало кто вообще может «опуститься» до системщика с верхних уровней прикладников. Я думаю что никому из моих знакомых программистов цифры из вашей таблицы никогда в жизни не пригодятся. Если уж прикидывать время то как отношение одного к другому — чтение с жёсткого быстрее чтения с сети в десять раз (ведь тоже зависит от сети и от диска).
А эти цифры не должны зависеть от реализации языка программирования или, скажем, от мощности конкретного компьютера?
А как же 42? Просветлённому программисту нужно знать только это число.
Вам смешно, а меня это число преследует. Жил в 2 квартирах с таким номером. Теперь живу в 42-ом доме -_-
У меня девченки знакомой, это число(номер билета) на экзамене в школу попалась, в колеедже во вступительном, и в отпускном в колледже. Ана мне с такими эмоциями все это рассказывала. Сам кстати тоже жил в доме № 42.
Но вот не знал что это какое-то особое число, да слабенький я еще программист.
Но вот не знал что это какое-то особое число, да слабенький я еще программист.
и с русским тоже слабовато.
Это уже не смешно…
Открытие/закрытие мьютекса 25 нс
Обращение к главной памяти 100 нс
тут всё правильно?
Обращение к главной памяти 100 нс
тут всё правильно?
Cache?
как можно закешировать изменение состояния?
Как и все другие переменные, которые хранятся в кеше.
хм, а смысл, если при каждом успешном открытии/закрытии, которых должно быть большинство, значение меняется?
Чтобы к ОЗУ не обращаться. ru.wikipedia.org/wiki/кеш
ну-ну, если запись немедленная, то обращение к ОЗУ будет.
А если отложенная и L2 разделен для ядер, то будет весело когда процессы на разных ядрах один семафор запросят :)
А если отложенная и L2 разделен для ядер, то будет весело когда процессы на разных ядрах один семафор запросят :)
Почитайте на эту тему, перед тем как писать. ru.wikipedia.org/wiki/Когерентность_кэша
Ну если на момент начала операции вы уже в ринг0, то может быть
Вы о чем? Очевидно, что под временем операции имелось в виду lock/unlock свободного мьютекса, иначе бы пришлось учитывать время на которое он заблокирован. Либо имеется в виду неблокирующая попытка взять мьютекс. Все это можно реализовать, и обычно и реализуется, операцией compare_and_swap которая выполняется в пространстве пользователя. О каком ring0 Вы говорите?
Кажется мы с вами в совершенно разных контекстах.
Мой мютекс виндовый, и он медленный. Что такое ваш мютекс?
Мой мютекс виндовый, и он медленный. Что такое ваш мютекс?
Как же хорошо, что у программистов гугла нет доступа к моему L1 cache.
Хороший программист должен знать намного меньше цифр. Вот они:
— питаться нужно по крайней мере 3 раза в день
— спать нужно как минимум 6 часов в сутки
Все остальное приложится =)
— питаться нужно по крайней мере 3 раза в день
— спать нужно как минимум 6 часов в сутки
Все остальное приложится =)
Ерунда, для этого есть офис-манагеры. Они должны в нужных местах выкладывать еду, а также через какое-то время после прихода программиста на работу, например через 15 часов, выгонять его домой спать. Не надо, понимаешь, занятых людей грузить всякими приземленными пошлостями.
А кто при этом подложит еду манагеру и выгонит его домой?
Сударь, вы балбес =) Офис манагеры как правило, тетьки, значит, они могут быть блондинками, страдать хроническим пмс и еще всякой фигней… Т.о., прогер может сдохнуть от голода и недосыпа. Если вещи, которые ни кому нельзя доверять =)
Где найти таких? Дайте 2 :)
И еще 2012. Т.к. будет большой праздник православных программистов: 1024 года со дня крещения Руси :)
Я только недавно до этого дошел.
степени двойки? остальное не надо.
я как-то пожалел о том, что не знал числа Каталана
ru.wikipedia.org/wiki/Числа_Каталана
ru.wikipedia.org/wiki/Числа_Каталана
Где-то видел более запоминающийся вариант. Типа, достать из кэша — равнозначно взять булочку со стола перед собой. Взять из памяти — сходить за булочкой в соседнюю комнату. Взять с диска — спуститься на первый этаж, перейти улицу, купить в магазине, и вернуться обратно…
Не смог найти первоисточник, к сожалению.
Не смог найти первоисточник, к сожалению.
мьютекс?
>>должен знать каждый программист
Программист может знать, программист может и не знать…
Но программист точно никому ничего не должен.
Программист может знать, программист может и не знать…
Но программист точно никому ничего не должен.
Прочитав заголовок стал ожидать рассказ о 0x5f3759df и иже с ним. А оно вон как.
Сейчас, когда хабралюди полезли проверять время передачи пакета, то это число стало уже совсем другим
я вот блин недавно забыл чуть ли не самую главную цифру, которую должен знать программист… размер своей зарплаты
%username% должен знать и уметь VTune, но если не судьба — то да, эту шпаргалку
НЛО прилетело и опубликовало эту надпись здесь
Передача пакета из Москвы в Нидерланды и обратно Почтой России
Exception in thread "main" java.lang.ArithmeticException: integer overflowЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Числа, которые должен знать каждый программист