Возможности конкурентной обработки появляются в программе по разным причинам: некоторые связаны с расширением возможностей платформы, другие вводятся вместе с новым API, поступающим в стандартную библиотеку, некоторые связаны со сменой парадигмы и переменами в наших представлениях. В этой статье будет рассмотрено три способа решения одной и той же задачи, но с применением отличающихся инструментов и парадигм.
В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы
⚠️ Материал средней сложности
С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)
Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.
А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?
Закончим мы главу несколькими, возможно, пугающими выводами об объемах работы, приемлимой для того чтобы обеспечить производительную работу приложения на пуле потоков.
Также отмечу, что материал постепенно переходит от начального уровня сложности ? через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.
Threading Building Blocks (TBB) — популярная библиотека для параллельного программирования на C++ с открытым исходным кодом, опубликована на GitHub. Пару лет назад команда разработки решилась на глобальный рефакторинг библиотеки (проект TBB revamp), в который удалось вписать долгожданную смену системы сборки с GNU Makefiles на CMake. Свежая версия вышла в релиз в рамках инициативы oneAPI, обновив имя на oneTBB. В этой статье я расскажу про то, как подключить oneTBB в CMake-проект и как собрать, протестировать и установить oneTBB.
Microsoft продолжает развивать свои учебные программы и курсы. Так, в конце прошлого года мы анонсировали возможность сдачи базовых (и некоторых продвинутых) экзаменов на русском языке. Мы также писали о том, что российские ВУЗы начали открывать у себя центры сертификации, чтобы студентам было проще сдавать экзамены по нашим продуктам и платформам, начав свою карьеру с хороших позиций.
Одним из ключевых базовых экзаменов Microsoft в настоящее время является AZ-900, который открывает дверь в мир Azure. Сам экзамен доступен на русском языке, однако долгое время основные материалы были доступны только на английском. Поэтому мы рады анонсировать выход перевода нашего официального руководства по сдачи экзамена AZ-900 на русском языке. И как маленький бонус мы также немного расскажем о книге «Параллельное программирование на C# и .NET Core».
Над переводами данных книг работали наши партнеры из молодой компании Devs Universe, а редактором выступил уже известный нашим читателям Вячеслав Черников, в прошлом эксперт по Xamarin, а в настоящее время архитектор решений Azure.
Здравствуйте, уважаемые читатели.
Хочу написать здесь об одном из своих проектов -- языке Planning C (v2.0). Он является расширением C++, дополняющим базовый язык рядом новых конструкций. В настоящее время проект доступен в репозитории (исходный код прототипного транслятора-препроцессора, множество примеров, конвертер простых программ MPI->Planning C). От других языков Planning C отличается тем, что многие его новые конструкции построены на базе так называемых процедур с планированием повторного входа, которые в первую очередь удобны для программирования некоторых алгоритмов, использующих стек, дек или очередь (но могут использоваться и для программирования произвольных алгоритмов). Язык содержит различные средства алгоритмизации и распараллеливания, более-менее унифицированные и для обычных в наше время компьютеров с многоядерными процессорами, и для видеокарт, и для кластерных систем. Во второй версии языка были введены стандартные средства расширения языка новыми конструкциями, «интеллектуальная» мемоизация и еще некоторые возможности. Надеюсь, кому-нибудь данный язык покажется интересным, может быть даже перспективным для применения и/или развития. Сам я иногда им пользуюсь для быстрого написания некоторых расчетных параллельных программ.
В этой статье напишу лишь о самых базовых возможностях языка, преимущественно на примерах. Если тема вызовет интерес, то, возможно, впоследствии напишу еще одну-две статьи о «продвинутых»/необычных возможностях.
Проект aztotmd основан на классической молекулярной динамике и содержит основной функционал для классических расчётов, но также и ряд экспериментальных особенностей: непостоянное поле сил и излучательный термостат. Программа распараллелена с помощью технологии CUDA. Здесь представлена инструкция по работе с программой.
Возможности и ограничения
Требуется видеокарта NVidia с computational capability > 2.2. Программа основана на численном интегрировании уравнений движения скоростным алгоритмом Верле. Опции:
+ периодические граничные условия и только в форме прямоугольного параллелепипеда;
+ парные потенциалы: 6 обычных и 1 температуро-зависимый;
+ 3 способа учета электростатики: наивный, суммирование по Эвальду и метод Феннеля и Гецельтера;
+ 2 термостата: Нозе-Гувера и излучательный;
+ валентные связи;
+ валентны углы;
+ внешнее электрическое поле с постоянным градиентом;
+ возможность динамического образования/удаления валентных связей (включая водородные) и валентных углов;
Рецепт параллельных вычислений Fork/Join или Map/Reduce:
- разбить задачу на куски;
- посчитать куски по-отдельности;
- склеить вместе.
Неотрицательная сумма (a, b) -> max(0, a + b) неассоциативна и результат зависит от порядка склейки. Она сломает Fork/Join и результат будет некорректен. Магией моноида починить на Java, SQL и Haskell за 5 минут, но
В этой статье мне хотелось бы поговорить о двух аспектах программирования, которые лично у меня всегда вызывают много вопросов, а рекомендации от мэтров не дают исчерпывающих ответов.
Здесь я попытаюсь изложить некую стратегию-рекомендацию, которую я вывел для себя на данном этапе, и применимую для различных языков программирования общего назначения. Тем не менее, для пущей наглядности, будут примеры на конкретных ЯП.
Итак, я хотел бы поговорить о разумной обработке ошибок и безопасном многопоточном кодировании.
Что общего между популярным у хоббистов компьютером Синклер ZX Spectrum и космической станцией Juno, которая сейчас вращается вокруг Юпитера? И на одном, и на другом стоит процессор с архитектурой Zilog. На Синклере просто Z80, а на Juno - радиационно стойкий Y180-S. Y180-S спроектировал Монте Далримпл (Monte J. Dalrymple), выпускник Беркли, который проработал 16 лет в Zilog, после чего сделал собственный бизнес, компанию под названием Systemide.
Мы связались с Монте и он согласился выступить перед российскими слушателями, рассказать о всяких занятных ситуациях при проектировании процессоров.
Существующие распространенные парадигмы программирования, несмотря на прогресс в области разработки средств программирования, интуитивно недоступны специалистам предметных областей, охваченных автоматизацией, особенно в области управления технологическими процессами и механизмами. Налицо усиление проблемы семантического разрыва. Обосновывается и описывается альтернативная концепция распределенного программирования на основе потоков данных между узлами коллектива вычислителей. В предлагаемой парадигме можно описывать алгоритмы на уровне понятий предметной области и успешно решать задачи распределенного программирования.
Вот уже в который раз хочется поднять тему многопоточного программирования. Сейчас я попытаюсь донести мысль, что если посмотреть на эту тему под другим - более простым, как мне кажется, углом, то она не будет казаться такой сложной и неприступной для начинающих. В этой статье будет минимум формализма и известных (и не очень) терминов.
Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за 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.