Ну. Если сказать по правде, мы их до сих пор тестим, но есть уже одна, ставшая очевидной, особенность: память не тянет два ядра. Ну не тянет и всё. У нас есть новый кластер, в котором стоит сколько-то блэйдов, в которые засунуты двухпроцессорные платы, на которых установлены двухядерные opteron'ы 285, к каждому из которых воткнуто по 4 гигабайта памяти и соединено это всё с внешним миром через Hyper Transport вот так вот:

внешний мир (в том числе и 1Gb медный ethernet) --HT-- cpu0 --2xHT-- cpu1

Количество ядер у процессоров растет год от года. Но многие программы до сих пор умеют использовать только одно. В небольшой заметке хочу рассказать о дополнении к библиотеке System.Threading, которое называется Parallel Extensions. Это дополнение позволяет на высоком уровне выполнять задачи на всех доступных ядрах/процессорах.

Данная статья является лишь кратким вводным обзором в Parallel Extensions. Так же в конце статьи вы найдете ссылки на ресурсы, которые раскрывают тему во всех деталях.

Если интересно, то смело ныряем под кат.

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

2 недели назад помогал клиенту начать пользоваться бетой Intel Ct. Заодно, как водится, и сам немножко разобрался, и теперь хочу поделиться.

Недавно появилась возможность скачать бету Ct, зарегистрировавшись на сайте. Пока только для Windows, но через некоторое время должна появиться бета и для Linux.

Дайте угадаю: вы, возможно, считаете, что корпоративная культура в QNX немножко ботанская? И если так, то я не виню вас. Мы являемся компанией, которая занимается операционкой, в конце концов. Но знаете, мы тоже можем быть немного бесстыдными.

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

Это рекламный щит, который мы придумали:

Эта история началась в 1997 году. Но, чтобы задать нужную атмосферу, давайте быстро перенесемся в 2010 год и посмотрим снимок загруженности ЦПУ моего компьютера с четырёхядерным процессором:



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

Второе, каждое ядро показывает краткие, но интенсивные всплески загрузки процессора. Здесь это явление может иметь два объяснения:

За последние 10 лет беспилотные летательные аппараты (БПЛА) окончательно перешли из разряда лабораторных образцов в разряд технологий, проверенных в полевых условиях. Недавно проведенные Teal Group исследования показали, что общие сметные расходы на БПЛА удвоятся за следующую декаду с 5 млрд. долл. США в год до 11,3 млрд. в год. Ожидается, что за следующие 10 лет будет потрачено более 94 млрд. долларов. Помимо военного применения (основная ожидаемая область применения), БПЛА применяются в таких областях, как наблюдение за общественной безопасностью, контроль границ, пожаротушение, мониторинг автотрафика. Ожидается коммерческое применение БПЛА в системах связи.

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

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

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

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

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

Данная статья написана в ходе исследования различных библиотек акторов, доступных Java-программисту, в процессе подготовки к чтению курса «Multicore programming in Java».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Это первая статья из цикла статей цель которых сравнить API, быстродействие и реализацию акторов Akka с реализациями в других библиотеках на некоторой модельной задаче. Данная статья предлагает такую задачу и решение на GPars.

GPars — библиотека написанная для Clojure с широкой поддержкой различных подходов к параллельным вычислениям.
Плюсы GPars

• Исходный код написан на Java (в отличии от Akka, написанной на Scala). Всегда интересно посмотреть «что под капотом» на «родном» языке программирования
• GPars представляет собой целый «зоопарк» подходов (Actor, Agent, STM, CSP, Dataflow)
• GPars использует классы из runtime-библиотеки Clojure, написанной на Java. Интересно покопаться

В этой статье я попытаюсь описать терминологию, используемую для описания систем, способных исполнять несколько программ параллельно, то есть многоядерных, многопроцессорных, многопоточных. Разные виды параллелизма в ЦПУ IA-32 появлялись в разное время и в несколько непоследовательном порядке. Во всём этом довольно легко запутаться, особенно учитывая, что операционные системы заботливо прячут детали от не слишком искушённых прикладных программ.



Используемая далее терминология используется в документации процессорам Intel. Другие архитектуры могут иметь другие названия для похожих понятий. Там, где они мне известны, я буду их упоминать.

Цель статьи — показать, что при всём многообразии возможных конфигураций многопроцессорных, многоядерных и многопоточных систем для программ, исполняющихся на них, создаются возможности как для абстракции (игнорирования различий), так и для учёта специфики (возможность программно узнать конфигурацию).

Аннотация

При помощи московского представительства компании IBM мы провели тестирование производительности последних версий СУБД PostgreSQL на серверах Power8, изучили масштабируемость зависимость производительности от количества одновременных запросов, нашли узкие места ограничивающие производительность, предложили новые технические решения и добились рекордной производительности.

Введение

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

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

Для решения таких проблем существуют механизмы управления доступом к ресурсам — использование блокировок, а также пригодные в некоторых случаях неблокирующие (lock-free) подходы. Рост производительности этих механизмов, а также детализация блокировок дает возможность снизить издержки, связанные с одновременным (конкурентным) доступом.

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

За последние три дня вышло несколько новостей про российский процессор Байкал-Т:

1. Российская компания «Т-Платформы» представила процессорный модуль SF-BT1 с Байкалом-Т, который она собирается распостранять среди разработчиков.

2. Также «Т-Платформы» выпустили на основе Байкала-Т тонкий клиент «Таволга терминал», который может работать не только как терминал, но и как автономной компьютер с Linux Debian 8.

3. Т-Платформы показывали и плату для разрабочиков, и терминал на основе Байкала-Т на выставке Embedded World в Нюренберге, в сотрудничестве с британской компанией Imagination Technologies, которая разработала микропроцессорное ядро MIPS P5600, которое использует Байкал-Т.

Я не буду пересказывать все статьи про Байкал-Т, Т-Платформы и Таволгу. Те разрабочики, кто этим интересуется, могут сами сходить по ссылкам и посмотреть параметры плат. Я добавлю некоего информационного гарнира про процессор, его экосистему и историю.

На фотографии ниже — ранние пользователи байкаловских плат. Это инженеры из России, Украины и Казахстана, которые участвуют в разработке микропроцессорного ядра MIPS P5600 и его сотфтверной экосистеме в отделении Imagination Technologies в Санта-Клара, Калифорния: Леонид Егошин (поддержка многоядерности в ядре Линукса), Сергей Вакуленко (симулятор для верификации) и Юрий Панчул (модели интерфейсов шин):



Вообще Байкал-Т — это плод международного сотрудничества, в которое вовлечены в частности:

Всем привет! Наша статья про отечественный процессор Мультиклет, вызвала довольно большой интерес. Правда, многие почему-то решили, что это статья от самого Мультиклета.

В этой статье речь пойдёт об отечественных производителях процессоров (микроконтроллеров). Сейчас эта тема достаточно популярна: например, этому была посвящена конференция OSDay. В общем, в этот раз к нам попала плата от компании «Электронные вычислительно-информационные системы» ЭЛВИС. Мы затащили туда свой Embox и решили, что пользователям хабра было бы интересно узнать и об этой эпопее.