14 декабря 2016 в 18:55

DotNext — Moscow 2016. Как это было



Впервые я побывал на «Дотнексте» летом этого года в Питере. Тогда меня привлекли имена Дино Эспозито и Саши Гольдштейна в списке докладчиков. По книге Дино я когда-то давно осваивал ASP.NET. Pro .NET Performance не читал, но отзывы слышал лишь позитивные. Никогда не считал performance своей сильной стороной, а необходимость сталкиваться по работе с оптимизацией производительности стала возникать довольно часто. Вдобавок, на тот момент у меня были смешанные чувства по отношению к .NET Core. Хотелось узнать, что думают другие по этому поводу. Решающим фактором, конечно же, стало желание девушки съездить в Питер на пару деньков. Мы поехали и не пожалели:)

С Москвой все было сложнее – этот город я недолюбливаю примерно так-же, как зиму в России. Чашу весов на этот раз сдвинули доклады C++ через C#, Моя жизнь с актерами, Squeezing the Hardware to Make Performance Juice и присутствие на конференции сотрудника Stack Overflow. Каждый из них был интересен в практическом плане, так что поездка предстояла не увеселительная, а рабочая.

Открывал конференцию Дино Эспозито и на этот доклад я опоздал. Во-первых, с лета мало чего принципиально поменялось в ASP.NET Core и еще тогда Дино четко обозначил свое мнение на три года вперед. Во-вторых, я слежу за .NET Core с пятой беты. Отсутствие SignalR можно пережить, воткнув для соответствующих целей socket.io. А вот EF7 все-еще сыроват.

Ознакомившись с видео-записью, я понял, что ничего не потерял. Стоит отметить, что для тех, кто не следит за развитием .NET Core доклад мог быть полезен, потому что в событиях периода RC1-RC2 действительно можно было потеряться.



Дальше я пошел в четвертый зал, потому что портирование плюсов на C# — задача для меня актуальная. Доклад Егора заставил по настоящему зауважать разработчиков Mono за то, какую не тривиальную работу они проделали, не смотря на то, что традиционно Mono принято ругать и хулить, потому что «там баги» и вообще «все криво» и не тот «level of quality», что в Microsoft. В докладе была затронута тема предотвращения утечек памяти при взаимодействии из C# с плюсовым кодом. Если слайды, начиная с 25го не вызывают у вас вопросов, вы знаете про внутреннее устройство .NET гораздо больше меня. В дискуссионной зоне удалось пообщаться про HoloLens.

Заказывать предварительную версию поиграться – жаба душит, а у Егора девайс есть. Я расспросил о деталях работы с «линзами». Не уверен, будет ли коммерческое применение устройству, кроме как в визуализации интерьеров. Очень бы хотелось, потому что игрушка прикольная.

После перерыва мне пришлось выбирать между akka.net и Stack Overflow. Желание обменяться опытом и расспросить конкретные факты и цифры про akka.net победило и я остался в четвертом зале. В итоге укрепился во мнении, что пора учить F#. Во-первых, функциональная парадигма выглядит лучше для event-driven систем. Во вторых, строки кода – это то, с чем я активно борюсь в последнее время, потому что кода слишком много.

Статистика Вагифа на слайде 83 далеко не в пользу C#. Хорошей новостью для меня стало, что persistent-actors вполне себя работают. Мы с момента беты не рисковали связываться. Уже за рамками доклада в дискуссионной обсудили перспективы akka streams. В России «Аккой» занимается не так много людей, поэтому обмен опытом был крайне полезным. Стоит отдельно отметить, что этот доклад был однозначно самым «творческим». Около трех минут заняло исполнение песни, посвященной акторной системе. По-моему свежо:)

Следующий доклад меня, к сожалению, разочаровал. Показалось, что времени охватить многопоточнось с уровня процессора до .NET Framework, просто не хватило. Информации и цифр было много, но в итоге осталось ощущение недосказанности: что делать с этой информацией, на что обращать внимание, с какими проблемами можно столкнуться в «реальном мире»? Возможно, я просто стал заложником своих ожиданий. Не смотря на общее ощущение понравилась часть, посвященная ключевому слову lock. Деталей реализации (слайд 37), озвученных Гаелем, мне не попадалось на глаза в интернете/литературе. Всегда казалось, что lock просто сразу переходит к шагу 3: «Create kernel event and wait».

Зато доклад Карлена, наоборот, оказался неожиданно ярким. Возможно, этому способствовала особая манера изложения спикера. Я не фанат разглядывания ассемблерных листингов. Здорово, что кто-то может за тебя замерить производительность разных методов .NET и объяснить почему происходит именно так, а не иначе. Принято считать, что виртуальные методы – медленные. Карлен очень доходчиво продемонстрировал, что это не так. Посмотрите слайд №37, спорим, удивитесь! Вообще было много деталей про отличие классов от интерфейсов, реализации дженериков. Информация Карлена крайне полезна разработчикам библиотек.


Дальше – лучше. История о том, как Stack Overflow разрабатывала поиск по тегам – просто шедевр. Удалось осветить в одном докладе темы оптимизации БД, full text search, неожиданные детали GC, особенности параллелизации и работу с CUDA. И все это на реальном примере сайта, которым мы пользуемся чуть ли не ежедневно. Для меня – это, однозначно, лучший доклад на конференции. В слайдах есть ссылки. Информация доклада доступна в блоге Марка Гравелла. Всем, кому нужен поиск в больших БД – абсолютный must read.

К концу конференции я стал уставать от обилия низкоуровневых деталей. Доклад Гольдштейна тоже не оказался простым. Казалось бы SIMD – это больше для геймдева и физики, математики. Но опыт Stack Overflow подсказывал, что может быть по-всякому. В любом случае, просто знание этой информации, может очень сильно помочь в принятии верных технологических решений. Один мой знакомый, занимается робототехникой. Большая часть софта – на плюсах по причинам производительности. Когда они начинали никто всерьез не рассматривал Java или C# в качестве платформы. Раньше я разделял такую точку зрения. Доклады Марко и Саши заставляют задуматься а так ли это на самом деле?

Финальный доклад я тоже почти целиком пропустил, потому что общался с представителями RavenDB. Решил, что нужно обязательно посмотреть запись их спича: судя по всему, ребята проделали большую работу в четвертой версии.

Понравилась идея map/reduce-репликаций в реляционное хранилище. RavenDB 4 еще в альфе, конечно, и в продакшн использовать рано. Но, если все действительно так хорошо, как говорят разработчики, то RavenDB сейчас – одна из наиболее привлекательных БД для рефакторинга legacy .NET-систем на NoSQL-хранилище (там где это действительно нужно, конечно).

Резюме


Описывать стенды спонсоров и обед мне не интересно. Спонсоры – предлагали работать у них или рассказывали о своих продуктах. Обед был без очередей и задержек – все четко.

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

Кстати, в этот раз мне пришла в голову мысль: есть проблема, не с конференцией, а публикой, с сообществом. Некоторые доклады были на столько специфичными, что находилось всего несколько смельчаков с вопросами. У какого числа программистов в России есть доступ к самым новым процессорам и возможность проверить, побенчмаркать разные архитектуры? Вот тупит branch prediction в маленьких циклах на Haswell, а на Ivy Bridge – нет. Кто действительно полезет переписывать алгоритмы, чтобы вставить в них SIMD?

Если лет пять назад я считал, что нет широкого рынка таких задач, то сейчас ситуация меняется. Ежегодный взрывной рост частоты процессоров и наращивание ядер закончились, memory bandwidth никто не отменял, а значит, скоро придется снова оптимизировать алгоритмы и выжимать из железа максимум. А чтобы знать как оптимизировать, учиться нужно уже сейчас.
Максим Аршинов @marshinov
карма
84,0
рейтинг 5,6
Управление разработкой бизнес-приложений
Самое читаемое Разработка

Комментарии (15)

  • –9

    А будут ли выложены Видео этих самых презентаций, или в отличие от https://habrahabr.ru/company/mailru/blog/311736/


    Или все таки .net проприотарен ???

    • +8
      у них есть канал на ютубе, все предыдущие дотнексты есть, скорее всего и этот будет
    • +5
      Участникам уже доступно необработанное видео. После того как всё будет подчищено (иногда были проблемы с микрофонами, которые весьма оперативно устранялись) — будет выложено публично.
      • +5
        Справедливости ради стоит заметить, что «чистовые» видео тоже будут доступны только участникам.

        В общий доступ выложим где-то через полгода.
        • +4
          почему через полгода-то? В феврале-марте выложим.
    • +1
      Видео с наших открытых встреч и митапов JUG.ru/CodeFreeze мы тоже выкладываем сразу в открытый доступ. Но тут 26 докладов с конференции. Доступ к ним есть только у участников, оставивших нам фидбек о конференции.
  • +5
    Хочется отметить отличное выступление Дино Эспозито.

    Так же в следующем году, хочется больше докладов про .net core и .net standard
  • +2
    а почему Akka.Net а не Orleans? Только из-за F#?
    • +2
      Вагиф объяснил так:
      1. Akka.NET достаточно точно портирована, а у Akka (та что на скале) комьюнити больше
      2. На момент выбора Akka.NET имела больше фич (не помню каких)


      У меня произошло примерно так-же: я искал не «акторную систему», а отказоустойчивую инфраструктуру с многопоточностью. Нашел Akka, увидел, что есть порт. Меня устроило. Orleans нашел сильно позже, когда мы уже разобрались в Akka.
    • +1

      У них несколько разные подходы вообще говоря. Akka позволяет работать с акторной моделью в чистом виде, Orleans же скрывает всю эту кухню и по сути предоставляет возможность писать обычные дотнетные классы, экземпляры которых уже сам раскидает по кластеру, а взаимодействие между ними идёт через асинхронные (async/await) вызовы. Соответственно выбор зависит от того, насколько вы хотите именно акторы, а не просто шардинг экземпляров ваших классов.

      • 0
        Кстати, а никто не сравнивал пропускную способность Akka.NET vs Orleans «при прочих равных»?
        • +1

          В последний раз, когда я смотрел (а это было года полтора назад) Akka была шустрее чуть ли не на порядок на локальной машине, но в дальнейшем Orleans серьёзно оптимизировали. Но даже сейчас следует учитывать, что Orleans гвоздями приколочен к TPL (Task/Task<T>), что даёт ощутимые накладные расходы и, если я всё правильно понимаю, блокирует актор до завершения вызова к другому актору, в Akka же всё построено на ручных отправке/приёме сообщений.


          Кстати, когда в Akka.NET делали поддержку тасков, была идея их к каждому актору их прикрутить нативно, но от этого отказались, так как вылезли проблемы с тем, что в Akka всякие разные состояния, которые она держит в TLS и в случае с тасками их приходится гонять через LogicalCallContext, что давало деградацию производительности в разы.

      • +1
        а в чем именно разница в подходе?
        В Orleans у меня есть grain, который гарантированно единственный экземпляр моего актора, и к которому доступ всегда синхронизирован.
        Какие дополнительные преимущества есть у Акка?
  • +1
    этот город я недолюбливаю примерно так-же, как зиму в России

    Аналогично, поэтому в этом году я не поехал.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.