понедельник, 15 января 2018 г.

Intel Core architecture

        Волевым усилием заставил себя дочитал до конца "The Architecture of the Nehalem Processor and Nehalem-EP SMP Platforms" by Michael E. Thomadakis.
Читается довольно тяжело, над каждой страницей приходится думать. Но результат того стоит. Признаться этот whitepaper перевернул мое представлене о современных интеловских процессорах. Раньше в моей голове были отдельные прямоугоньки "ядра", и что внутри там какая "мульти скалярная архитектура". Но что именно под этими бла-бла-бла и прямоугольниками скрываеться я понятия не имел. После прочтения этого документа я понял только одно-мы не имеем ни малейшего представления даже о сотой доли процессов происходящих внутри куска кремния под названием CPU. В общем я всем рекомендую нагуглить этот whitepaper и прочитать. Да, процессоры построенные именно на  Nehalem архитектуре уже давно не выпускаются, после нее уже было выпущено куча новых архитектур (Intel выпускает новую архитектуру каждые два года), но все они являются развитием идей освященных в данной работе.
    Итак что же меня больше всего поразило:
- Понимание того как на самом деле работает hyper threading. Какие ресурсы внутри ядра деляться статически("по-ровну"), я какие становяться разделяемыми.
- Какие ресурсы являются общими для всех ядер одного CPU
- NUMA архитектура, протоколы отвечающие за обеспечение целостности CPU Cache. Вообще я пребываю в шоке от того сколько всего наворочено внутри современных интеловских процессоров. Целые протоколы синхронизации реализованы в кремние. 
- Все что мы знали про регистры процессора(AX, DX, DS и тд) было правдой только 20 лет назад. Сейчас есть только пулл теневых (не описанных в архитектуре регистров) и блок внутри CPU ядра который вешает на них алиасы. 
- NUMA доступ к памяти. Это все оказываться очень не просто. 
- Цена miss-prediction, цена L1, L2, L3 cache miss. Цена доступа к локальной памяти (памяти в твоей NUMA-зоне), цена доступа к паямти в другой NUMA зоне.
Вообще сложность алгоритмов реализованных в кремнии/микрокоде конечно зашкаливает. Особенно если учесть что цена ошибки для вещей сделанных в кремнии очень высока (представьте что у вас  "релиз" - раз в два года). 

вторник, 26 декабря 2017 г.

Про производительность PWA и single page приложений

         Меня давно посещала мысль что все эти PWA/single page application и переиспользование JS кода это утопия. И эта утопия достижима только если вы работаете над государственным проектом и вам насрать на performance budget. А как только у вас появляются реальные требования по производительности то выяснится что стратегии оптимизации client side JS и server side JS - совсем разные, можно сказать противоположные. 
         К примеру в этой статье  https://habrahabr.ru/post/345212/.com[perevod]-vy-mozhete-sebe-eto-pozvolit - наглядно доказано что написать хорошее PWA/single page application это очень сложно. Я давно подозревал что это именно так, что обеспечение быстрой первой загрузки - это пиздец какая проблема, но у меня не было данных чтобы это доказать. Теперь есть. 
         https://hpbn.co/ - High Performance Browser Networking by  Ilya Grigorik - надо будет обязательно прочитать.

понедельник, 25 декабря 2017 г.

Exceptions в Java

     Многие критикуют Golang за отсутсвие Exceptions. Якобы из-за этого пишется очень много кода по обработке ошибок. С одной стороны это правда, этот код писать нужно. Ошибка сама не всплывет вверх по стеку, поэтому как минимум if + return написать придется. Но с другой стороны этот подход оказывается оправданным для performance critical code. В этой статье - http://java-performance.info/throwing-an-exception-in-java-is-very-slow/  анализируется производительность Java Exceptions. Оказывается бросить исключение это пиздец как медленно  - 1-5 микросекунд. И для performance critical кода предлагается кэшировать исключения. По-моему это костыль хуже некуда. Либо возвращать кастомные объекты со строкой сообщение об ошибке внутри. Это тот же самый error в Golang. В общем когда смотришь на Java с опытом использования Golang - то все выглядит совсем не так радужно как это выглядело раньше. 

Коллекции в Java

      В своем недавнем посте я разнес в щепки стандартную реализацию HashMap в  Java. Оказывается не все так плохо. Не я один считаю что стандартный HashMap отстой, и Java коммьюнити написало альтернативные варианты реализации HashMap.  В http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/ проведено неплохое сравнение этих реализаций. Чемпионами оказались fast utils и  Колобок! В общем пошел читать исходники fast utils, буду учиться писать на Java у настоящих мужиков.

среда, 20 декабря 2017 г.

Golang sync.Map

      sync.Map в появившийся в Golang 1.9 оказался довольно занятной штуковиной. Я посмотрел видео с конференции:
 Перечитал еще раз слайды - https://github.com/gophercon/2017-talks/blob/master/lightningtalks/BryanCMills-AnOverviewOfSyncMap/An%20Overview%20of%20sync.Map.pdf но все равно не мог четко понять - в каких случаях стоит использовать sync.Map а в каких обычный map[] + mutex. Может недостаточно понятно написано, может просто я такой одаренный. В общем мне чтобы разобраться нужно залезть в исходники, что я собственно и сделал - https://golang.org/src/sync/map.go?s=822:2269#L16
          Итак под капотом sync.Map находятся две map[] - readonly map и dirty map. Readonly map используется для быстрого чтения/записи уже существующих значений. В readonly map храниться не само значение а указатель на него. Для чтений значения используется  atomic.LoadPointer(), для записи - atomic.CompareAndSwapPointer(). Это так называемый fastpath, то есть собственно для чего все и затевалось. И используем мы этот fastpath если пишем или читаем значения по уже существующим ключам. Все остальное - происходит уже не так быстро. В случае если мы вставляем новое значение - оно попадает в dirty map. Все операции с dity map происходят с заблокированным мютексом. После какого-то количества cache miss - попыток чтения новых значений из readonly map происходит промоушен dirty map до readonly map.  После этого все недавно добавленные ключи можно будет читать писать без блокировки. 
        Итого: читаем/пишем по существующим ключам очень быстро (сильно быстрее map + mutex),  потребляем в 2 раза больше памяти на указатели/хэш таблицы(dirty map также хранит все ключи из readonly map). Но размер значений тут никакой роли не играет, так как мы не храним значения а только указатели на них.  Добавление новых ключей и look up по вновь добавленным ключам происходит сильно медленнее обычной map + mutex потому что появляется дополнительный indirection level(указатели), и сами операции с ними - atomic, а это значит много memory barrier-ов.    

вторник, 19 декабря 2017 г.

Проникновение ИТ в быт

     В очередной раз убеждаюсь что по некоторым параметрам Китай уже далеко впереди планеты всей. Один из эти параметров - это проникновение ИТ в быт, в традиционные отрасли бизнеса не связанные с ИТ. Почему-то в Европе да и у нас - ИТ (за небольшим исключением) сосредоточено вокруг интернета и "около интернетных" областей деятельности. Такие области деятельности как ресторанный бизнес вообще  ИТ вообще не сильно затронуло - за исключением разве что кассового аппарата. Здесь в Ханчжоу во многих ресторанах на уголок стола приклеен QR код, отсканировав который в AliPay приложении  ты можешь сразу увидеть меню, сделать заказ, а когда покушаешь - и сразу оплатить его. Причем люди сидящие за одним столом могут видеть что заказывают другие, и один человек может оплатить за всех. В некоторых местах бумажного меню вообще нет, в принципе. А нахера оно если у каждого есть смартфон и AliPay ??
         Тоже самое с такси - все без исключения таксисты принимают AliPay. Многие даже не хотят с наличкой связываться вообще, требуют AliPay. У нас только ленивый не потешается над платежной системой МИР. А китайцы сделали себе UnionPay и в ус не дуют. Международные кредитные карточки мало где принимают. В основном только в гостиницах и аэропортах. Ну еще из банкомата можно наличку снять. А так - либо UnionPay, либо AliPay. 

Нанкин (Nanjing)

     На выходных довелось побывать в южной столице Китая - Нанкине. Этот город был столицей поднебесной до того как ее перенесли в северную столицу - Пекин. Сейчас Нанкин это средний по китайским меркам город, что-то около 8 миллионов житилей. В нем расположены довольно много достопримечательностей: гробницы времен династии Мин, мавзолей Сунь Ятсена, древние крепостные стены. Много парков и озер. Несмотря на размер оставляет впечатление довольно провинциального города. Не китайскую еду или кофейню найти очень проблематично. Зато женщины там заметно красивее тех что я наблюдаю в Ханчжоу или Шанхае.