Роман Єлізаров: «Половина наукових робіт з Concurrency — повна нісенітниця!»

Добрий день, це «Без слайдів. В гостях у мене побував Роман Єлізаров, Java Champion, експерт з Java і багатопоточності (а з недавнього часу ще й з фінансової математики), спікер численних конференцій, голова журі Північно-Східного Європейського регіону ACM-ICPC, найпрестижнішої в світі олімпіади з програмування, лектор в ІТМО і, нарешті, VP за технологіями в компанії Devexperts. Загалом, «людина і пароплав».

У розмові ми торкнулися наступні теми:
  • що таке фінансова математика і як її вчити;
  • як влаштований софт для фінансової індустрії;
  • як у компанії Devexperts з'явилася дослідна лабораторія з багатопоточності;
  • куди розвивається Concurrency, і що буде в моді найближчим часом;
  • як всесвітня олімпіада з програмування прийшла в Росію.




Текстова версія — під катом.


Що таке фінансова математика, і як її вчити
— Перед початком інтерв'ю ти розповів, що почав займатися фінансовою математикою. Як і чому ця тема зацікавила тебе?

— Стикнувся з цією темою роботи — ми багато пишемо всякого софта для фінансової індустрії. І деколи приходять клієнти, які починають питати: «чи Є у вас це? Чи є у вас ось те?». І при цьому різні розумні слова говорять, половину яких ми не знаємо. Ось так я і зацікавився.

Спочатку намагався вчитися сам за підручниками — нічого не виходило. Потім вирішив систематизувати процес, пішов системно вчитися. І з-за цього в минулому році не з'являвся ні на яких конференціях. Замість цього сидів під великою горою підручників. Та й досі у мене книжкова полиця забита книжками з фінансової математики, а не по темі concurrency, яка на час відійшла на задній план. Звичайно, я продовжую їй займатися і вчити, але всі вивчення нового по concurrency відійшло на другий план.

— Наскільки багато у сучасній фінансовій індустрії саме математики?

— Дійсно багато. В основному, все це зав'язано на складні фінансові інструменти. Великі організації, банки постійно торгують чимось складним. І щоб оцінити ризики складного фінансового інструменту, потрібна досить нетривіальна математика.

Ось, наприклад, така проста річ, як моделювання Монте-Карло. Вона будь-якому програмісту зрозуміла: накидав випадкових чисел, склав, отримав. Начебто, з точки зору програмування це виглядає дуже просто. Але з точки зору математики зрозуміти, як правильно зробити, де саме треба правильно помножити або поділити, щоб результат мав відношення до дійсності, — це нетривіальна часом завдання.

— Розкажи, що таке взагалі фінансова математика? З якими областями тієї математики, яку всі ми вчили у ВУЗах, вона стикається?

— В основному, це математичний аналіз, теорія ймовірностей і така її сфера, яку мало хто вивчає, — стохастичні процеси, типу інтеграла Іто. Їх начебто навіть викладають всім потрошку, але дають лише базу. Нещодавно я розмовляв зі студентом матмеха Спбду, він розповів, що прослухав курс просунутої теорії ймовірностей. Але навіть там дуже поверхово про це розповідають. Якщо цього де вчать, то або у спеціалізованих навчальних закладах, типу ВШЕ, або на дуже спеціалізованих кафедрах. І дуже небагато випускників це знають. А якщо займатися складними фінансовими інструментами – то без цього знання нікуди.

— Я пам'ятаю, ти розповідав, що вчишся в Лондоні?

— Так, це дистанційне навчання — я туди в підсумку жодного разу так і не з'їздив. Там основна фішка в тому, що, по-перше, тобі підручники підібрані дуже хороші. До речі, знайти хороший підручник з будь-якого предмету — це диво. Коли я починав вчити студентів того ж concurrency, у мене було кілька підручників, на які я випадково натрапив і вони мені так сподобалися, що у мене народилася думка вчити студентів.

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

Зараз в сучасній фінансовій математиці практично нічого не робиться «для краси» в замкнутому вигляді, всі моделі, які реально використовують, вони в замкнутому вигляді не вважаються. Це все чисельні методи. І або ти на сітках диффур вирішуєш методом кінцевих різниць, або методом Монте-Карло щось моделюєш. І математика потрібна тільки для того, щоб вивести або кінцево-різницеву схему, або зрозуміти, що треба моделювати. А далі треба писати код, тому що без коду ніякої відповіді ти не отримаєш.

— Багато хто звинувачує сучасну математику в тому, що вона дуже далека від реальності. А тут — наука суто практична?

— Математика — вона різна. Я так само сам критикую concurrency. Я читаю по цій темі купу наукових робіт, і половина з них — повна нісенітниця. Народ придумує якісь алгоритми, робить якісь порівняння, але нікому на практиці ці алгоритми не потрібні.

Те ж саме і тут, природно. Математика — вона рухається сама. Є окрема область, окремі люди, які все це застосовують. І саме тому важливо мати правильний підручник. Одна справа – взяти підручник, де просто абстрактна математика. Поки через нього продерешься, витратиш купу часу, а корисної там буде мало, дві-три теореми або факту. І зовсім інша справа, коли матеріал структурований, коли з усієї величезної бази наукового знання відібрані і збудовані в ланцюжок ті факти, які тобі потрібні для вирішення практичних завдань.

Власний курс многопоточному програмування
— Давай трохи поговоримо про викладання. Ти вже більше десяти років викладаєш, так? Коли ти починав — був підручник Херлихи і Шавита?

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

— Як ти це робив?

— Почалося все з однієї книги. Я випадково натрапив на підручник, який мені сподобався. Насправді, підручник дуже дивний. Автор Гарг, називається Concurrent and Distributed Computing in Java.
Мені він сподобався тим, що, по-перше, у ньому все було досить поверхово описано і Concurrency, і Distributed в прикладному невеликому підручнику; по-друге, там були практичні приклади, як це можна запрограмований; і по-третє, були посилання на реальні наукові роботи. Тобто, ти голову закінчив, в ній багато теореми були пропущені і багато фактів опущені, але в кінці мали посилання на додаткове читання.

— Чим цей підручник відрізнявся від Java Concurrency in Practice?

— Багатьом. Це все-таки теоретична книга, але з подачею для практиків. З спробою відібрати те, що може знадобитися на практиці. І цим вона мене дуже зачепила. Оскільки ця книжка здалася мені надто поверхневою, я пішов за посиланнями, які знайшов в ній, вивчав відповідну літературу наукову, відібрав щось для студентів і збудував з цього свій курс. Послідовність подачі матеріалу у мене спочатку була приблизно така ж, як у Гарга. Але його матеріал я розбавляв теорією, яку брав з наукових праць того ж Лампорта, Херлихи і так далі.

А потім вийшов вже підручник з Сопсиггепсу Херлихи і Шавита. Я тоді на багато блогів був підписаний, і як тільки побачив анонс та відгуки, то відразу ж купив і прочитав. І відчув шок: «Ось воно! Ось те, що насправді треба, щоб читати такий курс. Ні більше, ні менше». Потрібна глибина, потрібна послідовність, потрібна широта. Я після цього курс трошки скоригував.

— А ось я цю книжку так всю цілком і не подужав. Знаєш, що мене в ній дратує найбільше? Вона досить кривим мовою написана, в ній сам англійська якийсь дивний і приклади теж. Пам'ятаєш, там на самому початку приклади з собаками, бляшаними банками. Я сидів дві години, намагаючись зрозуміти, що автори хоча мені сказати… А потім раптом зрозумів, що це класичний приклад про те, як на атомарних регістрах щось зробити. Як ти через це всі продирався?

— Мені було простіше, тому що я вже був підготовлений. У мене вже була професійна деформація, я всі ці приклади з собаками 100500 раз читав у статтях Лампорта та інших авторів. Я знав, звідки це. Що це не Херлихи і Шавіт придумали, а це класика, якої вже двадцять років. І тому для мене все це було знайоме і рідне. І студентам я рекомендую цю книгу як додаткове читання, не змушую всіх її читати. З курсу мого я частина теорії, яка мені здається малокорисною, викинув і студентам її не читаю.

—Як ти обираєш, що розповісти студентам, а що не розповісти?

— Я даю студентам те, що мені самому здалося дуже красивим і нетривіальним. Наприклад, я доводжу студентам теорему консенсусу Херлихи, тому що мені здається, що вона дуже красива і дозволяє зрозуміти суть речей. Дозволяє зрозуміти, навіщо тобі потрібен CAS, що без нього нікуди, що навіть два потоки не можуть прийти до консенсусу, якщо немає якоїсь більш високої конструкції. Показую універсальну конструкцію. Хоча її на практиці в тому вигляді, як у Херлихи, ти ніколи не будеш застосовувати. Це дуже штучна річ, але в ній використовуються прийоми, які потрібні далі в реальних алгоритмах. І взагалі я розповідаю про ті чисто теоретичні алгоритми, у яких є якісь прийомчики, які є будівельними блоками у інших, вже практичних, алгоритмах.

— до Речі, якщо читати роботи Лампорта, наприклад, то його побудови виглядають трохи штучними. Для доказу це добре, але коли відкриваєш який-небудь вихідний код в спробі зрозуміти застосування, то бачиш, що в ньому взагалі все інше. Виходить, що на практиці ці рішення не ефективні?

— Так, саме так. Основне питання, яке хвилювало дослідників 20-30 років тому, коли вся ця теорія з'являлася, — «чи Можна щось зробити або не можна?» Про ефективність взагалі ніхто не замислювався, тільки про те, можна чи не можна. І з'явилося дуже багато красивих теорем, що можна, а що не можна. І я всі ці теоретичні побудови на регістрах розповідаю студентам за одну лекцію, дуже швидко і поверхово. Я не змушую їх напам'ять знати. Тому що, з одного боку, хочеться показати, що все це можливо, а з іншого боку, всі ці алгоритми практичної цінності не мають. І другу частину курсу я концентруюся саме на практичних алгоритмах. Наприклад, на Сoncurrent-списках — розповідаю абсолютно класичний алгоритм, який багато де використовується.

— Який з полуинвариантом?

— Так. І відповідно, я його докладно розбираю. Тому що не тільки сам алгоритм практично цінним. Незважаючи на те, що після нього з'явився вагон поліпшень, якихось наукових робіт, все одно по балансу між складністю і продуктивністю він всіх рве.

А ось, наприклад, в HashMap-ах такої перемоги поки немає. Досі це активна тема дослідження, якій в числі інших і займаємося у себе в дослідницькій лабораторії і ми. Тому що HashMap – це взагалі структура даних всіх структур. Використовується постійно.

Є байка відома, здається, про СЕО Амазона. Коли він виступав перед студентською аудиторією, то студенти, які вивчають алгоритми, його запитали: «Скажіть, які структури даних нам знадобляться? Які алгоритми? Що ви використовуєте?». Він відповів, що для них найважливіше – «хеш-таблиці, хеш-таблиці та хеш-таблиці». І це все правда.

У нас теж саме. І у великих бізнес-завдання завжди так: хеш-таблиці – найважливіша структура даних. І з ними, звичайно, з точки зору Concurrency дуже багато відкритих питань. Тобто, там навіть подивитися, як активно все це змінюється в реалізації. Хоч нутрощі Java подивися, як там звичайний HashMap переписується.

— По слідах ConcurrentHashMap?.

— Ну, його переписали не по слідах. Довга там була історія. Фурор справили чуваки, які вісім років тому вивчили, як в PHP влаштований стандартний словничок, і навіть не вникаючи в суть веб-сайту, зробили запит, де ключі мають однаковий хеш. І стали його на різні сайти посилати.

95% сайтів, які вони спробували, лягли. І про це вони випустили чудову статтю. Після цієї статті почалася боротьба за хеши, в тому числі, за них почав Sun боротися. У Sun перша ітерація була — випадково хеш-коди рядків. Потім вони зрозуміли, що справа не тільки в рядках. І загалом, все це закінчилося поточною реалізацією: якщо bucket хеш-таблиці переповнюється, це все замінюється на збалансоване дерево. Мета цього — стабільна боротьба з хакерами. Щоб у тебе в гіршому випадку хеш-таблиця не вырождалась в O(N^2)-алгоритм, а щоб вона хоча б за O(N logN) працювала. Тому що в реальному веб-сайті ти з якими масштабами N стикаєшся? Може бути, десять тисяч, сто тисяч… І якщо у тебе десь є N^2, то твоя система лягла. Тому що 100 000 в квадраті — це вже занадто багато. А якщо у тебе невеликий N – то ще нічого, нормально, жити буде.



Багатопоточність: наука чи бізнес?
— Наскільки я розумію, рішення вашої компанії пов'язані з високими навантаженнями, з багатопоточністю. Розкажи, це твій інтерес до Сопсиггепсу призвів до того, що ви стали цим займатися? Чи, може, навпаки — робота змусила зануритися в цю тему?

— Це скоріше збіг обставин. Тут складно простежити причинно-наслідковий зв'язок. Коли ми починали (а це було в стародавні часи, в 2000ый рік або навіть трохи раніше), ми, як маленька компанія, бралися за все підряд. В ті часи дотком-буму програмісти були на вагу золота, народ готовий був замовляти кому завгодно що завгодно… І нам якось випадково потрапила пара проектів у фінансовій області. Ми почали їх робити, і нам сподобалося. І вже через два роки ми зрозуміли, що нічим іншим займатися не хочемо, перестали брати які-небудь інші проекти. Вирішили, що більше ніякого створення веб-сайтів, ніякого аутсортинга, будемо займатися тільки додатками для трейдингу, брокерів і бірж.

Все інше — наслідок цього рішення. Ти починаєш займатися цими додатками, і у тебе починаються проблеми з передачею котирувань. Тому що їх величезна кількість, а основна торгівля зосереджена на американському ринку. Знову ж таки, так історично склалося, що ми займалися більш складними фінансовими продуктами, всякими опціонами. А там мільйони інструментів, десятки мільйонів котирувань в секунду. Все це треба якось обробляти, досилати клієнтам. Клієнтів теж багато, десятки тисяч.

І нам довелося в цьому розбиратися. Спочатку ти переписуєш, переписуєш, вивчаєш, профилируешь код, знаходиш вузькі місця, придумуєш, як пофіксити… Перші кілька років взагалі все було виключно своїм потом і кров'ю досягнуто, самі винаходили рішення, без всякої науки. А потім наука як-то вже підійшла випадково. Ми всі були самоучками в цій області, кожну книгу исчитывали від кірки до кірки.

І коли з'явилася Java Concurrency in Practice в 2006 році, ти її брав і бачив, що це скарб! Але все це ти вже знаєш, до всього цього вже дійшов сам, тому що у тебе були практичні завдання. Але ти розумієш, як круто, що хтось це все систематизував. І ти знаєш, що якщо до тебе прийде новий програміст, то ти можеш йому сказати: «Ось, бери і читай Java Concurrency in Practice. Там зведення знань». І ти цю книгу починаєш цінувати за ці знання. І ти готовий під кожною сторінкою кров'ю своєю підписатися! Там автор пише, а ти вже знаєш: «так-Так, чорт забирай! Я був там! Дійсно так! Так не роби — а то сніг довбешка потрапить — зовсім мертвий будеш».

— Взагалі це дуже цікаво, тому що книжка дійсно досить стара. І результати тих Performance-тестів, які там є, сьогодні виглядають досить дико. Зараз реальність зовсім інша. Цікаво спостерігати, як це все розвивається.

— Цінність її не Performance-результати, звичайно. Цінність її в дизайн-шаблонів. Вона і структурує знання, і змушує тебе правильно мислити. Тому що основна проблема Concurrency в тому, що його дуже складно протестувати і дуже легко допустити баги. Тест можна хоч 10 раз запустити, але все одно він потім на підвішеній системі впаде через перемикання. Тому треба писати код так, щоб і тобі, і сусіду, і того, хто буде через кілька років читати цей код, було зрозуміло, що він коректний. Тому що написати код якось заплутано, то як потім себе переконати, що він коректний? І ось цьому вчить Java Сопсиггепсу in Practice. Вона вчить шаблонами. Якщо ти ними пишеш, то далі іншій людині легко їх пізнати, зрозуміти, що там все правильно.

Про підхід до створення API
Я нещодавно розмовляв з Пітером Лорі, який робить OpenHFT. Він вважає, що зараз вся боротьба між фреймворками йде вже не за Performance, а за те, щоб надається рішення було такою собі закритою коробкою, вирішує всі завдання Concurrency. Тому що, коли ми даємо якісь Concurrency-ручки назовні людям, все нафіг взагалі руйнується. Як ви боретеся з тим, що ваш код потім потрапляє комусь, хто не розбирається в багатопоточності?

— Ми не боремося. У нас інший бізнес. Ми робимо рішення за кінцевих клієнтів, тому у нас такої проблеми немає. Ми даємо інструмент конкретним людям більше, ніж програмістам.

— тобто, ви не даєте API?

— Даємо, але намагаємося його спрощувати. Ми вирішуємо це багатошарової архітектурою. У нас є низькорівневий API, де всі кишки назовні, і де крок вліво, крок вправо — підірвався на міні. Але цим низьким рівнем користуємося тільки ми самі, причому в нашій компанії є дуже маленька кількість людей, які знають, як з цим мін ходити.

А є ще високорівневе API, де все зручно і зрозуміло. І ми клієнтам навіть і не говоримо, що є всередині. Він документований, він зрозумілий. Там теж періодично помилки трапляються, але ми їх знаходимо і фиксим.

Чим займається компанія Devexperts
— Дуже цікаво, розкажи. У вас якісь розподілені системи, які передають котирування клієнтам і тому біржі, чи що?

— У нас дуже багато чого. Ми взагалі пишемо вертикально інтегроване рішення. Робота з котируваннями настановних даних – це всього лише маленька частина нашого бізнесу. У нас є окремий продукт dxFeed — це фактично окрема компанія в Америці, яка займається тим, що збирає дані з усіх бірж (десь якісь курси, котирування), поширює і клієнтам продає в упакованому вигляді через єдиний API в єдиному форматі. І це тільки одне маленьке напрямок. Дуже маленьке — там працює від сили десяток чоловік.

А вся інша компанія — ми чого тільки не пишемо… Візьми брокера якогось, йому потрібно купу інформаційних систем, йому потрібно враховувати клієнтів, йому потрібно вести свій бек-офіс, йому треба угоди враховувати… У нас величезна кількість команд, які ці системи створюють.

— А біржі теж різні, так?

— Біржі ми не автоматизуємо. Біржі вважають за краще все робити самі in-house. Але ми інтегруємося з ними у великій кількості. В основному це американські, але є і Азія, і ММВБ був довгий час нашим клієнтом. І зараз хороші стосунки з ними, і РТС був нашим клієнтом хорошим. Потім, коли РТС і ММВБ об'єдналися, інтеграція в основну інформаційну систему пішла не в нашу користь. Але на російському ринку у нас взагалі клієнтів дуже мало. Просто тому, що масштаб не той.

— А наскільки більше американська біржа, ніж наша?

— Та справа навіть не в біржі. Візьмемо створення якого-небудь професійного торгового терміналу з нуля. Кожний брокер прагне, щоб у нього була не така ж фігня, як у сусіда, а хоче відрізнятися. І якщо раніше гналися за меншою комісією, то зараз це вже давно не головна фішка. Комісійні у всіх брокерів досить низькі. А боротьба йде за більш зручний користувацький інтерфейс. Кожен брокер хоче щось своє, унікальне. Щоб можна було торгувати чим завгодно, щоб були графіки, красиво, швидко, не гальмувало.

— У вас це веб?

— У нас все. Ми робимо як веб-фронти, так і декстоп. Професіонали ставлять собі спеціальні стійки залізні, навішують туди п'ять – дев'ять моніторів. І всі ці монітори заповнені інформацією. Далі це все ось так починає рости вшир і зростання. Є спеціальні компанії, які роблять для цього машини, спеціальні стійки для моніторів.

— Це вінда, так?

— Так як ми пишемо на Java, то у нас робота під Windows і під Mac OS X. Але конкретно такі штуки під віндою зазвичай роблять.

— Так видеокарточек-то навіть нема, що стільки моніторів можуть підтримувати.

— Встромляти відразу декілька відеокарт, і все. Не проблема.

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

— Залежить від того, чим ти займаєшся. Звичайно, в основному це гоніння даних, але оскільки у тебе великий screen space, даних треба ганяти багато просто тому, що у тебе екранів багато. Ну і ще залежить від того, як ефективно написаний весь код. Багато хто, навпаки, займаються тех. аналізом, і всі бази даних котирувань тримають у себе на локальному компі. Якщо ти щось будуєш, це аналізується у тебе тут часто. Хоча зараз це все поступово…

— А це навіщо? Це для low latency зроблено?

— Ні, low latency — це взагалі окрема тема, це зовсім інший бізнес. Там тобі не потрібні всі ці монітори, ти пишеш код, який реально працює швидко, і основна проблема в тому, що щоб перемогти інших, ти повинен свої залізяки ставити прямо на біржі, в спеціальному colocation, платити чималенькі за це гроші. І тут вже монітори тебе не врятують. HFT — це дуже нішевою бізнес. У нас було кілька проектів low latency, але справа не пішла з різних причин. Одна з них в тому, що всі, хто займається low latency, всі намагаються робити in-house. А ми самі не торгуємо, ми пишемо софт.

І ти питав, у чому різниця масштабу. Розумієш, яка-небудь велика торгова система – це проект від мільйона доларів мінімум. Якщо ти подивишся навіть найбільшого брокера, то він не може собі з об'єктивних причин дозволити ці гроші витратити, тому що в них немає способу стільки заробити. У нас на всю Росію цих трейдерів кілька десятків тисяч.

Всі брокери заробляють на комісійних, яких у нас генерується як кіт наплакав. А у наших брокерів просто немає грошей, щоб інвестувати в розробку якогось крутого софту.

В Америці — зовсім інші масштаби. Там у брокерів мільйони клієнтів, які тримають мільярдні вклади, і брокер заробляє на відсотках з цих вкладів, так і з комісійних від угод. І це дозволяє найбільшим американським брокерам вкладатися у створення дійсно крутих систем.

Лабораторія по багатопоточності
— На початку 2000-х ти займався всім. А чим ти займаєшся зараз, коли компанія вже так виросла? Скільки, до речі, у вас людей?

— Чотириста чоловік або навіть більше. Я досі продовжую займатися всім, в тому числі, пишу код, тому що кодити люблю. І тому не відмовлю собі ніколи в задоволенні написати що-небудь цікаве. Але і не тільки. Наприклад недавно, близько року тому, ми зробили такий відокремлений підрозділ у компанії під назвою dxLab. Це дослідна лабораторія, і я тепер активно займаюся цей напрямок.

Ідея лабораторії — дуже проста. До нас багато років поспіль приходили на стажування студенти. І ми зрозуміли, що якщо в компанію собі береш стажиста, то їм треба займатися, його треба вести, допомагати йому. І поки це все залишається чиєюсь побічної завданням, то воно не працює. І ми зрозуміли, що в якийсь момент, що з цього треба робити Fulltime-роботу, треба робити окремий підрозділ, який буде цим займатися. Буде курирувати стажистів, давати їм завдання, контролювати.

— Якого типу завдання?

— Коли ми створювали dxLab рік тому, у нас планувалося кілька основних напрямків досліджень. Одне з них — це багатопотокові структури даних і алгоритми. Друге, пов'язане з цим, напрямок, — це тестування і аналіз продуктивності. Тобто, ми пишемо інструменти для себе, незважаючи на достаток на ринку комерційних профайлеров — в силу специфіки того, що наші рішення — high concurrent, і у нас є дуже багато вузьких задач. І ми продовжуємо в цих напрямках працювати, тому що існує дуже багато речей, яких нам треба подивитися.

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

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

Таким чином, у нас взагалі підхід до дизайну систем і до Performance-моніторингу зовсім інший. І тому доводиться багато інструменти розробляти з нуля. І з-за того, що нам потрібні спеціалізовані структури даних і алгоритми, які нікому більше не потрібні.

— Які алгоритми? Приведи приклад.

—Простий приклад — котирування. У звичайних реалізаціях HashMap пара «ключ-значення» загортається в об'єкт. Якщо ти спробуєш при нашому обсязі котирувань так робити, у тебе буде дикий Garbage Collection, і все помре. Тому нам потрібні інші HashMap-и. Нам потрібно, щоб пару «ключ — багато значень» прямо в пам'яті розкладати. Спробуй пошукай серед наукових робіт алгоритми HashMap-ів, які до одного ключа можуть атомарно багато значень хронить. Да їх просто немає! Нуль таких статей! Тобто, треба самому ці алгоритми придумувати.

— Всі речі, які пов'язані з CAS-ами і атомарностью, як раз лають саме за високу аллокації.

— Ми придумуємо алгоритми, які без цього. Це окрема тема дослідження – як цього уникнути. Просто все доводиться робити своїми руками. Я давно робив доповідь про, наприклад, чому GC жере ваш CPU. Ми коли з цією проблемою стали стикатися, зрозуміли, що ніякої штатний профілювальник її не вирішить. У нас всі серйозні проблеми виникають завжди на продакшені. Й ще особливість у тому, що системи такого роду, як наші, складно тестувати, тому що треба писати свої власні інструменти.

Якщо ти пошукаєш інструменти тестування програми під навантаженням, то знайдеш сто штук. Але що всі вони вміють? Вміють на веб-сайт посилати HTTP-запит. Відмінно. Тільки у нас на веб-сайт і немає HTTP-запиту. У нас взагалі інша система.

Тому, профилировщики доводиться писати самим. Але одна справа — писати, а інша справа — намагатися рухати в цьому науку. І ми зрозуміли, що без науки нам нікуди. Тому що не хочеться писати чогось, що науці невідомо. Набагато приємніше, коли ти прочитав статтю, там описаний алгоритм, ти взяв його і реалізував. А що, якщо такої статті нема? Очевидно, тобі цю статтю треба самому написати, щоб потім ти міг по ній написати свій алгоритм.

— А як ви вирішуєте дихотомію між теорією і практикою? В теорії-то алгоритм може бути якої завгодно хороший, а потім на залізо просто не ляже.

— А ми поки займаємося тільки прикладною наукою, фундаментальними дослідженнями ми не займаємося. У нас маленька лабораторія.

Як розвивається Concurrency, і що буде в моді найближчим часом
—У мене таке відчуття, що є п'ять книг у світі Concurrency, і всі були опубліковані ще в середині двотисячних, а новіше взагалі нічого немає. Далі тільки статті в журналах. Наскільки це так?

— Наука завжди так розвивається. Підручник Херлихи і Шавита, за науковим мірками, —досить свіжа книга. У нього перевидання вийшло не так давно, кілька років тому. З тих пір наука прямо семимильними кроками нікуди не пішла. Для науки все-таки десять років повинно пройти.

— Вона розвивається взагалі?

— Розвивається. Проблема в тому, що коли ти відкриваєш роботи серйозної наукової конференції, завдання у них, як правило, далекі від практики. І це зрозуміло. Бо хто на ці конференції їздить? В основному, це все-таки Внз. Так, у них є які-небудь співпраці з компаніями, вони намагаються брати практичні завдання звідти, але все одно найчастіше є професор, у якого є своя тема, він продовжує рухати незалежно від того, чи пов'язана ця тема з практикою. У професора є студенти, вони щось роблять йому.

— Є такий професор Даг. Яку роль він відіграє в сучасній Java і в сучасному Сопсиггепсу, я думаю все більш-менш знають. І є мужик такий, Джеремі Менсон, який, якщо мені не зраджує пам'ять, був аспірантом Дага і на початку двотисячних зробив дисертацію на тему Memory Model. І потім це все просто взяли і фактично зашили в Java 5 (JSR 133). Це досить дивний випадок, коли наука стикається з практикою. Ти взагалі наскільки активно стежиш за повідомленнями типу concurrency-interest і hotspot-dev?

— Я підписаний на все і стежу за всім, що там відбувається. І природно, я на всі блоги всіх цих великих людей підписаний. Відповідно, якщо щось з'являється, я в курсі.

— тобто, ти активно стежиш не тільки наукою, але й за індустрією?

— Я підписаний на тисячу різних каналів. У будь-який вільний час я щось читаю. Я стежу за тим, що відбувається у світі науки, а зараз додалися фінанси — тепер я ще й на це підписаний. Це дозволяє відчувати тренди, і якщо щось нове і цікаве відбувається, то повз мене воно точно не пролетить. Тому що заздалегідь ти не знаєш, коли і хто придумає щось революційне. Коли читаєш стару Wait-free synchronization авторства Херлихи, ось тоді розумієш, що за тих часів це була революція, тому що ця робота все структурувала і сказала: «Так, ось потрібні універсальні об'єкти, всі ці CAS і так далі. Без них ніяк.» Розумієш? І чітко показала, що, чому, навіщо.

Зараз схожа, гаряча тема, яка повинна в якийсь момент вистрілити — це Software Transactional Memory (STM). Software за підтримки Hardware, природно. Чисто залізної моделлю, на жаль, не обійдешся, тому що залізо лімітовано за обсягом. Тому основна тема – як це все одружити.

Фішка в тому, що Hardware Transaction Memory (HTM), яка повинна була бути в Haswell, виявилася бажной, і Intel вимкнув її. Але рано чи пізно цю фічу відлагодять, і у нас буде HTM-процесор. Як його використовувати — зрозуміло. Але проблема в тому, як з цієї дати інструмент програмісту високого рівня, який зможе будь-код писати.

— Розумна JVM повинна все робити за нього.

— Так, але не зовсім зрозуміло, як. Це велика тема для дослідження, тому що якщо розумна JVM просто скомпилирует у HTM, то буде проблема, тому що HTM в кеші все тримає. А коли кеш скінчився, система говорить: «Все, транзакція занадто велика, я не можу її хардварно обробити». А ти хочеш хардварно! Ти не хочеш твого high level програміста цими low level деталями напружувати. Якщо він написав Atomic, воно повинно працювати. Повільно чи швидко — але працювати повинно! Тому тема дійсно складна, їй купа народу займається, багато свіжих публікацій виходить.

Ідея HTM — досить проста. Припустимо, ти пишеш хеш-таблицю. Щоб вона стала многопоточной, ти пишеш «synchronized». У тебе synchronized хеш-таблиця з'являється. Далі, якщо тобі потрібно що-то більш масштабоване, ти починаєш перейматися, придумувати CAS-и і так далі.

А з транзакційних менеджером тобі взагалі паритися не треба. Ти пишеш замість «synchronized» інше магічне слово – «atomic», мовляв, хочу, щоб це все атомарно працювало. Не ситуативно, а атомарно. Суть зразок для програміста та ж сама, але деталь зовсім інша. Тому що, якщо у тебе є HTM, то процесору просто йде інструкція xbegin — «почати транзакцію». Даний CPU спілкується з іншими CPU, і знає, яку пам'ять він змінює. Він просто починає відстежувати: ось я зараз читаю комірку пам'яті, а не поміняли випадково, поки у мене транзакція, цю комірку пам'яті? Бо прийде сигнал по шині про те, що хтось поміняв.

Крутість в тому, що overhead на такі дії — нульовий. Якщо все добре і конфлікту немає, то overhead навіть менше, ніж у твоїх всіх CAS-ів і блокувань. Тому що нічого не треба реально змінювати. Ти береш xbegin, xcommit, і все: транзакція почалася, транзакція закінчилася. Якщо тобі пощастило, і ніякий інший потік в цей момент з цієї коміркою пам'яті нічого не робив, то у тебе все відпрацювало без конфлікту і з величезною швидкістю.

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

І тільки коли в тебе виникає конфлікт, і два потоку лізуть в одну клітинку, починаються проблеми. В класичному варіанті, без хардварной транзакції, тобі довелося б lock для кожної клітинки тримати. Це дорого. Зрозуміло, що JVM — дуже розумна і вміє ці lock-і виділяти об'єктів за необхідності, але все одно overhead великий.

А з хардварной транзакцією у тебе з'являється суперсила практично безкоштовно, без втрати продуктивності. Проблема, що ці хардварные транзакції будуть тільки в Skylake. У Haswell перший млинець вийшов грудкою.

— А от цікаво, в hotspot-dev нічого не миготіло на цю тему? Тобто, в Java вже починали вже це все робити?

— В hotspot-dev — не факт, але Джон Роуз, архітектор JVM, і його колеги з Oracle на цю тему активно публікують наукові статті.

—Я не знав, що Джон займається наукою.

— Займається: є його статті на тему, з яких я зробив висновок, що вони з колегами займаються дослідженнями в області транзакцій.

У чому основний challenge роботи Devexperts
— Я почув, що у вас складна система, що мало досліджень у вашій області, тому доводиться придумувати самим. Це основні челленджи?

— Головний челендж — це scale. Системи стають великими, доводиться їх різати на модулі, тому що одним шматком все це вже не задизайнити. І у нас виходить кілька проектів в компанії, кожен займається своїм шматком. Далі починаються інтеграційні проблеми і пошуки балансу: в який момент треба або писати все в одну купу, одним монолітом, як це зараз прийнято називати, або все це треба різати на микросервисы і думати, як бути з перформансом тоді. Ось це все – теж великий головний біль. У тому числі, у плані дизайну. Тому що scale зростає, багато всього робимо. Купа організаційних проблем із-за цього.

Ми ж не робимо коробкові продукти, у нас зовсім інший бізнес. Ми не випускаємо нові версії, у нас код — це така заготовочка для демонстрації, щоб на виставці можна було показати. Клієнти дивляться і кажуть: «Добре. Але мені потрібно ще ось тут, тут і тут перефарбувати, там ось такий функціонал додати». У підсумку ми робимо custom-копію під одного клієнта, custom-копію під іншого…

— А цим окремі люди займаються?

— Є окремі команди, які під клієнта вже працюють. Команди впровадження.

— І вони беруть якийсь конструктор ваш?

— Так. А потім вже те, що вони наконструировали треба поділити: щось є інтелектуальною власністю клієнта, тому що це була його мега-вигадка, а що-це просто наша кодова база, яку треба замержить назад в основний продукт.

— І цим окремі люди займаються?

— Загалом, так. І ніхто тобі на конференції не розповість, як такий бізнес вести, чорт забирай! Як клепати сайти – розкажуть. Як робити коробковий продукт – розкажуть. Мобільні додатки робити – розкажуть. Як ось таким бізнесом займатися – ніхто тобі не розповість. Ні в якій книжці не напишуть.

— Це цікаво?

— Це цікаво. Це бізнес, який не робить більше ніхто. Це унікальна ніша, вона дає унікальну конкурентну перевагу. З одного боку, іноді ніби як шкода: ось компанії продають коробкові продукти десятками тисяч, а нам кожна продаж дається насилу. З одного боку. З іншого боку – ми розуміємо, що є клієнти, які просто без нас би не подужали. Тому що вони реально не хочуть коробковий продукт, як у всіх. Вони хочуть своє власне рішення, але не готові платити за його написання з нуля. Тому що це шалено дорого і довго. Тому вони беруть наші готові кубики, і ми для них збираємо відповідне рішення.

—І у вас вже є експертиза визнана, і фактично вони йдуть до вас.

— Так.

Як всесвітня олімпіада з програмування прийшла в Росії
— Слухай, вже довго розмовляємо, давай ще про одну річ поговоримо. Якщо я помиляюся, то ти ще й директор Європейських олімпіад з програмування, так?

— Не зовсім. Я голова журі Північно-Східного Європейського регіону ACM-ICPC.

— Це тих самих знаменитих олімпіад з програмування?

— Так, є найбільші престижні олімпіади для студентів, називаються International Collegiate Programming Contest. Їх проводить ACM – найбільше співтовариство професійних програмістів, яке ще відоме тим, що щорічно вручає всім відому премію Тюрінга. Це як Нобелівська премія, але для програмістів. І Лампорт, і інші великі люди — всі вони лауреати цієї премії. Так ось під егідою ACM проводиться найбільше, найпрестижніше змагання з програмування — ICPC.

— Де ми періодично бачимо наших...

— Так. Там, де періодично наші студенти всіх рвуть, як Тузик грілку.

— А ти там чим займаєшся?

— ICPC – це глобальна олімпіада, яка проходить у десятках регіонів по всьому світу. І у нас є своя зона регіональна. Називається «Північно-Східний Європейський регіон» (NEERC). У нього входять Росія, Казахстан, Узбекистан, Білорусія, Балтійські держави. Причому система досить демократична. Якщо якась команда хоче де-небудь в іншому місці брати участь, вона має право попроситися в іншу зону. Змагаються Вузи, це важливий момент. Не конкретні люди, а ВУЗ посилає команду.

— Є правило, що у фіналі не може бути більше однієї команди від Внз.

— Так. У фіналі не більше однієї команди від внз. І у фіналі не можна брати участь одній людині більше двох разів. Все дуже жорстко зроблено, щоб не було професіоналізму.

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



— Як влаштований відбір – це стандартизовано? Або на розсуд регіону?

— Є загальне правило, а деталі – на розсуд регіону.

— Ти ці деталі розробляв?

— Так. Я, власне, був одним із батьків-засновників. Я в першому нашому змаганні ще брав участь.

— А давно взагалі ці змагання проводяться?

— Сам ICPC проводиться з 77-го року. А я там з 96-го року. Коли я перший раз брав участь, у нас ще не було регіону, і ми поїхали брати участь в сусідній регіон. Написали лист, попросилися і нас взяли. Ми поїхали в Стокгольм і зайняли там перше місце, і місцевих всіх позбавили путівки у фінал. І вони такі: «Ой, як так?». І тут директор стокгольмського фіналу знайшов оригінальне рішення, каже: «Хлопці, зробіть у себе регіон». Тоді Антон Суханов, переможець всесоюзних ще олімпіад з інформатики, займався цим. Він і організував регіон тут, країна велика.

— А тобі було років 20, напевно?

— Під час того першого змагання я був на другому курсі. І моя команда стала першим чемпіоном Росії, ми зайняли перше місце в нашому регіоні, поїхали у фінал. У фіналі виступили не дуже: не внизу, але і не на призові місця. А в наступному регіоні, так як я вже два рази брав участь у фіналі, мені вже брати участь було не можна, і тому я став організатором усього цього справи. Суханов тоді поїхав працювати в Microsoft, усе залишив на мене. І з тих пір я цим і займаюся.

— тобто, 20 років уже?

— Так. У нас був ювілейний півфінал, двадцятий. І 19 років його організовую я. Коли я перші роки ICPC займався, це було жахливо. Це відбувалося в Анічковому палаці, я там ночував по кілька діб, фактично жив там.

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

Останні кілька років ми проводимо змагання на базі ІТМО в Санкт-Петербурзі. Але у нас країна велика, тому довелося одночасно проводити змагання в Санкт-Петербурзі і в Барнаулі, тому що з'ясувалося, що з тієї частини Росії просто немає грошей у студентів долетіти до Пітера. Почалося з двох, а зараз ми проводимо в чотирьох місцях одночасно. Це рішення було прийнято з фінансових міркувань, щоб люди могли брати участь. Останні змагання пройшли в Санкт-Петербурзі, Барнаулі, Ташкенті та Тбілісі. Ми намагаємося принести олімпіаду до людей, щоб вони все-таки могли взяти участь. А потім люди їдуть на фінал.

— А скільки команд їде на фінал від нашого регіону?

— Зазвичай трохи більше десяти. У цьому році, по-моєму, 13 або 14.

— А в фіналі скільки всього?

— У фіналі 120-125 команд.

— Виходить, що наш регіон – це приблизно десята частина від усього, що є у світі?

— Так. Наш регіон великий. І ми історично добре виступаємо.

— Ви ж брали фінал всієї світової цієї олімпіади?

— Так. Два роки тому. Я був директором цього фіналу.

— Це тому, що ваша команда виграла?

— Тому що ми цим давно займалися і тому що ми виграли. Було багато факторів. Це як олімпійська система: кожен рік фінал проходить в різному місці. Різні країни, бажаючі провести фінал у себе, шлють заявки. Ми теж в якийсь момент надіслали заявку. Не те, що прямо це була наша ідея. Швидше це була ідея директорату змагань: «Давайте-но, хлопці, в Росії ніколи не було, а ви цим давно займаєтеся, проведіть у себе фінал». Ми по засіках пошкребли і знайшли фінанси. І послали заявку. І організували фінал у себе. Це був колосальний досвід.

— Ви проводили в Ювілейному, по-моєму?

— Так. Сам фінал проходив у Ювілейному. Фішка в тому, що ти повинен, організовуючи фінал, всіх учасників розмістити. Учасники прилітають за свій рахунок до тебе на фінал, а далі ти їх повинен повністю забезпечити. Поселити, нагодувати, розважити. Повний пансіон.

— А скільки людей приїжджає? 120 команд, кожна команда, напевно, людина за шість?

— Три людини плюс тренер. Мінімум чотири.

— Запасні, напевно, ще?

— Запасних тут немає. Їх скасували, як раз щоб заощадити гроші. Вирішили, що замість того, щоб запасних тягнути, краще більше команд запросити. Тому команда офіційно — чотири людини. У підсумку до нас приїхало чоловік 1200 десь. Це колони автобусів. Все було влітку. Ми всіх поселили у Исакиевского.

— Це ж білі ночі та інше. Де готелів стільки взяти?

— Асторія, Петро Палас — все прямо в центрі.

— Це ж величезні гроші насправді. Хто це фінансував?

— Це був федеральний грант.

— тобто, ви прийшли в Уряд або в Міносвіти і сказали: «Хлопці, ось така історія»?

— По суті так. Це велика заслуга конкретно ІТМО і його ректора Васильєва, що він примудрився виграти великий освітній грант на розвиток освіти взагалі. Це був не окремий грант під цю олімпіаду, це був такий величезний грант взагалі на створення системи освіти і підтримку освіти програмістів. І маленький шматочок цього гранту – це було проведення фіналу ICPC.

— тобто було запропоновано фінансування, ви там з містом особливо не взаємодіяли?

— Ми з містом взаємодіяли з питань підтримки з боку, щоб поліція супроводжувала все це справа, автобуси там робила. Реклама по місту.

— А реклама навіщо?

— А ти знаєш, місто сам запропонував. У міста є соціальні рекламні місця. І раз місто бере в цьому участь, допомагає, підтримує, то нам сказали: «Ось ми вам виділяємо скільки-то місць». Ми спільно з ними розробили макети реклами. І вона була там розвішена. Приємно, ти приїжджаєш на захід – у тебе висить реклама.

А це дійсно чудовий захід. Це найпрестижніший у світі змагання з програмування. Тобто те, що воно приїжджало в наше місто – це насправді супер. Це велике досягнення.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.