LINUX.ORG.RU
ФорумTalks

IBM открыла ядро А2I процессора POWER-A2, но не сам проц:( Низачот.

 , , , ,


0

1

Сабж

На проходящем сейчас саммите Linux Foundation Open Source было анонсировано новое открытое процессорное ядро A2I, базирующееся на этой архитектуре. Новая разработка предназначена для заказных и встраиваемых систем-на-чипе (SoC) сравнительно небольшой мощности. A2I не поддерживает внеочередного исполнения инструкций, но мультипоточность в нём реализована, а главный упор сделан на увеличение пропускной способности по всем каналам передачи данных, что немаловажно для активно растущего сегмента периферийных вычислений.

В основу дизайна A2I легло ядро Edge-of-Network под названием PowerEN, которое использовалось в процессорах общего назначения POWER-A2 в составе HPC-систем и суперкомпьютеров серии IBM BlueGene/Q. Что удивительно, данное ядро не поддерживает спекулятивное исполнение команд, то есть оно не подвержено уязвимостям класса Spectre/Meltdow

При этом надо понимать, что открыто только ядро, а не процессор POWER-A2 целиком. Последний состоял из 18 ядер, одно из которых было служебным, а ещё одно — запасным. L1-кеш был представлен SRAM, а L2 состоял из eDRAM. Помимо обычных ядер в нём имелись отдельные акселераторы для работы с XML, шифрования, компресии и обработки регулярных выражений, а также 4 канала 10GbE. По отзывам тех лет, процессор был невероятно сложным, но, как показала практика, в конечном итоге достаточно эффективным.

★★★★★
Ответ на: комментарий от Shulman

Изначально ядро данной серии разрабатывалось под 45-нм техпроцесс,

Судя по этому, устаревшее

tiinn ★★★★★
() автор топика
Ответ на: комментарий от tiinn

Для задротов, изучающих строение процессорных ядер – это просто подарок с неба, пофиг что устаревшее.

/me Пошел читать код.

qrck ★★
()

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

ncrmnt ★★★★★
()

акселераторы для работы с XML <…> и обработки регулярных выражений

18 ядер, одно из которых было <…> запасным

Суровый энтерпрайз суров o_0

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от ncrmnt

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

Ведь все эти аппаратные примочки начинают иметь смысл только с какого-то объёма данных, чтобы время доступа к акселератору не было выше, чем время обработки тех же данных на CPU.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Либо они рассчитаны на массовый параллелизм. Например, веб-страница хайлоада, которая рендерится с регулярками и к которой обращаются одновременно дохрена пользователей в единицу времени. Но один хрен непонятно, как и самое главное нафига.

ncrmnt ★★★★★
()
Ответ на: комментарий от intelfx

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

Значит, был один какой-то ключевой заказчик, который покупал ibm именно для регулярок, и все существующие на тот момент решения категорически не устраивали его по производительности. Он же, вероятно, и гигаXMLи мучал

tiinn ★★★★★
() автор топика
Ответ на: комментарий от ncrmnt

1.5.2 Auxiliary Execution Unit (AXU) Port
This interface provides the A2 core with the flexibility to attach a tightly-coupled coprocessor-type macro incorporating instructions that go beyond those provided within the processor core itself. The AXU port provides sufficient functionality for attachment of various coprocessor functions such as a fully-compliant Power ISA floating-point unit (single- or double-precision), multimedia engine, DSP, or other custom function implementing algorithms appropriate for specific system applications.

nvidia
()
Ответ на: комментарий от nvidia

Хорошо, у тебя есть расширения набора команд для парсинга регулярок/xml. Отлично, это сразу доступно для юзерспейса без kernel интерфейса. А теперь внимание вопрос, как заставить библиотеки это использовать? Варианта два. Ручные правки и костыли (ибо обычно либы не расчитаны на офлоад, правки будут выглядеть как говно и мейнтейнеры их не примут в апстрим). Правки компилятора (еще больше веселья и вопросов). И оба варианта так себе ;(

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 1)
Ответ на: комментарий от ncrmnt

как заставить библиотеки это использовать?

Вы забыли третий вариант: написать свои библиотеки, и их юзать. Я ж говорю, скорее всего, всё это делалось под одного-единственного заказчика для одной-единственной проги.

tiinn ★★★★★
() автор топика
Ответ на: комментарий от ncrmnt

Ну например, держишь небольшую команду, которая встраивает #ifdef’ы в pcre, oniguruma и libxml (но не в перл, ибо нахер)

shimon ★★★★★
()
Ответ на: комментарий от ncrmnt

Ну например, когда ты отправляешь заявку на услугу в Госуслугах, то получаешь XML своего запроса (раньше в интерфейсе можно было скачать, сейчас хз, давно не пользовался).

Чтобы не раскрывать никаких секретов, представим какую-нибудь сферическую систему в вакууме :) И в этой сферической системе всё делается на XML, XSLT-трансформациях, и регулярках. Всё общение между сервисами (снаружи системы) и микросервисами (внутри системы) - это очереди сообщений (вроде ActiveMQ), которые передают XML-документы. Зачастую это что-то самопальное, но иногда это может быть обычный SOAP. Управляется это всё какой-нибудь Java и фреймворками вроде Apache Camel и Apache CXF.

Регулярки нужны, например, чтобы парсить поля в разных форматах, которые не были разобраны структурно в XML и переданы как строки, самое простое - взять ФИО-как-строку на вход и превратить в четыре XML-тэга на выходе.

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

stevejobs ★★★★☆
()
Ответ на: комментарий от shimon

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

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

ncrmnt ★★★★★
()
Ответ на: комментарий от ncrmnt

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

Ну может и нет. Вот у Apple дохерища живых денег в загашнике и сама она стоит триллион, а как тестировать свои продукты, так «ресурсов нет» сразу. Пути менеджмента неисповедимы. IBM еще более заскорузл.

shimon ★★★★★
()
Ответ на: комментарий от shimon

А через LD_PRELOAD свои реализации подложить уже не вариант?

Evil_And ★★
()
Ответ на: комментарий от ncrmnt

Так это ж не тебе как конечному пользователю продукта, или конечному разработчику продукта, нужно заботиться о костылях. Это разработчики библиотек XML-парсинга должны этим заниматься. Причем скорее всего, эти «разработчики библиотек» - это та же компания, что создала процессор. Ты у себя юзаешь какую-нибудь Java, и не задумываешься ведь, что на процессорах с AVX512 она в JIT будет использовать эти оптимизации, а без него - не будет, и всё в порядке. Это дело разработчиков Java этим заниматься, а тебе как енд юзеру - пожинать плоды.

stevejobs ★★★★☆
()
Ответ на: комментарий от ncrmnt

Например, веб-страница хайлоада, которая рендерится с регулярками и к которой обращаются одновременно дохрена пользователей в единицу времени.

За такое бубенцы отрезать надо

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Если уж включать перфекциониста, то 98% индустрии давно ходило бы евнухами. Остается смириться, что все крутится на костылях и подпорках.

ncrmnt ★★★★★
()
Ответ на: комментарий от ncrmnt

Да, скорее всего сделали свои версии библиотек, поддерживающие нужные фичи

cvs-255 ★★★★★
()
Ответ на: комментарий от ncrmnt

Зачем ifdef? просто делаешь свою версию библиотеки, куда захардкожено то, что надо заказчику и передаешь ее заказчику.

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Ага, и каждая такая либа - maintainence burden, так как каждую новую версию приходится заново патчить. И обязательно найдется потребитель, который поставит ванильную версию на Генте (когда поддерживается какая-то конкретная убанта, например), и будет долбить саппорт, что оно медленно работает.

ncrmnt ★★★★★
()
Ответ на: комментарий от intelfx

Мне больше любопытно, насколько огромными должны быть регулярки и прогоняемые через них данные

типичный парсинг логов

next_time ★★★★★
()
Ответ на: комментарий от next_time

Логи обычно парсят не просто так, а чтобы потом индексировать и куда-то складывать. И вот построение индекса и его I/O на диск у тебя будет занимать гораздо больше времени, чем прогон регулярок.

intelfx ★★★★★
()
Ответ на: комментарий от cvs-255

Зависит конечно от задачи, но простота поддержки и интеграции играют очень большую роль. А то получится как-то так (был на разных сторонах баррикад, и даже одновременно на обеих):

Вариант один: Ты разработчик решения, получаешь от вендора кучу говнокод^W SDK. Если ядру пара-тройка лет и на твое счастье это LTS - повезло. Далее начинаешь копаться в говнокоде, видишь нестандартные интерфейсы для разных аппаратных ништяков, пытаешься их интегрировать в свои решения, ловишь гонки/крэши/непонятно что, потому как обязательно ткнешься в том виде, в котором девелоперы это не предусмотрели. Если твое решение разработано было на другой платформе, то при переносе на вендорный дистриб линукса узнаешь что куча либ старые/несовместимые, начинаешь материться и строчить письма в поддержку. Время идет, дедлайн приближается…

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

ncrmnt ★★★★★
()
Ответ на: комментарий от ncrmnt

Ты сейчас говоришь про что-то, что широко применяемое. Если у IBM есть один жирный заказчик, который захотел одно ядро отдать чисто под регулярки и xml, то там не будет никакого «нестандартного» дистрибутива, не будет нетипичного применения итп. Будет одно конкретное жирное приложение, которое использует данную возможность. И развертываться оно вполне может не в виде приложения на произвольную систему, а сразу в виде готового образа, например, дебиана конкретной версии в который все нужно уже установили и менять не предполагается

cvs-255 ★★★★★
()

акселераторы для работы с XML

Аппаратный XML? Нифигаси

обработки регулярных выражений

Эммм. чво?

процессор был невероятно сложным

Ясен пень сложный это походу сборка ASIC`ков (окаменелый софт) прилепленных на одну кольцевую шину вместе с простецким универсальным АЛУ блоком.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от cvs-255

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

ncrmnt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.