Предисловие

Недавно прочитал очередную статью из серии: "мы лучше двухфазного коммита". Здесь я не буду анализировать содержания этой статьи (хотя, подумываю о том, чтобы дать развернутый анализ). Задача моего опуса — предложить самый эффективный вариант распределенного коммита с точки зрения временных задержек. Конечно, такой коммит дается высокой ценой. Однако цель — дать оценку и показать, что двухфазный коммит не является тормозным, как многие считают.

Стоит также отметить, что здесь не будет натурных экспериментов и фейковых сравнений. Будут просто даны алгоритмы и теоретический анализ. При желании, можно самостоятельно реализовать и проверить на практике. Конечно, было бы куда лучше, чтобы это было описано в текущей статье, но все упирается в свободное время и мотивацию. На мой взгляд, описать алгоритмы более важно, чем привести графики, т.к. графики по алгоритмам может нарисовать почти каждый, обратное же не верно.

Задача производитель/потребитель

Software Transactional Memory

Во время написания диссертации одним из направлением исследований было распараллеливание поиска в пространстве состояний на вычислительных кластерах. У меня был доступ к вычислительному кластеру, но не было практики в программировании для кластеров (или HPC — High Performance Computing). Поэтому прежде чем переходить к боевой задаче, я хотел поупражняться на чем-то простом. Но я не любитель абстрактных hello world без реальных практических задач, поэтому такая задача быстро нашлась.

Всем известно, что полный перебор является самым низкоэффективным способом подбора паролей. Однако с появлением суперкомпьютеров появилась возможность существенно ускорить данный процесс, поскольку, как правило, перебор параллелится практически без накладных расходов. Поэтому, теоретически, на кластере можно ускорить процесс с линейным коэффициентом, т.е. имея 100 ядер — ускорить процесс в 1000*k раз (где 0.0 < k <= 1.0). Так ли это на практике?

Всем привет! Меня зовут Лёха, и я работаю бэкенд-разработчиком в FunCorp. Сегодня мы поговорим про реактивное программирование, библиотеку Reactor и немного про веб.

Реактивное программирование часто «подвергается упоминанию», но если вы (как и автор статьи) всё ещё не знаете, что это такое — устраивайтесь поудобнее, попробуем разобраться вместе.

На конференции JBreak я не читал задачки спонсоров специально. Ну, конечно, кроме ада от Excelsior: уж эти ребята всем задали жару. А тут принесли мне листок от СКБ Контур, смотри, мол, посмейся. Я посмеялся: первая задача действительно выглядела настолько наивно сформированной и недоопределённой, что даже не хотелось идти к стенду и убеждать в этом сотрудников компании. Я про это почти забыл, однако тут на Хабре появился авторский разбор этой задачи, не лишённый некоторой глубины. Даже про modCount написали. Выходит, зря я смеялся?

Привет всем, кто пишет код для .NET, особенно многопоточный. Редко встретишь потокобезопасный код без потокобезопасных коллекций, а значит, нужно уметь ими пользоваться. Я расскажу о самой популярной из них — ConcurrentDictionary. В ней спрятано на удивление много интересных сюрпризов: как приятных, так и не очень.

Сначала разберём устройство ConcurrentDictionary и вычислительную сложность операций с ним, а затем поговорим об удобных трюках и подводных камнях, связанных с memory traffic и сборкой мусора.

Сообщество Rust в последнее время сконцентрировало много своих усилий на асинхронном вводе/выводе, реализованном в виде библиотеки Tokio. И это замечательно.

Многим из участников сообщества, тем, которые не работали с веб-серверами и связанными с этим вещами, не ясно, чего же мы хотим добиться. Когда эти вещи обсуждались во времена версии 1.0, я тоже имел смутное представление об этом, никогда прежде не работав с этим раньше.

• Что это такое — Async I/O?
• Что такое корутины (coroutines)?
• Что такое легковесные нити (threads)?
• Что такое футуры? (futures)?
• Как они сочетаются между собой?

Рассмотрим модели многопоточности на примере Rust и Go.

Аннотация

Оффтоп

В названии статьи не поместилось — данные результаты считаются таковыми по версии рейтинга Graph500. Также хотелось бы выразить благодарность компаниям IBM и RSC за предоставленные ресурсы для проведения экспериментальных запусков во время исследования.

Введение

Поиск в ширину (BFS) является одним из основных алгоритмов обхода графа и базовым для многих алгоритмов анализа графов более высокого уровня. Поиск в ширину на графах является задачей с нерегулярным доступом к памяти и с нерегулярной зависимостью по данным, что сильно усложняет его распараллеливание на все существующие архитектуры. В статье будет рассмотрена реализация алгоритма поиска в ширину (основного теста рейтинга Graph500) для обработки больших графов на различных архитектурах: Intel х86, IBM Power8+, Intel KNL и NVidia GPU. Будут описаны особенности реализации алгоритма на общей памяти, а также преобразования графа, которые позволяют достичь рекордных показателей производительности и энергоэффективности на данном алгоритме среди всех одноузловых систем рейтинга Graph500 и GreenGraph500.