Эта статья представляет собой формализованный ответ на публикацию на форуме IDZ. Проблема, которую описывал автор исходной публикации, заключалась в том, что производительность работы кода не увеличивалась в достаточной степени при использовании OpenMP на 8-ядерном процессоре E5-2650 V2 с 16 аппаратными потоками. Потребовалось некоторое время на форуме, чтобы помочь автору публикации и предоставить ему необходимые подсказки, однако времени для оптимизации кода было недостаточно. В этой статье описываются дальнейшие методики оптимизации в дополнение к описанным на форуме IDZ.

Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.

Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.

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

Прошло четыре месяца с прошлой онлайн-встречи ISO-комитета, а значит, настало время собраться опять.



В этот раз в черновик нового стандарта C++23 добавили весьма полезные и вкусные новинки:

• operator[](int, int, int)
• монадические интерфейсы для std::optional
• std::move_only_function
• std::basic_string::resize_and_overwrite
• больше гетерогенных перегрузок для ассоциативных контейнеров
• std::views::zip и zip_transform, adjacent, adjacent_transform

Подробности об этих и других (даже более интересных!) вещах, а также о том, что за диаграмма стоит в шапке, ждут вас под катом.

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

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

Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.

Это Лесли Лэмпорт — автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Это он впервые, ещё в 1979 году, ввёл понятие последовательной согласованности, а его статья «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs» получила премию Дейкстры (точней, в 2000 году премия называлась по-старому: «PODC Influential Paper Award»). Про него есть статья в Википедии, где можно добыть ещё несколько интересных ссылок. Если вы в восторге от решения задач на happens-before или проблемы византийских генералов (BFT), то должны понимать, что за всем этим стоит Лэмпорт.

А ещё он скоро приедет на нашу новую конференцию о распределённых вычислениях — Hydra, которая состоится 11-12 июля в Санкт-Петербурге. Давайте посмотрим, что это за зверь такой.

Становится уже доброй традицией — все любопытное, что появилось на Хаскеле — повторять на Эликсире.

Первой ласточкой были «Примерно 20 строк для подсчета слов», появившиеся как алаверды на «Побеждая C двадцатью строками Haskell: пишем свой wc» от 0xd34df00d — сегодня же я наткнулся на «Перевозим волка, козу и капусту через реку с эффектами на Haskell» от iokasimov и тоже не устоял.

Итак, встречайте: ленивый полный асинхронный параллельный перебор против алгебраических эффектов.

https://www.youtube.com/playlist?list=PLwr8DnSlIMg0KABru36pg4CvbfkhBofAi

Как-то на Хабре мне попалась довольно любопытная статья “Научно-технические мифы, часть 1. Почему летают самолёты?”. Статья довольно подробно описывает, какие проблемы возникают при попытке объяснить подъёмную силу крыльев через закон Бернулли или модель подъёмной силы Ньютона (Newtonian lift). И хотя статья предлагает другие объяснения, мне бы всё же хотелось остановиться на модели Ньютона подробнее. Да, модель Ньютона не полна и имеет допущения, но она даёт более точное и интуитивное описание явлений, чем закон Бернулли.

Основной недостаток этой модели — это отсутствие взаимодействия частиц газа друг с другом. Из-за этого при нормальных условиях она даёт некорректные результаты, хотя всё ещё может применяться для экстремальных условий, где взаимодействием можно пренебречь.

Я же решил проверить, что же произойдёт в модели Ньютона если её улучшить. Что если добавить в неё недостающий элемент межатомного взаимодействия? Исходный код и бинарники получившегося симулятора доступны на GitHub.

Перед тем как мы начнём, я бы хотел сразу обозначить, что это статься не о физике самой модели. Эта статья о GPGPU-программировании. Мы не будем рассматривать физические свойства самой модели, потому что она груба и не подходит для настоящих расчётов. И всё же, эта неточная модель даёт куда более интуитивное описание явления подъёмной силы, чем закон Бернулли.

Цель статьи: хочу поделится опытом создания трех вычислительных кластеров Matlab, а также их удаленного администрирования.

Небольшое вступление

При исследовании/моделировании разных природных явлений (и не только), изредка появляется потребность в больших вычислительных способностях с которыми домашний ПК справится уже не в силе (каким бы мощным он небыл). В конце концов, эта потребность появились и у меня.

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

Итак, обо всем — по порядку

Железо в наличии:

Дома: комп (Phenom II x4 840, 7x64) и ноут (Athlon II Dual-Core M320, 7x64) соединенные в одну сеть старым добрым маршрутизатором DIR-300.

Дома у девушки: комп (i5 4440, 7x64).

На работе: 10 компов (Athlon II Dual-Core, XPx86) (связанных в одну сеть) в одном помещении и 4 (Athlon II Dual-Core, XPx86) в другом (тоже связанных в одну сеть). Локальной сети между помещениями нет.

На всех вышеперечисленных ящиках присутствует доступ в интернет.

Привет, коллеги.

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

В этой серии из двух статей говорится о том, как структура данных и памяти влияет на производительность. Предлагаются определенные действия для повышения производительности программного обеспечения. Даже простейшие действия, показанные в этих статьях, позволят добиться существенного прироста производительности. Многие статьи, посвященные оптимизации производительности программ, рассматривают распараллеливание нагрузки в следующих областях: распределенная память (например, MPI), общая память или набор команд SIMD (векторизация), но на самом деле распараллеливание необходимо применять во всех трех областях. Эти элементы очень важны, но память также важна, а про нее часто забывают. Изменения архитектуры программ и применение параллельной обработки влияют на память и на производительность.

В этой серии из двух статей о производительности и памяти описываются базовые принципы и приводятся советы для разработчиков по повышению производительности программного обеспечения. Эти статьи затрагивают, в частности, работу памяти и компоновку. В первой части было рассказано об использовании регистров и о применении алгоритмов блокирования для повышения многократного использования данных. В этой части статьи сначала описывается компоновка данных для обычного распараллеливания — программирования для общей памяти с потоками, а затем распределенные вычисления по сетям MPI. В статье описываются понятия, связанные с распараллеливанием: векторизация (инструкции SIMD) и работа с общей памятью (многопоточная архитектура), а также вычисления с распределенной памятью. И наконец, в этой статье сравниваются компоновки данных «массив структур» (AOS) и «структура массивов» (SOA).

Процесс вычисления весового спектра

Первопричина

Данная статья обязана своим появлением одному достаточно давнему вопросу, который был задан в группе русскоязычной поддержки Wolfram Mathematica. Однако, ответ на него сильно разросся и в итоге стал жить самостоятельной жизнью и даже обзавелся собственными проблемами. Как понятно из названия статьи, задача была посвящена вычислению весового спектра, а значит напрямую относится к дискретной математике и линейной алгебре. Здесь же демонстрируется решение на языке программирования Wolfram Language. Не смотря на то, что суть задачи очень проста (для простых базисных векторов она вполне решается в уме), гораздо больший интерес представляет процесс оптимизации алгоритма нахождения весового спектра. Авторы придерживаются мнения, что рассматриваемая в данной статье задача и способы ее решения очень хорошо показывают способы применения таких приемов в языке Wolfram как компиляция и параллелизация. Таким образом основная цель, это показать один из эффективных способов ускорения кода в Mathematica.