[Перевод] Parallel STL. Быстрый способ ускорить C++ STL код

За пару последних десятилетий, пока вычислительные системы эволюционировали от одноядерных скалярных до многоядерных векторных архитектур, значительно выросла популярность управляемых языков, а также появились новые языки программирования. Но старый добрый C++, позволяющий писать высокопроизводительный код, остается более чем популярным. Однако, до недавнего времени стандарт языка не предоставлял каких-либо инструментов для выражения параллелизма. Новая версия стандарта (C++17 [1]) предоставляет набор параллельных алгоритмов Parallel STL, дающий возможность преобразовать существующий последовательный C++ код в параллельный, что, в свою очередь, позволяет задействовать такие аппаратные возможности, как многопоточность и векторизация. Эта статья познакомит вас с основами Parallel STL и его реализацией в Intel Parallel Studio XE 2018.


Читать дальше →

Шаг к квантовому превосходству: 49-кубитный квантовый компьютер от Intel

В октябре прошлого года Intel объявили о релизе 17-кубитного чипа. Но уже спустя три месяца на CES 2018 компания продемонстрировала 49-кубитный квантовый чип Tangle Lake, который, как надеются ученые, станет важным компонентом в достижении квантового превосходства, так как теоретически 49-кубитный квантовый компьютер может превзойти по вычислительной мощности все суперкомпьютеры в мире (на некоторых задачах).

Об особенностях Tangle Lake и ситуации на рынке квантовых машин расскажем далее.

Читать дальше →

Опыт построения логов на Postgres

Мы разработали свою систему логирования на PostgreSQL… Да я знаю, что есть надстройки над ElasticSearch (GrayLog2, Logstash), и что есть другие похожие инструменты, и есть те, про которые не знаю. Тем не менее, наш инструмент на текущий момент построен на PostgreSQL, и он работает.
Во время рабочей недели со всех сервисов СБИС в облаке к нам поступает в сутки более 11 млрд записей, хранятся они 3 дня, общий объем занимаемого при этом места не превышает 32 Тб. Все это обрабатывает 8 серверов с PostgreSQL 9.6. Каждый сервер имеет 24 ядра, RAM 16Гб и 4 SSD диска по 1Тб.


Читать дальше →

Масштабируем блокчейн сохраняя децентрализацию с Failsafe Network

Как многие уже заметили, комиссии в биткоине последнее время стабильно держатся в районе 20-30 баксов за простой перевод, достигая даже 50 в пиковое время.

Это происходит потому что размер блока ограничен константным значением, а желающих вместить свою транзакцию в блок заметно больше чем раньше. Что вызывает конкуренцию за комиссию и ее естественный рост.

Логично, что увеличив блок мы сможем вместить больше людей а значит отложить проблему? С одной стороны — да — так поступил Bitcoin Cash вся суть которого сводится к увеличению блоксайза до 8Мб.

С другой стороны — нет. Об этом, и о разработанном блокчейне Failsafe который элегантно решает эту проблему — под катом.
Читать дальше →

Удалённая работа, это хорошо или плохо?

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

Я довольно долго (4 года) работал удалённо, и не мало успел поработать в офисах (около 3-х лет), здесь я хотел бы поговорить о плюсах и минусах удалённой работы для программиста.

Думаю что стереотип о лежащем на пляже удалёнщике с ноутбуком давно развенчан, но всё же я бы хотел с вами поговорить о том, почему удалённая работа это хорошо/плохо.



Читать дальше →

[Перевод] Введение в современную сетевую балансировку и проксирование


Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.


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

Читать дальше →

Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) in-memory БД. С Join и полнотекстовым поиском

Всем привет,

Я директор по разработке компании Рестрим. Мы разрабатываем и сопровождаем платформу IPTV/OTT телевидения. У платформы около 10 миллионов пользователей. Платформа первого поколения проектировалась в 2010 году, и была ориентирована в первую очередь на IPTV приставки.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать несколько сотней тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш. Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

...Далее...

Лучшая архитектура на базе Docker и Kubernetes — миф или реальность?

Как изменился мир разработки ПО в эпоху Docker и Kubernetes? Можно ли построить архитектуру один раз и навсегда на базе этих технологий? Возможно ли унифицировать процессы разработки и интеграции, когда все "упаковано" в контейнеры? Какие требования предъявляются таким решениям? Какие ограничения несут они с собой? Упростят ли они жизнь простым разработчикам или сделают её тяжелее?



Пришло время ответить на все эти и не только эти вопросы! (В тексте и оригинальных иллюстрациях)

Читать дальше →

Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) inmemory БД. С Join и полнотекстовым поиском

Всем привет,

Я директор по разработке компании Рестрим. Мы разрабатываем и сопровождаем платформу IPTV/OTT телевидения. У платформы около 10 миллионов пользователей. Платформа первого поколения проектировалась в 2010 году, и была ориентирована в первую очередь на IPTV приставки.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать несколько сотней тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш. Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

...Далее...

Разбор PHP-задач Badoo и новый тест. Как получить оффер в Лондон в феврале

Привет, Хабр! В июле мы проводили рекрутинговое мероприятие для PHP-разработчиков, по результатам которого пять человек получили оффер в наш лондонский офис. Мы продолжаем быстро расти: Android- и iOS-команды с того времени стали на 11 человек больше, поэтому мы снова запускаем конкурс для PHP-разработчиков. Правила те же: покажи высокий результат в тесте, успешно пройди интервью 10 или 11 февраля в Москве — получи оффер в лондонский офис Badoo. Все расходы по приезду на интервью в Москву компания берёт на себя, равно как и всё связанное с дальнейшим переездом в Лондон: рабочие визы членам семьи, 10 000 фунтов стерлингов (≈ 770 000 рублей) на переезд, совершенствование английского, поиск жилья. Чтобы выполнять тестовое задание было интереснее, по многочисленным просьбам (1, 2, 3) под катом мы разберём задачи с предыдущего мероприятия, рассмотрим их правильные решения, и я объясню, почему мы выбрали именно их, а также приведу некоторые примеры, статистику и варианты решений от кандидатов. ...Далее...


Последние посты