Как стать автором
Обновить
33.18

Параллельное программирование *

Распараллеливаем вычисления

Сначала показывать
Порог рейтинга
Уровень сложности

Вычисляем «магические квадраты» с помощью GPU

Время на прочтение 16 мин
Количество просмотров 29K
Привет, habr.

Тема «магических квадратов» достаточно интересна, т.к. с одной стороны, они известны еще с древности, с другой стороны, вычисление «магического квадрата» даже сегодня представляет собой весьма непростую вычислительную задачу. Напомним, чтобы построить «магический квадрат» NxN, нужно вписать числа 1..N*N так, чтобы сумма его горизонталей, вертикалей и диагоналей была равна одному и тому же числу. Если просто перебрать число всех вариантов расстановки цифр для квадрата 4х4, то получим 16! = 20 922 789 888 000 вариантов.

Подумаем, как это можно сделать более эффективно.


Читать дальше →
Всего голосов 26: ↑23 и ↓3 +20
Комментарии 28

Быстрый ресайз джипегов на видеокарте

Время на прочтение 9 мин
Количество просмотров 9K
В приложениях по работе с изображениями довольно часто встречается задача ресайза джипегов (картинок, сжатых по алгоритму JPEG). В этом случае сразу сделать ресайз нельзя и нужно сначала декодировать исходные данные. Ничего сложного и нового в этом нет, но если это нужно делать много миллионов раз в сутки, то особую важность приобретает оптимизация производительности такого решения, которое должно быть очень быстрым.


Читать дальше →
Всего голосов 23: ↑23 и ↓0 +23
Комментарии 31

From 0.01 TFlops HPL to ASC’18 Application Innovation

Время на прочтение 10 мин
Количество просмотров 2.2K

Привет, Хабр! Продолжаем серию статей об участии команды из Санкт-Петербургского Государственного Университета (мы называем себя EnterTildeDot) на крупнейших в мире студенческих суперкомпьютерных соревнованиях.



В этой статье мы рассмотрим путь на ASC’18 на примере одного участника команды, уделив особое внимание визитной карточке соревнований и современных суперкомпьютеров в целом — Linpack. Ну что ж, давайте посмотрим на секрет достижения рекорда и антирекорда производительности вычислительной системы.

Читать дальше →
Всего голосов 22: ↑21 и ↓1 +20
Комментарии 6

Основы работы с фьютексами

Время на прочтение 10 мин
Количество просмотров 31K
Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

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

Важный момент: фьютексы — это достаточно низкоуровневый инструмент, напрямую его использовать стоит лишь при разработке фундаментальных библиотек, вроде стандартной библиотеки C/C++. Очень маловероятно, что вам понадобится использовать фьютексы в обычном прикладном приложении.
Читать дальше →
Всего голосов 30: ↑30 и ↓0 +30
Комментарии 4

Истории

ASC'18: Упорство и регулярные тренировки как способ достижения цели

Время на прочтение 11 мин
Количество просмотров 3.8K

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


img

Читать дальше →
Всего голосов 19: ↑18 и ↓1 +17
Комментарии 2

CUDA и удалённый GPU

Время на прочтение 7 мин
Количество просмотров 20K

CUDA всем хороша, пока под рукой есть видеокарта от Nvidia. Но что делать, когда на любимом ноутбуке нет Nvidia видеокарты? Или нужно вести разработку в виртуальной машине?


Я постараюсь рассмотреть в этой статье такое решение, как фреймворк rCUDA (Remote CUDA), который поможет, когда Nvidia видеокарта есть, но установлена не в той машине, на которой предполагается запуск CUDA приложений. Тем, кому это интересно, добро пожаловать под кат.


TLDR

rCUDA (Remote CUDA) — фреймворк, реализующий CUDA API, позволяющий использовать удалённую видеокарту. Находится в работоспособной бета-версии, доступен только под Linux. Основная цель rCUDA — полная совместимость с CUDA API, вам не нужно никак модифицировать свой код, достаточно задать специальные переменные среды.

Читать дальше →
Всего голосов 17: ↑17 и ↓0 +17
Комментарии 7

Гетерогенная конкурентная обработка данных в реальном времени строго один раз

Время на прочтение 34 мин
Количество просмотров 14K

Конкурентная сосиска


Аннотация


Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.


Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.


Введение


Разработчик распределенных систем проходит несколько стадий:


Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.


Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.


Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

Читать дальше →
Всего голосов 23: ↑23 и ↓0 +23
Комментарии 6

Изучаем многопоточное программирование в Go по картинкам

Время на прочтение 8 мин
Количество просмотров 68K

Скорее всего, вы уже слышали о языке программирования Go, популярность его постоянно растет, что вполне обоснованно. Этот язык простой, быстрый и опирается на прекрасное сообщество. Один из самых любопытных аспектов языка — это модель многопоточного программирования. Примитивы, положенные в ее основу, позволяют создавать многопоточные программы легко и просто. Эта статья предназначена для тех, кто хочет изучить эти примитивы: горутины и каналы. И, через иллюстрации, я покажу, как с ними работать. Надеюсь, это будет для вас хорошим подспорьем в дальнейшем изучении.
Читать дальше →
Всего голосов 50: ↑48 и ↓2 +46
Комментарии 21

Java и Project Reactor. Эпизод 2

Время на прочтение 9 мин
Количество просмотров 20K


Привет! Удивительно, но первая часть статьи даже кому-то понравилась.
Отдельное спасибо за ваши отзывы и комментарии. У меня для вас плохая хорошая новость: нам ещё есть о чём поговорить! А если точнее, то о некоторых деталях работы Reactor.

Читать дальше →
Всего голосов 26: ↑26 и ↓0 +26
Комментарии 6

Свой асинхронный tcp-сервер за 15 минут с подробным разбором

Время на прочтение 7 мин
Количество просмотров 78K

Ранее я представил пару небольших постов о потенциальной роли Spring Boot 2 в реактивном программировании. После этого я получил ряд вопросов о том, как работают асинхронные операции в программировании в целом. Сегодня я хочу разобрать, что такое Non-blocking I/O и как применить это знание для создания небольшого tcp–сервера на python, который сможет обрабатывать множество открытых и тяжелых (долгих) соединений в один поток. Знание python не требуется: все будет предельно просто со множеством комментариев. Приглашаю всех желающих!
Читать дальше →
Всего голосов 22: ↑19 и ↓3 +16
Комментарии 17

Erlang-like микросервисы в Clojure приложении: это просто

Время на прочтение 7 мин
Количество просмотров 5.8K

Как известно в кругу Erlang разработчиков: только Erlang разработчики знают как "жить" правильно а все остальные "живут" — неправильно. Не пытаясь оспаривать этот факт, приведем пример Clojure приложения в стиле Erlang, используя библиотеку Otplike.

Читать дальше →
Всего голосов 26: ↑26 и ↓0 +26
Комментарии 19

Мифы о кэше процессора, в которые верят программисты

Время на прочтение 6 мин
Количество просмотров 74K
Как компьютерный инженер, который пять лет занимался проблемами кэша в Intel и Sun, я немного разбираюсь в когерентности кэша. Это одна из самых трудных концепций, которые пришлось изучить ещё в колледже. Но как только вы действительно её освоили, то приходит гораздо лучшее понимание принципов проектирования систем.

Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.

С другой стороны, неправильные представления о кэшах часто приводят к ложным утверждениям, особенно когда речь идёт о параллелизме и состоянии гонки. Например, часто говорят о трудности параллельного программирования, потому что «у разных ядер в кэшах могут быть разные/устаревшие значения». Или что квалификатор volatile в языках вроде Java нужен, чтобы «предотвратить локальное кэширование общих данных» и принудительно «читать/записывать только в основную память».
Читать дальше →
Всего голосов 75: ↑70 и ↓5 +65
Комментарии 72

HoleyBeep: объяснение и эксплоит

Время на прочтение 6 мин
Количество просмотров 6.7K


В былые времена люди использовали \a для генерирования неприятных «гудков» из спикеров системных блоков. Это было особенно неудобно, если хотелось генерировать более сложные звуковые последовательности вроде 8-битной музыки. Поэтому Джонатан Найтингейл написал программу beep. Это была коротенькая и очень простая программа, позволявшая тонко настраивать звучание из спикера.

С появлением X-сервера всё стало куда сложнее.

Чтобы beep могла работать, пользователь должен был либо быть суперпользователем, либо являться владельцем текущего tty. То есть beep всегда будет работать у root-пользователя или у любого локального, но не будет работать у не-root удалённого пользователя. При этом любой терминал (например, xterm), подключённый к X-серверу, считается «удалённым», и поэтому beep работать не будет.
Читать дальше →
Всего голосов 27: ↑24 и ↓3 +21
Комментарии 8

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн

Go: Хороший, плохой, злой

Время на прочтение 26 мин
Количество просмотров 63K

У Go есть некоторые замечательные свойства, которым посвящён раздел «Хороший». Но когда речь заходит о применении этого языка не для создания API или сетевых серверов (для чего он и был разработан), а для реализации бизнес-логики, то я считаю Gо слишком неуклюжим и неудобным. Хотя даже в рамках сетевого программирования найдётся немало подводных камней как в архитектуре языка, так и в реализации, что делает Go опасным, несмотря на его кажущуюся простоту.

Читать дальше →
Всего голосов 113: ↑109 и ↓4 +105
Комментарии 190

Руководство по фоновой работе в Android. Часть 4: RxJava

Время на прочтение 5 мин
Количество просмотров 13K

Обработка событий — это цикл.

В прошлой части мы говорили об использовании thread pool executors для фоновой работы в Android. Проблема этого подхода оказалась в том, что отправляющий события знает, как должен быть обработан результат. Посмотрим теперь, что предлагает RxJava.

Дисклеймер: это не статья о том, как использовать RxJava в Android. Таких текстов в интернете и так прорва. Этот — о деталях реализации библиотеки.
Читать дальше →
Всего голосов 36: ↑32 и ↓4 +28
Комментарии 1

Разбор основных концепций параллелизма

Время на прочтение 17 мин
Количество просмотров 63K
Всем кофе!

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

Поехали!

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

РАЗДЕЛ 1

Вступление

С момента своего создания Java поддерживает ключевые концепции параллелизма, такие как потоки и блокировки. Эта памятка поможет Java-разработчикам, работающим с многопоточными программами, понять основные концепции параллелизма и способы их применения.

РАЗДЕЛ 2

Концепции

Концепция Описание
Atomicity (атомарность) Атомарная операция — это операция, которая выполняется полностью или не выполняется совсем, частичное выполнение невозможно.
Visibility (видимость) Условия, при которых один поток видит изменения, сделанные другим потоком

Таблица 1: Концепции параллелизма

Читать дальше →
Всего голосов 17: ↑15 и ↓2 +13
Комментарии 12

Достижимость нижней границы времени исполнения коммита распределенных отказоустойчивых транзакций

Время на прочтение 12 мин
Количество просмотров 8.1K

Предисловие


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


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

Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Комментарии 7

Многопоточность на корабликах

Время на прочтение 8 мин
Количество просмотров 66K

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


Статья рассчитана для новичков, которые недавно начали свое знакомство с миром многопоточноcти на JAVA.
Читать дальше →
Всего голосов 21: ↑21 и ↓0 +21
Комментарии 7

Software Transactional Memory на Free-монадах

Время на прочтение 13 мин
Количество просмотров 7.7K
Осознав, что я давно не писал на Хабр ничего полезного о ФП и Haskell, и что имеется вполне отличный повод для технической статьи, — решил тряхнуть стариной. Речь в статье пойдет о Software Trasactional Memory (STM), которую мне удалось реализовать на Free-монадах при участии ADTs (Algebraic Data Types) и MVars (конкурентные мутабельные переменные). И, в общем-то, Proof of Concept оказался крайне простым, в сравнении с «настоящим» STM. Давайте это обсудим.

Software Transactional Memory

Читать дальше →
Всего голосов 39: ↑39 и ↓0 +39
Комментарии 13

Изучаем параллельные вычисления с OpenMPI и суперкомпьютером на примере взлома соседского WiFi

Время на прочтение 11 мин
Количество просмотров 17K

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



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

Читать дальше →
Всего голосов 16: ↑15 и ↓1 +14
Комментарии 4

Вклад авторов