Skip to content

ALTGAS and Googleplex on a chip

Altgas-io edited this page Apr 2, 2019 · 48 revisions

ALTGAS and "Googleplex-on-a-chip"

Рассмотрим, можно ли реализовать концепцию "Googleplex-on-a-chip", введенную еще в [Microprocessor Report, Intel’s Larrabee redefines GPU, September 29, 2008] в 2008 г.

Googleplex-on-a-chip

Googleplex-on-a-chip

Т.е. можно ли сделать 1000-и ядерный специализированный чип для поиска, в 2019 г.?

Не смотря на то, что примеры 1000-и ядерных чипов "общего назначения" уже существуют [EPIPHANY-V: A 1024-CORE 64-BIT RISC PROCESSOR], можно ли реализовать подобный чип на базе ALTGAS платформы (используя "альтернативный газ") и исключительно для сервиса поиска.

И это может стать значимым и экономически выгодным примером специализированных вычислений на базе ALTGAS.

Т.е., основной вопрос - можно ли создать специализированный "поисковый процессор"?

В дальнейшем будем реализовывать данную стратегию как "специализированный GOYA-микрочип".

Рассмотрим более подробно.

Тестовая задача


Допустим, нам нужно быстро отранжировать по похожести 1 млн. любых документов (обычный запрос в поисковик).

И это может быть любой размеченный смыслами контент.


Рассмотрим вопрос параметризации реальной системы поиска

Будем использовать обычную схему сборки ответа из "инвертированного индекса".

В качестве глобального словаря термов (для кодирования индекса) мы используем Оракул ALTGAS-OLAP. И это довольно эффективное кодирование (нет излишней энтропии, из-за множества общих префиксов, и это свойство "хорошо" подходит для сжатия информации).

Тракт и этапы поиска вводятся тут

В первой фазе тракта поиска (см. рисунок) - Этапы 1,2 - запрос расширяется близкими смыслами (аналог "расширения морфологией" в обычном поиске). Смыслы представлены в виде онтологических векторов (с Оракула).

Эта фаза не требует масштабной параллельности задач.

Работа производящей функции (Этап 3) - первая масштабно параллельная фаза для вычислений.

Работа производящей функции

Больше промежуточных этапов (Shuffle stage)

Shuffle stage

Появляется очередь задач по перемешиванию (Shuffle stage) - реализуется через работу "производящей функции F".

CROSS-Matrix (матрица пересечений)

Одна отдельная матрица Cross-Matrix иллюстрирует "работу" одной производящей функции (см. рисунок ниже). Роль производящей функции - отображение координат между плоскостями Оракула. В данном случае, AlGas-координаты токенов (смыслов разметки) отображаются на AlGas-координаты документов (контента). Что и запускает механизм подготовки ранжирования.

Допустим, у нас есть определенный набор документов с контентом и эти документы размечены смыслами с Оракула.

Тогда, на любой набор смыслов на входе поиска, Cross-Matrix может "построить отклик" - найти все документы в которых эти смыслы участвуют и построить обратную матрицу.

Отклик на входные адреса смыслов (на дереве-Оракуле) внутри процессора ("поисковая VM")

Отклик на входные адреса смыслов

Т.е. матрица {Токены, Документы} превращается в матрицу {Документы, Токены}, но только для области пересечения с входными данными.

Если пул контента большой, то таких матриц будет очень много. Например, мы можем разбить 1 млн. документов на 1000 таких матриц (т.е. провести шардинг).

Фактически, поиск по такой матрице выполняет роль поиска по инвертированному индексу. То, что матриц много - означает, что "индекс" разбит на множество частей (как и происходит в реальной жизни в Google).

В случае ALTGAS такая матрица может быть "прошита" внутри VM ядра и выдавать "отклик" на входные инструкции - смыслы с Оракула.

Работа ядра будет аналогичной работе поиска по индексу (но пока еще без ранжирования). Ранжирование появится на Этапе 5.

Построение Cross-Matrix

Построение Cross-Matrix

Вопрос быстрой работы Cross-Matrix - это вопрос быстрого поиска по индексу.

В терминах ALTGAS - это вопрос быстрого отклика на AlGas-инструкцию, попадающую в ядро, хранящее Cross-Matrix.

Массивно-параллельные вычисления

Использование таких матриц (CM - Cross-Matrix) дает нам возможность ввести массивно-параллельные вычисления на большом пуле ядер внутри одного чипа.

Допустим, нам нужно быстро ранжировать по похожести 1 млн. любых документов (обычный запрос в поисковик). И это может быть любой размеченный смыслами контент.

Общая архитектура обработки запроса

Общая архитектура обработки запроса

Почему 100 матриц и 1000 ядер?

Каждая матрица аггрегирует новую порцию размеченного контента.

Новый контент поступает непрерывно каждый день.

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

В реальности же, это может быть роутинг с массива FPGA на массив чипов (специализированных поисковых серверов).

Как происходит отображение одной матрицы на ядра чипа?


1000 ядер на чипе и вычисление финального ранжирования

Фаза перехода к универсальным вычислителям

Рассмотрим более подробно "Этап 5" из тракта обработки запроса.

Массив ядер-вычислителей с адаптивной загрузкой

Ядра-вычислители с адаптивной загрузкой

Ядра-вычислители работают по принципу энергетической пропорциональности.

Будем считать, что эффективность TF-IDF в некотором приближении не зависит от размера корпуса документов (при расчете глобальных "частот" термов это влияет).

Поэтому, предположим, что мы разбили весь корпус документов на 1000 частей и каждому из них соответствует своя CROSS-Matrix.

Финальное вычисление похожести сводится к формуле подобного типа:

Формула вычисления похожести

Формула ранжирования

  • и это для каждого документа.

Что не является большим количеством вычислений.

Логично было бы для всех документов из одной CM-матрицы (~1000) вычислить ранжирование на одном ядре (из всего массива ядер чипа GOYA).

Тогда, для отработки одного поискового запроса будет достаточно одного 1000-ядерного GOYA чипа.

Статическая и динамическая архитектура

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

В том числе, она затрагивает и неявные информационные связи, кем-то и когда-то достоверно подтвержденные, в том числе и при помощи Блокчейна (например, через механизмы "ленты Factum" [Лента "глобальной фактологии" - Factum]).

Хорошая "модель близостей" может сильно поднять добавочную стоимость сервиса.

Одновременно, модель вносит и излишнюю параметризацию. И это будет приводить к изменению структуры чипа (если мы захотим поменять FUPE-вычислители близости, например), что недопустимо по экономическим причинам (стоимость редизайна чипа слишком велика). При создании архитектуры чипа мы это учитываем через ввод излишних возможностей для параметризации (Например, как это делает ARM для Machine Learning Processor).

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

"Статичность" и "динамичность" индекса

Изначально весовые коэффициенты смысловых термов (т.е. "уровень важности терма" для заданного документа) берутся из статического Оракула, исходя из выбранной "модели близостей" в ALTGAS (эмпирических моделей может быть несколько).

Эмпирически - "чем глубже смысл находится на дереве онтологии, тем точнее он описывает нужное знание и тем выше его коэффициент".

Близости и связи на Оракуле

Близости и связи на Оракуле

Деление на AlGas и FUPE-Gas. Потоки "энергетической прибыли"

На этапе "ДО-производящей функции F" зарабатывают в основном создатели смыслов Оракула (потенциальная энергия в AKKA-контейнере).

На этапе "ПОСЛЕ-производящей функции F (т.е. массив ядер-вычислителей)" - зарабатывают поставщики FUPE-блоков (fabless-разработчики FUPE-газа). И это должно мотивировать большие корпорации становиться поставщиками в FUPE пространство.

В итоге, данный сервис (AL SEARCH) достаточно эффективно реализует энергетический контейнер AKKA. И является возможной основой для EnergyCoin.

Деление на AlGas и FUPE-Gas

Деление на AlGas и FUPE-Gas

Streamer

Будем раздельно рассматривать фазу подготовки пакетов из "базового поиска" и фазу ранжирования на массиве ядер.

Ранжирование на массиве ядер отражает [кинетическую энергию] запроса.

Streamer нужен для быстрой "заливки" пакетов из "базового поиска" в память вычислителей функции ранжирования. Вычисление ранжирования происходит на специальных FUPE.Search блоках [FUPE для поисковых алгоритмов].

Streamer "знает" о формате данных базового поиска и осуществляет быструю пересылку данных на уровне DMA (direct memory access).

Примерно также работает Streamer в графических чипах (GPU).

Ядра "разбирают" данные для вычислений.

Streamer

Streamer

STREAMER осуществляет быструю доставку данных из "базового поиска" в вычислители для финального ранжирования.

Количество CROSS-матриц будет непрерывно расти с ростом количества размеченных объектов контента.

Роутинг на чипе осуществляется при помощи специальных парсеров на HW уровне.

Роутинг на чипе и hardware parser

Поток данных через Streamer на примере реальных данных от Яндекс


Реальные параметры от Яндекс для Streamer-архитектуры:

"Входящие динамически данные – массив из float[600][16], 38 килобайт. Можно u8[600][16]. Сейчас эти данные на той же машине, что и вычислитель matrix net, сетевого трафика нет.

Эти данные свертываются со статическими данными размера 5 мегабайт. Может быть, будет 10 мегабайт. Характерное время выполнения одного пакета на Core i5 на одном ядре – 500 микросекунд.

Если делать обычный DMA, то для паритета с Core i5 на одном ядре надо гигабайты трафика памяти, зависит от размера блока, которым делается DMA (статические данные используются не все, а разреженные). DMA блоками по 64 байта – 5 гигабайт трафика в секунду. DMA блоками по 256 байт – надо 10 гигабайт трафика в секунду.

Латентности нужны примерно такие, же, вплоть до тысяч микросекунд."


Сравнение с GPU

GPU является потоковым процессором сильно специализированным под известный формат данных (графические растры).

В этом смысле чип GOYA устроен похожим образом, но оптимизирован под другой формат данных - пакеты "поиска" с векторами AlGas.

С другой стороны, в GOYA не нужен очень длинный pipeline, как в GPU, т.к. нет существенных преобразований данных.

Выводы

Проект "Googleplex-on-a-chip" реализует сразу несколько важных концепций:

И это почти гарантированно ведет к возможности реализации EnergyCoin на базе данной технологии.

Влияющие документы

Полезные ссылки

  1. ALTGAS Foundation Whitepaper
  • План развития ALTGAS Foundation
  1. FAQ - Как стать партнером ALTGAS Foundation и зачем это нужно
  • Взаимодействие с ALTGAS Foundation

Основы ALTGAS

FUPE

ALTGAS-Блокчейн

F8-Space

Микро-протоколы

ONTO-Оракул(GONT)

EnergyCoin-StableCoin

Инфраструктура

Приложения

Экономика

R&D

ALTGAS FLOWS

Whitepaper

Проекты (текущие)

AppNotes - все примеры

FAQ - все темы

Clone this wiki locally
You can’t perform that action at this time.