Вот уже в который раз хочется поднять тему многопоточного программирования. Сейчас я попытаюсь донести мысль, что если посмотреть на эту тему под другим - более простым, как мне кажется, углом, то она не будет казаться такой сложной и неприступной для начинающих. В этой статье будет минимум формализма и известных (и не очень) терминов.
Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за GIL, — то остается другое, и, наверное, вполне достоверное: что многопоточность — это сложно, и нам этого, пожалуйста, не надо. И знаете что? Так оно и есть. Многопоточность — это сложно, особенно когда выбираешься за пределы стандартных руководств и попадаешь со своей многопоточной поделкой в реальный мир. И, возможно, вам не нужно. Ни здесь, ни далее я не буду обсуждать целесообразность написания многопоточного кода на Python и сразу перейду к тому, как это делать.
store идут в процессор строго по порядку, то в архитектуре ARM это совершенно не факт. В результате частенько случается, что вполне безопасный код x86 порождает состояние гонки под ARM.
Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.
Из-за чего весь сыр-бор?
Данная статья посвящена параллелизму в C++, сопутствующим сложностям и как их можно обойти, используя библиотеку oneAPI Threading Building Blocks (oneTBB) для упрощения параллельного программирования.
Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и раскладываем их по полочкам.
И на этот раз мы постараемся прийти к согласию касательно согласованной классификации алгоритмов обеспечения консенсуса в системах со множеством участников. Разберём разные виды блокировок, бесконфликтных алгоритмов. А так же попробуем выявить их фундаментальные особенности, проявляющиеся на самых разных масштабах.
Вы можете смотреть это как видео, читать это как статью, либо открыть в интерфейсе проведения презентаций.
В прошлой статье я разбирался с тем как работает GIL, а сегодня меня захватила идея узнать насколько дорого обходится этот GIL для кода, который исполняется у нас на бэкенде. Для этого я решил пропатчить MRI и добавить пару переменных, в которые буду засекать сколько времени поток реально выполнял код, а сколько ничего не делал и ждал пока ему удастся завладеть локом.
В настоящее время большинство высокопроизводительных вычислений мигрируют в сторону кластерных систем, а для них невозможно получить по настоящему высокую производительность без быстрого доступа к распределенным данным. Данная статья посвящена описанию устройства распределенной общей памяти (DSA) с малой латентностью.
MPIRE комбинирует функции, подобные map из multiprocessing.Pool, с преимуществами копирования при записи общих объектов multiprocessing.Process. В пакете также есть простые в работе функции состояния рабочего процесса, информирования о нём и индикатора выполнения. Сокращённым переводом документации делимся к старту курса по Fullstack-разработке на Python.
Давным давно уже уже была написана статья о том что такое GVL (или GIL, кому как привычнее) и как он работает, однако с того времени некоторые вещи поменялись (к примеру, , а так же в Ruby 3.0 завезли Ractor'ы - новую абстракцию для реальной параллельной работы тредов. Мне стало интересно узнать что поменялось в планировщике ruby для реализации множества GVL. В этой статье я попытаюсь понять алгоритм, по которому GVL передается от одного треда к другому, как блокирующее IO позволяет продолжить работать другим тредам, а так же выяснить до сих пор ли операция добавления элемента в массив является атомарной операцией
Через неделю будет выставка ChipEXPO, на которой для начинающих будет школа проектирования железа с упражнениями на FPGA платах, а для более продвинутых - конференция Микроархитектура, верификация и физическое проектирование микросхем.
И на части для школьников, и на части для взрослых будут выступать проектировщики RISC-V процессора из Syntacore / Yadro Станислав Жельнио и Никита Поляков. Сегодня Коммерсант сравнил этот проект с полетом на Луну.
Количество заявок на школу существенно превысило количество посадочных мест, но у нас еще остался небольшой резерв FPGA плат, с бесплатной их раздачей школьникам и преподавателям из далеких от Москвы городов, которые могут принять участие в школе онлайн. В начале этой заметке мы опишем как получить плату и установить софтвер нужный для упражнений.
Далее мы расскажем про новые упражнения в школе этого года - распознавание и генерацию музыки с помощью FPGA и приведем забавные сведения из советской физматшкольной книжки 1963 года как Бах изменил гаммы.
В конце поста мы покажем, как эта деятельность поможет получить в будущем интересные и высокооплачиваемые работы в Apple, Intel, SpaceX, как и самом в модном в этом сезоне российском микроэлектронном проекте - Syntacore / Yadro (в конце поста скриншоты их объявлений).
Здравствуйте, уважаемые читатели.
Обычно, когда речь заходит о создании какого-либо расширения для существующего языка программирования, в воображении неминуемо начинают рождаться разнообразные сложные решения, включающие поиск описания формальной грамматики исходного языка, ее модификации, а затем и применения какого-либо инструмента, позволяющего по данной грамматике либо построить новый компилятор, либо модифицировать существующий компилятор. Причем такие инструменты существуют (bison/flex, yacc/lex, вероятно и многие другие) и успешно используются, несмотря на их явную сложность и громоздкость.
Здесь обсуждаются более простые решения, вполне пригодные для внесения в язык программирования относительно небольших модификаций.
В этой статье хочу рассказать про реальный опыт оптимизации нашей трединговой системы для работы на американских рынках. Как мы с командой работаем с многопоточностью, разбираем связанные с ней проблемы производительности, а также поделиться интересными подходами, которые мы используем для тюнинга нашего софта.
Модуль WebFlux появился в 5й версии фреймворка Spring. Этот микрофреймворк является альтернативой Spring MVC и отражает собой реактивный подход для написания веб-сервисов. В основе WebFlux лежит библиотека Project Reactor, позволяющая легко запрограммировать неблокирующие (асинхронные) потоки (streams), работающие с вводом/выводом данных.
Следует учесть, что WebFlux для работы требуется встроенный в Spring сервер Netty. Со встроенными Tomcat и Jetty настроить реактивность сложнее и они, как минимум, должны поддерживать Servlet 3.1. Следующая диаграмма иллюстрирует особенности окружения, в котором работает WebFlux [1].
До конференции по распределённым системам Hydra осталось менее трёх недель, программа уже готова, и пришло время рассказать о ней Хабру. Под катом — описания всех докладов, а для начала скажем общее:
Прошло больше года с начала глобальной пандемии, вызванной Covid-19, но жизнь так и не вернулась в прежнее русло. Изменения в рабочих процессах претерпели все без исключения сферы бизнеса. Даже IT, где, вопреки распространенному заблуждению, многие сотрудники посещали офис.
Что произошло в жизни IT компаний за это время, и как карантин повлиял на digital-маркетинг? Перемены не ограничились переходом на удаленную работу - они гораздо глубже и серьезнее.
Как при распараллеливании кода не мучиться из-за блокировок? На Хабре уже писали о транзакционной памяти, но когда о ней говорит Морис Херлихи, это особый случай. В 1993-м и Хабра никакого не было, и многоядерные процессоры ещё не заявили о себе — а Морис уже стал соавтором основополагающей работы о транзакционной памяти. Так что он главный в мире авторитет по этому вопросу, и если вам нужно введение в тему, логично слушать его.
В прошлом году на нашей конференции Hydra он выступил с докладом для широкой публики, в котором всё начинается с самых азов, а позже доходит до менее очевидных вещей. Сейчас мы ждём его на Hydra 2021 с новым докладом — а в ожидании этого решили сделать для Хабра текстовый перевод прошлогоднего выступления на русский (видеозапись тоже прилагаем). Далее повествование будет от лица спикера.
Привет, друзья.
Меня зовут Alex Versus и сегодня с вами посмотрим шаблон Singleton, реализацию на языке Golang.
Какая суть?
Одиночка - относится к порождающим шаблонам. Гарантирует:
Вот в чём вопрос! Что лучше - держать всё в одном процессе, или создавать отдельный процесс на каждый кусок состояния, которым нам нужно управлять? В этой статье я немного расскажу об использовании или неиспользовании процессов. Я также расскажу, как отделить сложную логику с отслеживанием состояния от таких проблем, как временное (темпоральное) поведение и межпроцессное взаимодействие.
Но перед тем, как начать, т. к. статья будет длинной, я хотел бы обозначить основные моменты:
• Используйте функции и модули для разделения мыслительных сущностей.
• Используйте процессы для разделения сущностей времени выполнения.
• Не используйте процессы (даже агентов) для разделения сущностей мышления.
Конструкция "мыслительные сущности" здесь относится к идеям, которые есть в нашем разуме, таким как "заказ", "позиция в заказе", "продукт" и т. д. Если эти концепции слишком сложны, то стоит реализовать их в отдельных модулях и функциях для разделения различных сущностей и держать каждую часть нашего кода сфокусированной и целостной.
Использование для этого процессов (например агентов) - это ошибка, которую люди часто допускают. Такой подход существенно упускает функциональную составляющую Elixir и вместо этого пытается имитировать объекты процессами. Реализация, скорее всего, будет хуже, чем простой функциональный подход (или даже эквивалент на языке объектно-ориентированного программирования). Поэтому стоит обращаться к процессам, только когда есть ощутимые выгоды от этого. Организация кода не входит в число этих преимуществ, так что это не лучший повод для использования процессов.
Основные данные вычислительных экспериментов по реорганизации ярусно-параллельной формы (ЯПФ) информационных графов алгоритмов (ТГА) приведены в предыдущей публикации. Цель текущей публикации – показать окончательные результаты исследований разработки расписаний выполнения параллельных программ в показателях вычислительной трудоёмкости собственно преобразования и качества полученных расписаний. Данная работа является итогом вполне определённого цикла исследований в рассматриваемой области.