Новогодние бенчмарки компьютеров Эльбрус

Продолжение статьи Большое тестирование процессоров различных архитектур. В этот раз я решил измерить производительность конкретных сред/языков программирования (C#, Java, JavaScript, Python, Lua) на компьютерах с процессорами Эльбрус и сравнить их с компьютерами (даже телефонами) на процессорах архитектурой ARM и X86-64.

Языки программирования:

• C#
• PHP
• JavaScript (Browser, не NodeJS)
• Java
• Python
• Lua

Список тестов

• Dhrystone (http://www.roylongbottom.org.uk/#anchorSource)
• Whetstone (http://www.roylongbottom.org.uk/#anchorSource)
• Scimark 2 (Original sources: https://math.nist.gov/scimark2/download.html)
• Linpack (Based on: https://github.com/fommil/netlib-java/blob/master/perf/src/main/java/com/github/fommil/netlib/Linpack.java)
• Generic:
  
  • Loops
  • Conditions
  • Arithmetics
  • Math
  • Array speed
  • String manipulation
  • Hash algorithms

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

Тестовые стенды и их процессоры

А пока можете опробовать JavaScript версию бенчмарка: http://laseroid.azurewebsites.net/js-bench/

Стенды на процессорах x86 (i386) х86-64 (amd64):

• Core i7-2600, 4 ядра 8 потоков, 3.4 ГГц
• AMD A6-3650, 4 ядра, 2.6 ГГц
• Atom Z8350, 4 ядра, 1440 МГц
• Core i3-m330, 2 ядра 4 потока, 2.13 ГГц
• Pentium 4 2800, 1 ядро, 2.8 ГГц
• Allwinner A64 (Orange Pi Win), 4 ядра Cortex A53, 1152 МГц
• Qualcomm 625 (Xiaomi Note 4X), 8 ядер, 2 ГГц
• Эльбрус 8С 1300 МГц, 8 ядер
• Эльбрус 8С x4 1300 МГц, 8 ядер (сервер 4 процессорный)
• Эльбрус 8СВ 1550 МГц
• Эльбрус 2С+ 500 МГц, 2 ядра
• Эльбрус 4C 750/800 Мгц, 4 ядра
• Эльбрус 1C+ 985/1000 МГц, 1 ядро

Компилируемые бенчмарки на C/C++

Таблица с результатами с прошлой статьи

Тут выходит так: компьютеры на Эльбрусах имеют сопоставимую производительность с Intel Core i7 2600, если бы он работал на частоте 1200 1300 МГц (Для Эльбрус-8С), кроме теста MP MFLOPS, который хорошо распараллеливается компилятором LCC и для Эльбрус 8СВ выдаёт 325 ГФлопс, где Core i7 2600 выдавал
85 ГФлопс (Это с SSE, без AVX).

Задержки кеша. Тест TLB от Линуса Торвальдса

Задержки кеша на Эльбруса 8СВ таковы:

• L1: 3 такта с 1,94 нс
• L2: 11 тактов с 7,1 нс
• L3: 3 такта с 21,31 нс
• ОЗУ: 90-180 тактов с 117 нс

Характеристики кеша для Эльбрус 8С можно посмотреть здесь: Архитектура Эльбрус 8С

Исходный код: Test TLB

Тесты памяти STREAM

Array size = 10000000 (elements), Offset = 0 (elements)

Memory per array = 76.3 MiB (= 0.1 GiB).

Total memory required = 228.9 MiB (= 0.2 GiB).

Исходный код: STREAM

Geekbench 4/5 (В режиме RTC: x86 -> e2k трансляция)

Geekbench 5

Geekbench 4

Crystal Mark 2004 (В режиме RTC: x86 -> e2k трансляция)

Процессор Эльбрус-8С 1.3 ГГц на уровне AMD Phenom II X4 965 3.4 ГГц 4 ядра. 8СВ на 20% быстрее.

Бенчмарки сред/языков программирования

А теперь переходим к бенчмаркам языков программирования (C#, Java, JavaScript, Python, Lua).

Исходный код здесь: https://github.com/EntityFX/EntityFX-Bench
Исходный код для прощлых бенчмарков можете найти тут: https://github.com/EntityFX/anybench

Микро бенчмарки

В цикле с большим числоv итераций проводим некоторые операции и замеряем время выполнения данного куска кода. Ниже буду приводить примеры на языке Python.

Arithmetics

Замеряет скорость арифметики: в цикле выполняет различные математические операции с замером времени выполнения.

Пример кода на Python:

    @staticmethod    def _doArithmetics(i : int) -> float:        return math.floor(i / 10) * math.floor(i / 100) * math.floor(i / 100) * math.floor(i / 100) * 1.11) + math.floor(i / 100) * math.floor(i / 1000) * math.floor(i / 1000) * 2.22 - i * math.floor(i / 10000) * 3.33 + i * 5.33

Math

Замеряет скорость математических функций (Cos, Sin, Tan, Log, Power, Sqrt):

    @staticmethod    def _doMath(i : int, li : float) -> float:        rev = 1.0 / (i + 1.0)        return (math.fabs(i) * math.acos(rev) * math.asin(rev) * math.atan(rev) + math.floor(li) + math.exp(rev) * math.cos(i) * math.sin(i) * math.pi) + math.sqrt(i)

Loops

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

Conditions

Замеряет скорость работы условий.

        d = 0        i = 0; c = -1        while i < self._iterrations:             c = ((-1 if c == (-4) else c))            if (i == (-1)):                 d = 3            elif (i == (-2)):                 d = 2            elif (i == (-3)):                 d = 1            d = (d + 1)            i += 1; c -= 1        return d

Array speed (Memory, Random Memory)

Замеряет скорость чтения из массива в переменную (последовательно или со случайными индексами)

    def _measureArrayRead(self, size) :        block_size = 16        i = [0] * block_size        array0_ = list(map(lambda x: random.randint(-2147483647, 2147483647), range(0, size)))        end = len(array0_) - 1        k0 = math.floor(size / 1024)        k1 = 1 if k0 == 0 else k0        iter_internal = math.floor(self._iterrations / k1)        iter_internal = 1 if iter_internal == 0 else iter_internal        idx = 0        while idx < end:             i[0] = (array0_[idx])            i[1] = (array0_[idx + 1])            i[2] = (array0_[idx + 2])            i[3] = (array0_[idx + 3])            i[4] = (array0_[idx + 4])            i[5] = (array0_[idx + 5])            i[6] = (array0_[idx + 6])            i[7] = (array0_[idx + 7])            i[8] = (array0_[idx + 8])            i[9] = (array0_[idx + 9])            i[0xA] = (array0_[idx + 0xA])            i[0xB] = (array0_[idx + 0xB])            i[0xC] = (array0_[idx + 0xC])            i[0xD] = (array0_[idx + 0xD])            i[0xE] = (array0_[idx + 0xE])            i[0xF] = (array0_[idx + 0xF])            idx += block_size        start = time.time()        it = 0        while it < iter_internal:             idx = 0            while idx < end:                 i[0] = (array0_[idx])                i[1] = (array0_[idx + 1])                i[2] = (array0_[idx + 2])                i[3] = (array0_[idx + 3])                i[4] = (array0_[idx + 4])                i[5] = (array0_[idx + 5])                i[6] = (array0_[idx + 6])                i[7] = (array0_[idx + 7])                i[8] = (array0_[idx + 8])                i[9] = (array0_[idx + 9])                i[0xA] = (array0_[idx + 0xA])                i[0xB] = (array0_[idx + 0xB])                i[0xC] = (array0_[idx + 0xC])                i[0xD] = (array0_[idx + 0xD])                i[0xE] = (array0_[idx + 0xE])                i[0xF] = (array0_[idx + 0xF])                idx += block_size            it += 1        elapsed = time.time() - start        return (iter_internal * len(array0_) * 4 / elapsed / 1024 / 1024, i)

String manipulation

Скорость работы со строковыми функциями (replace, upper, lower)

    @staticmethod    def _doStringManipilation(str0_ : str) -> str:        return ("/".join(str0_.split(' ')).replace("/", "_").upper() + "AAA").lower().replace("aaa", ".")

Hash algorithms

Алгоритмы SHA1 и SHA256 над байтами строк.

    @staticmethod    def _doHash(i : int, prepared_bytes):        hashlib.sha1()        sha1_hash = hashlib.sha1(prepared_bytes[i % 3]).digest()        sha256_hash = hashlib.sha256(prepared_bytes[(i + 1) % 3]).digest()        return sha1_hash + sha256_hash

Комплексные бенчмарки

Выполнил реализацию популярных бенчмарков Dhrystone, Whetstone, LINPACK, Scimark 2 на всех 5 языках программирования (конечно же использовал существующие исходники, но адаптировал под мои тесты).

Dhrystone

Dhrystone синтетический тест, который был написан Reinhold P. Weicker в 1984 году.
Данный тест не использует операции с плавающей запятой, а версия 2.1 написана так, чтобы исключить возможность сильных оптимизаций при компиляции.
Бенчмарк выдаёт результаты в VAX Dhrystones в секунду, где 1 VAX DMIPS = Dhrystones в секунду делить на 1757.

Whetstone

Whetstone синтетический тест, который был написан Harold Curnow в 1972 году на языке Fortran.
Позже был переписан на языке C Roy Longbottom. Данный тест выдаёт результаты в MWIPS,
также промежуточные результаты в MOPS (Миллионов операций в секунду) и MFLOPS (Миллионы вещественных операций с плавающей запятой в секунду).
Данный тест производит различные подсчёты: производительность целочисленных и операций с плавающей запятой,
производительность операций с массивами, с условным оператором, производительность тригонометрических функций и функций возведения в степень, логарифмов и извлечения корня.

LINPACK

LINPACK тест, который был написан Jack Dongarra на языке Fortran в 70х годах, позже переписан на язык C.
Тест считает системы линейных уравнений, делает различные операции над двумерными (матрицами) и одномерными (векторами).
Используется реализация Linpack 2000x2000.

Scimark 2

SciMark 2 набор тестов на языке C измеряющий производительность кода встречающегося в научных и профессиональных приложениях. Содержит в себе 5 вычислительных тестов: FFT (быстрое преобразование Фурье), Gauss-Seidel relaxation (Метод Гаусса Зейделя для решения СЛАУ), Sparse matrix-multiply (Умножение разреженных матриц), Monte Carlo integration (Интегрирование методом Монте-Карло), и LU factorization (LU-разложение).

Переходим к результатам.

Результаты

Бенчмарки Java

Результаты Java на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков 3.4 ГГц:

• Эльбрус 1С+ в 11 раз медленнее на 1 поток
• Эльбрус 4С в 10 раз медленнее на 1 поток
• Эльбрус 8С в 5,5 раз медленнее на 1 поток
• Эльбрус 8СВ в 4,5 раз медленнее на 1 поток
• Эльбрус 1С+ в 18 раз медленнее на всех потоках
• Эльбрус 4С в 12,5 раз медленнее на всех потоках
• Эльбрус 8С в 3 раз медленнее на всех потоках
• Эльбрус 8СВ в 2,5 раз медленнее на всех потоках

Результаты Java на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков, но на одинаковых частотах:

• Эльбрус 1С+ в 3,5 раз медленнее на 1 поток Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 2,5 раз медленнее на 1 поток Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 2 раз медленнее на 1 поток Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 2 раз медленнее на 1 поток Core i7 2600 на частоте 1,55 ГГц
• Эльбрус 1С+ в 5 раз медленнее на всех потоках Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 2,75 раз медленнее на всех потоках Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 1,15 раз медленнее на всех потоках Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,15 раз медленнее на всех потоках Core i7 2600 на частоте 1,55 ГГц

Для Java делали очень серьёзные оптимизации, поэтому отставание в 2 раза на одинаковых частотах не является плохим результатом.

Про то, как оптимизировали Java можно почитать тут: Java на Эльбрусе

Посмотреть здесь:

Бенчмарки C# (.Net Framework, .Net Core, Mono)

Так как сред исполнения несколько (.Net Framework, .Net Core, Mono), то я старался сравнивать одинаковые среды исполнения, т. е. Mono на e2k c Mono на x86.

Результаты C# (Mono) на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков 3.4 ГГц:

• Эльбрус 1С+ в 15,5 раз медленнее на 1 поток
• Эльбрус 4С в 19 раз медленнее на 1 поток
• Эльбрус 8С в 10,5 раз медленнее на 1 поток
• Эльбрус 8СВ в 8 раз медленнее на 1 поток
• Эльбрус 1С+ в 24 раз медленнее на всех потоках
• Эльбрус 4С в 12,5 раз медленнее на всех потоках
• Эльбрус 8С в 4,5 раз медленнее на всех потоках
• Эльбрус 8СВ в 4 раз медленнее на всех потоках

Результаты C# (Mono) на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков, но на одинаковых частотах:

• Эльбрус 1С+ в 4,5 раз медленнее на 1 поток Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 4,2 раз медленнее на 1 поток Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 3 раз медленнее на 1 поток Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 3 раза медленнее на 1 поток Core i7 2600 на частоте 1,55 ГГц
• Эльбрус 1С+ в 7 раз медленнее на всех потоках Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 3 раза медленнее на всех потоках Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 1,5 раз медленнее на всех потоках Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,2 раз медленнее на всех потоках Core i7 2600 на частоте 1,55 ГГц

Результаты C# (NetCore) в режиме RTC на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков 3.4 ГГц:

• Эльбрус 8С в 3,5 раз медленнее на 1 поток Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 3 раз медленнее на 1 поток Core i7 2600 на частоте 1,55 ГГц
• Эльбрус 8С в 2 раз медленнее на всех потоках Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,5 раз медленнее на всех потоках Core i7 2600 на частоте 1,55 ГГц

Результаты C# (NetCore) в режиме RTC на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков, но на одинаковых частотах:

• Эльбрус 8С в 1,3 раз медленнее на 1 поток Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,2 раз медленнее на 1 поток Core i7 2600 на частоте 1,55 ГГц
• Эльбрус 8С в 1,25 раза быстрее на всех потоках Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,25 раза быстрее на всех потоках Core i7 2600 на частоте 1,55 ГГц

Mono сам по себе является достаточно медленной средой выполнения по сравнению с Net Fremework, а особенно с NetCore (до 3х раз). Что достаточно допустимо. Здесь я не знаю, делали ли оптимизации как это было сделано с Java.

Выходит NetCore в режиме RTC на Эльбрусах работает до 4х раз быстрее чем Mono. Будем ждать нативного NetCore для e2k.

Бенчмарки JavaScript (Браузерные)

JavaScript версия бенчмарка: http://laseroid.azurewebsites.net/js-bench/

Результаты JavaScript на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков 3.4 ГГц:

• Эльбрус 1С+ в 16 раз медленнее
• Эльбрус 4С в 12,5 раз медленнее
• Эльбрус 8С в 6,5 раз медленнее
• Эльбрус 8СВ в 5 раз медленнее

Результаты JavaScript на Эльбрусах в сравнении с Core i7 2600 4 ядра, 8 потоков, но на одинаковых частотах:

• Эльбрус 1С+ в 5 раз медленнее Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 2,75 раза медленнее Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 2,5 раза медленнее Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 2,25 раз медленнее Core i7 2600 на частоте 1,55 ГГц

Другие популярные JavaScript бенчмарки

Octane

Firefox (версии разные)

Kraken Benchmark

Firefox (версии разные)

Sunspider

Firefox (версии разные)

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

Бенчмарки PHP

Результаты PHP на Эльбрусах в сравнении с Core i7 2600 3.4 ГГц:

• Эльбрус 2С+ в 15,5 раз медленнее
• Эльбрус 1С+ в 8 раз медленнее
• Эльбрус 4С в 4,5 раза медленнее
• Эльбрус 8С в 3 раза медленнее
• Эльбрус 8СВ в 2,5 раза медленнее
• Эльбрус R1000 в 12,5 раз медленнее

Результаты PHP на Эльбрусах в сравнении с Core i7 2600, но на одинаковых частотах:

• Эльбрус 2С+ в 2,3 раз медленнее Core i7 2600 на частоте 0,5 ГГц
• Эльбрус 1С+ в 2,3 раз медленнее Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С = Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 1,1 раза медленнее Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,1 раза медленнее Core i7 2600 на частоте 1,55 ГГц
• Эльбрус R1000 в 3,75 раз медленнее Core i7 2600 на частоте 1 ГГц

PHP показывает почти равную скорость на одинаковых частотах с Intel процессорами. Причина проста: здесь МЦСТ делали оптимизацию. Очень удивительно для интерпретируемого языка. Кстати, хочу обратить внимание на то что PHP 7.4 стал быстрее версии PHP 5.6 в 1,5 раза, поэтому я запускал бенчмарки на 2х версиях на Core i7 2600.

Другие популярные PHP бенчмарки

PHP Simple Benchmark

Бенчмарки Python

Так как под Windows не удалось запустить многопоточный Python (я не Питонист, да и времени сделать универсальную многопоточность на всех ОС не было, принимаю патчи), приведу относительно Amd A6 3650, который на 40% медленнее Core i7.

Результаты Python на Эльбрусах в сравнении с Core i7 2600 3.4 ГГц:

• Эльбрус 2С+ в 30 раз медленнее на 1 поток
• Эльбрус 1С+ в 12,5 раз медленнее на 1 поток
• Эльбрус 4С в 15,5 раз медленнее на 1 поток
• Эльбрус 8С в 9 раз медленнее на 1 поток
• Эльбрус 8СВ в 7,8 раз медленнее на 1 поток
• Эльбрус 2С+ в 58 раз медленнее на всех потоках
• Эльбрус 1С+ в 25 раз медленнее на всех потоках
• Эльбрус 4С в 13,5 раз медленнее на всех потоках
• Эльбрус 8С в 4,2 раза медленнее на всех потоках
• Эльбрус 8СВ в 3,8 раза медленнее на всех потоках

Результаты Python на Эльбрусах в сравнении с Core i7 2600, но на одинаковых частотах:

• Эльбрус 2С+ в 4,5 раз медленнее на 1 поток Core i7 2600 на частоте 0,5 ГГц
• Эльбрус 1С+ в 3,6 раз медленнее на 1 поток Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 3,5 раз медленнее на 1 поток Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 3,5 раз медленнее на 1 поток Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 3,5 раз медленнее на 1 поток Core i7 2600 на частоте 1,55 ГГц
• Эльбрус 2С+ в 8,5 раз медленнее на всех потоках Core i7 2600 на частоте 0,5 ГГц
• Эльбрус 1С+ в 7,4 раз медленнее на всех потоках Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 3 раз медленнее на всех потоках Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 1,5 раза медленнее на всех потоках Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 1,35 раза медленнее на всех потоках Core i7 2600 на частоте 1,55 ГГц

Во первых, для Python пока не делалось оптимизаций, которые повысили бы производительность. Во вторых, интерпретируемые языки плохо подходят к VLIW-архитектуре Эльбруса. Но МЦСТ советуют использовать CPython для производительности (Python -> C, а затем компилируем с помощью LCC). Про PyPy c Jit пока ничего не известно, но если потребуется, то такая среда выполнения будет реализована, а это сильно повысит производительность.

Также было замечено, что в некоторых случаях Python в режиме RTC (двоичная трансляция x86-64 в e2k) показывает большую производительность: в арифметике и математике. Значит есть ещё потенциал для оптимизации Python, возможно даже в 2 раза.

Бенчмарки Lua

Результаты Lua на Эльбрусах в сравнении с Core i7 2600 3.4 ГГц:

• Эльбрус 2С+ в 16 раз медленнее
• Эльбрус 1С+ в 6 раз медленнее
• Эльбрус 4С в 10 раз медленнее
• Эльбрус 8С в 6 раз медленнее
• Эльбрус 8СВ в 5 раз медленнее
• Эльбрус R1000 в 9 раз медленнее

Результаты Lua на Эльбрусах в сравнении с Core i7 2600, но на одинаковых частотах:

• Эльбрус 2С+ в 2,4 раза медленнее Core i7 2600 на частоте 0,5 ГГц
• Эльбрус 1С+ в 1,75 раза медленнее Core i7 2600 на частоте 1 ГГц
• Эльбрус 4С в 2 раза медленнее Core i7 2600 на частоте 0,8 ГГц
• Эльбрус 8С в 2,3 раза медленнее Core i7 2600 на частоте 1,3 ГГц
• Эльбрус 8СВ в 2,2 раза медленнее Core i7 2600 на частоте 1,55 ГГц
• Эльбрус R1000 в 2,6 раз медленнее Core i7 2600 на частоте 1 ГГц

У Lua отставание всего в 2 раза на равных частотах, это достаточно тепримо для VLIW-архитектуры.

Выводы

Во сколько раз Core i7 2600 быстрее Эльбрусов:

Во сколько раз Core i7 2600 быстрее Эльбрусов, если бы он работал на частоте Эльбрусов:

Как мы знаем, Эльбрус имеет VLIW архитектуру, у которой повышение производительности достигается путём оптимизации компилируемого кода (Эльбрус имеет явный параллелизм). Также у Эльбруса нет предсказателя переходов и переупорядочивания инструкций (снова всё явно задаётся компилятором).

Следует:

• Компилируемые программы на C/C++ (возможно, другие) будут иметь хорошую производительность. Это достигается патчами участков кода, где нужно оптимизировать производительность и умным компилятором LCC (eLbrus C Compiler).
• Языки с JIT-трансляцией (Java, JavaScript, C# Mono) будут иметь среднюю производительность. Здесь оптимизируют саму среду исполнения. Возможно, также потребуется оптимизировать сами программы.
• Интерпретируемые языки (PHP, Python, Lua) будут иметь низкую производительность. Но оптимизация среды выполнения позволит поднять до среднего уровня.

Другие способы:

• Доработка компилятора LCC.
• Архитектурно-специфические доработки в самой ОС.
• Улучшать архитектуру Эльбрус:
  
  • Поднимать частоту
  • Добавить предсказатель и т.д.

Какие языки ещё хотелсоь бы потестировать:

• Golang (Ждём выпуска)
• Ruby
• Perl

P.S. Поздравляем команду МЦСТ с Новым Годом. Желаем удачи в разработке следующих поколений процессоров. Ждём массового появления устройств на процессорах с архитектурой E2K!

Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.

В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.

Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.

Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Тестовый стенд

Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).

Схематично стенд выглядит следующим образом.

Стенд 1 e2k (Эльбрус)

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)

Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.

Методика тестирования

Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).

Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.

Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).

Выполняться будут основные и популярные сценарии использования СХД, в частности:

первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.

1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.

3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.

5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.

Результаты тестов

Результаты тестов сведены в две таблицы.

Эльбрус 8С (СХД Аэродиск Восток 2-Э12)

Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)

Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.

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

Если говорить о случайной нагрузке небольшими блоками, то:

• с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
• с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:

• и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:

• оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.

О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.

Выводы и ближайшее будущее

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

Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.

При случайной записи небольшими блоками оба процессора показывают равные результаты.

По показателям задержки Эльбрус выглядит значительно лучше Intel-а в потоковой нагрузке, т.е. в последовательном чтении и записи большими блоками.

Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:

• информационные системы с преобладанием операций записи;
• файловый доступ;
• онлайн-трансляции;
• видеонаблюдение;
• резервное копирование;
• медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.

Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.

Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.

Если теперь вернуться к началу статьи и ответить на вопрос, кто же прав: пессимисты, которые говорят, что Эльбрус никакой и никогда не догонит ведущих производителей процессоров, или все-таки оптимисты, которые говорят, что уже почти догнали и скоро перегоним? Если исходить не из стереотипов и религиозных предубеждений, а из реальных тестов, то, однозначно, правы оптимисты.

Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.

Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.

В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.

По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.

Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.

В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:

Общие обновления:

• переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
• много мелких оптимизаций под скоростные твердотельные накопители;
• и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:

• обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
• обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд

Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16G 1 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.

Методика тестирования

Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).

СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).

Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.

В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:

Последовательная нагрузка маленькими блоками 4k

• 100%_read_4k_sequential
• 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k

• 100%_read_4k_random
• 100%_write_4k_random

Последовательная нагрузка большими блоками 128k

• 100%_read_128k_sequential
• 100%_write_128k_sequential

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

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

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

Результаты тестов

Последовательная нагрузка маленькими блоками 4k

100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.

Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.

Случайная нагрузка маленькими блоками 4k

100%_read_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.

Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.

Последовательная нагрузка большими блоками 128k

100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).

А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).

Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4

Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые

Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19

Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые

Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.

В очередной раз мы убедились в отличной работе СХД на Эльбрусе среде, где преобладает последовательная нагрузка, а это аналитические СУБД, онлайн-трансляции, видеонаблюдение, обработка больших данных и т.п.

Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.

Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.

В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).

Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.

На этой позитивной ноте завершаем очередную статью про Эльбрус. Традиционно ждем каверзных вопросов, конструктивных споров и предложений.

Привет Хабр!

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

Интро

На старте проекта нам удалось найти дополнительное финансирование, основным условием была работа ПО полная кроссплатформенность, в том числе поддержка отечественных процессоров. На тот момент наиболее производительным вариантом для десктоп машин был Эльбрус 8С (пока он им и остается, 8СВ еще вроде не вышел). Мы купили две станции Эльбрус 801-РС напрямую от МЦСТ. Сейчас их стоимость указана на сайте, год назад были чуть дороже.

Из курьезных мелочей, с которыми столкнулись при закупке бумажные заявки на поставку. Сразу советую заключить договор NDA, это даст доступ к свежим инструментам разработчика (оформление около месяца). Приехали машины быстро, по комплектации есть проблема с кастомизацией на стороне МЦСТ. Проще докупить и поставить самим нужные видеокарты или периферию. Перечень проверенного оборудования/чипов карт пока есть только в багтрекере МЦСТ, хотя стоило бы опубликовать список на вики ресурсе по Эльбрусам.

Операционные системы

По ситуации на начало 2020го года при заказе можно выбрать предустановленную ОС: оригинальную Эльбрус или партнерскую (Альт, Астра). В нашем проекте используется Астра Linux. Она хоть и была доступна официально, но по факту не получилось заказать за адекватное время. Ставили сами с лайв образа отдельной лицензией.

Выбор той или иной ОС дело вкуса, мне понравилось окружение Fly в Астре, субъективно оно шустрее. С другой стороны, пакетная база Альта шире, они теснее сотрудничают с МЦСТ и набор дистрибутивов интереснее.
Пример не существовал USB лайв образ Астры под Эльбрус, а для Альта их было аж несколько штук. Бэкап раздела Астры работал только из-под лайв образа Альта.

Сама ОС Эльбрус изначально разрабатывалась для демо процессора заказчикам. Мы начинали с версии 4.0, сейчас рабочая 5.0rc2 стало лучше, но все же она сыровата для конечного пользователя. Нужна для отладки или получения максимума от VLIW архитектуры. Именно на этой ОС производительность при обработке изображений была максимальной.

UPD: сейчас вышла версия ОС Эльбрус 6.0. Там заявлены C++20 и свежее ядро Linux, но так как мы работаем на Астра обновления еще не добрались.

Архитектура

Пока только С++, 14-ый стандарт, про CUDA и Vulkan лучше не думать, а вот OpenGL на AMD видеокартах работает нормально. Важно OpenGL не старше 3.1, QT 5.11.
По остальным ЯП возможно кто-то поделится свои опытом в комментариях. Знаю, что идет работа в закрытых конторах, в основном по обработке видеопотока и изображений. Понемногу народ осваивает отечественные процессоры.

Теперь слово архитектору проекта, Максиму Титову (titovmaxim, Unicore Solutions)
Наша цель сделать хороший софт для работы с рентгенографическими системами. Поэтому начали с главного подключения железа и тракта обработки изображений. Сильно волновались. TLDR: все прошло гладко.

Главная часть системы детектор рентгеновского излучения. Подключается по Ethernet и забивает канал 1Гбит под завязку, протокол GigE Vision. Коммерческие библиотеки под Эльбрус отсутствуют, библиотеки с открытым исходным кодом (например Aravis) не подходят по скорости и качеству, так что писали свою реализацию.

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

Предварительная обработка изображений в реальном времени реализована на OpenGL, т.к. это единственное средство, доступное нам на всех платформах. В нее входит применение калибровки и коррекция битых пикселей детектора, обработка гистограммы, гамма коррекция, повышение резкости и подавление шума, раскраска полутонов, геометрические преобразования. Интересно было написать быструю оценку гистограммы изображения на OpenGL, а не CUDA, задача не совсем типичная.
Итого на обработку одного кадра 3000x3000 16 бит на самой слабой видеокарте (AMD R5) на Эльбрусе уходит ~33 мс. Очень даже неплохо, при условии независимости от ОС и полной разгрузки ЦП для задач сложной пост-обработки. Уже доступны более мощные видеокарты, так что здесь мы спокойны. К примеру, на x86 с GeForce RTX 2070 Max-Q мы получаем стабильные ~2мс, ждем подобного на Эльбрус
Подключение прочих компонентов рентгеновских генераторов и мехатроники по RS232, Web камер по UVC, прошло без проблем.

В проекте мы используем Qt 5.11 и QML для интерфейса. Здесь все прошло неожиданно гладко. Работает, заводится "из-коробки", основные пакеты в Астра есть. Ждем, когда будут доступны обновления, поскольку в 5.11 есть шероховатости и баги.
Немного о том, почему мы опасались C++ 14. Активное совместное использование C++ и QML часто вызывает сложности, поэтому мы решили использовать в проекте cвою библиотеку Flow.

Библиотека Flow

Среди плюсов библиотеки декларативность, сокращение boilerplate кода и ошибок. Помогает использовать ФП подход на С++, в частности есть гибкое объединение и композиция функций, ленивость, кеширование, потокобезопасность и фоновое выполнения в других потоках. Последнее, кстати, актуально для OpenGL, который не очень умеет в многопоточность. Все это в динамике с оповещением об изменениях (никаких update) отстыковки/пристыковки веток, действия (эффекты в смысле ФП), интегрированы с контекстами Qt. Из приятного автоматический контроль времени жизни объектов и подписок без ручных subscribe/unsubscribe и беспокойств, кто кого переживёт, все само :) Немного похоже на ReactiveX, но тут больше про состояния, а не про потоки данных.

Там же живет своя мета-система (в C++ рефлексию не завезли), используем вместо QMetaObject. Писать меньше, лучше интегрируется с QML (примерно, как WPF с C#), можно свободно перемещаться по дереву, в частности работать из QML с QVector в середине дерева как с моделью с умным diffом (без написания QAbstractItemModel), автоматическая сериализация/десериализация любого объекта одной командой и пр.
Библиотека изначально была рассчитана минимум на C++ 17. При переходе на C++ 14 мы, естественным образом, потеряли вывод типов и сейчас приходится прописывать большинство шаблонных параметров руками. Однако прогресс МЦСТ впечатляет, ждем новых компиляторов. Была пара особенностей компилятора Эльбрус, не замеченных ранее на GCC и MSVC. Не всегда понимаются auto параметры в лямбдах. Не умеет перезахватывать this во вложенные лямбды. Но это легко правится, в остальном все компилируется и работает без проблем. Да, ошибки компилятора на русском языке немного непривычны
Вследствие особенностей архитектуры на Эльбус не рекомендуется использовать исключения. Поэтому мы сразу отказались от них в нагруженных частях. Однако достаточно широко используем их на верхнем уровне, где операции единичные. Все работает как положено, зря боялись. Да, пока не завезли -fnon-call-exceptions для удобного отлова ошибок уровня системы и их обработки на месте возникновения.
Приятно, что можно большую часть кода писать "дома" на Linux под x86 и потом просто собирать на удаленной машине Эльбруса. При некоторой сноровке проблем с совместимостью кода почти не возникает.

Производительность OpenCV

Наиболее критичные вещи по обработке видеопотока вынесены на видеокарту, для неторопливой пост-обработки изображений используем OpenCV 3.2. Этот пакет портирован на Эльбрус, но есть нюанс производительность сильно зависит от версии пакета для конкретной ОС. См. таблицу по сравнению производительности пакетов OpenCV на Эльбрус 8С (1300 МГц) и Intel core i7 (2600 МГц) под разными ОС/сборками openCV:

Производительность OpenCV на Эльбрусах напрямую завязана на низкоуровневые EML библиотеки (см. руководство по программированию МЦСТ, они оптимизированы под VLIW архитектуру). А пакеты EML зависит уже от дистрибутива ОС. В используемой нами Астре свежая сборка до сих пор не появилась, возможно она есть в Альт Линукс. Кто игрался напишите в комментариях.
Если говорить про рутину свертку изображений, то производительность может быть в 2 раза лучше (16S) по сравнению с i7, а может быть и в 2 раза хуже (32F). На сборке ОС с неоптимизированной библиотекой OpenCV проигрыш в производительности до 20 раз. И да, с 16U у Эльбруса пока все плохо.

Резюме

Жить на Эльбрусе можно. Постепенно МЦСТ и партнеры (Альт, Астра) допиливают ПО, улучшают сервис, снижают цены. Это радует.
С другой стороны их ресурсы ограничены, чего-то нужного именно вам можно ждать полгода.
Возможно правительство станет более активно продвигать отечественные процессоры и стимулировать их коммерческую эксплуатацию, посмотрим. Мы в любом случае к этому готовы.

Сегодняшняя статья будет посвящена сразу двум нашим любимым темам: компьютерной томографии (КТ) и отечественному процессору Эльбрус. Мы расскажем, чем отличается рентгенограмма от результатов КТ и объясним, зачем такой большой и серьезной машине, как томограф, был бы кстати специализированный вычислитель. Несмотря на то, что томографы используются уже почти 50 лет (создание первого томографа было анонсировано в 1972 году [1]), это не означает, что все проблемы KT сегодня решены. Наоборот, существует острая потребность в новых томографических алгоритмах, которые были бы быстрее и точнее используемых, позволили бы уменьшить лучевую нагрузку на объект, что, в свою очередь, существенно расширило бы и сферу применения метода КТ. Понимая все это, мы создали такое программное обеспечение Smart Tomo Engine. О нем речь пойдет ниже. Рассказав ранее о борьбе с ортотропными артефактами и об оценке эффекта чаши, в данной статье мы опишем несколько тестов, проведенных с использованием синтетических и собранных на отечественном томографе реальных томографических датасетах и покажем работу нашей программы на процессоре Эльбрус нового поколения (видео прилагается ниже). Результат работы программы приоткроет внутренний мир майского жука, причем значение слова внутренний здесь следует понимать буквально.

Рентгенография широко используемый метод неинвазивной диагностики, основанный на формировании изображения объекта с помощью рентгеновского излучения. Для этого исследуемый объект помещается между источником рентгеновского излучения и регистратором (рис. 1 слева). В качестве регистратора может выступить рентгеночувствительная пленка или позиционно-чувствительный детектор. Изображение формируется прошедшим через объект и ослабленным при своем прохождении излучением. Разные материалы ослабляют рентгеновское излучение по-разному, что обеспечивает контраст на изображении. Регистрируя прошедшее через объект рентгеновское излучение, можно судить о локальном составе исследуемого объекта. Пример рентгенограммы грудной клетки показан на рис. 1 справа. Здесь светлые области характеризуют участки большего поглощения. Рассматривая ребра (светлые изогнутые пластинки), ограничивающие грудную клетку (темная полость с просматриваемыми светлыми участками бронхиального дерева), в верхней части грудины (центральный светлый столб) с правой стороны мы видим небольшое светлое утолщение.

Рис. 1. Рентгенография: принципиальная схема (слева); результат рентгеновского исследования рентгенограмма (справа). Источник.

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

Рис.2. Источник.

Уточнить форму и внутреннее строение поможет метод КТ. Также как и в рентгенографии, для сбора данных КТ объект помещается между источником рентгеновского излучения и детектором, но регистрируется уже набор рентгенограмм под разными углами. Углы поворота обычно равномерно распределены в некотором интервале. Принципиальная схема измерения показана на рис. 3.

Рис. 3. Принципиальная схема томографической съемки (источник).

Сбор изображений под разными углами проводится на специальном приборе томографе. Поскольку томографироваться могут самые разные объекты живой и неживой природы, а исследования проводятся и на микро-, и макро- уровнях, то разновидностей томографов огромное число. Они отличаются схемами сканирования (послойно-круговая, спиральная и т.д.), используемыми типами источников излучения, схемами формирования зондирующего пучка (конусная, параллельная, микрофокусная). В самых общих чертах схему томографа можно представить так: источник излучения, держатель объекта исследования и детектор. Подвижной частью, позволяющей контролируемо менять ракурс съемки, может быть любая из трех частей. Современный томограф также немыслим без компьютера, который не только управляет схемой сбора рентгенограмм, но производит обработку собранных данных с помощью специализированного ПО.

Для исследования объектов разной природы могут использоваться принципиально отличающиеся друг от друга технические решения. Так, при медицинских исследованиях гентри (подвижное устройство, содержащее систему детекторов и рентгеновских излучателей) (Рис. 4) вращается вокруг неподвижного пациента. Пространственное разрешение в таких томографах достигает 0.2-0.5 мм. Результаты КТ сохраняются в формате DICOM медицинском отраслевом стандарте, разработанном для создания, хранения, передачи цифровых медицинских изображений и сопутствующих документов обследованного пациента.

Рис. 4. Схема медицинского томографа (источник).

Для научных исследований in vitro, проводимых в лабораторных условиях, применяется другая экспериментальная схема источник и детектор неподвижны, а набор рентгенограмм получают, вращая образец. Во ФНИЦ Кристаллография и фотоника РАН (ФНИЦ КФ РАН) в лаборатории рефлектометрии и малоуглового рассеяния был сконструирован и функционирует целый комплекс лабораторных рентгеновских микротомографов. Изображение одного из созданных приборов представлено на рис. 5. В нем образец размещается на гониометре, ось которого перпендикулярна направлению зондирования. Прибор оборудован двумерным детектором. Размер пикселя 9 мкм, поле зрения детектора 24 на 36 мм. В данном приборе реализована возможность использования для зондирования как полихроматического, так и монохроматического излучения. Это позволяет не только повышать качество реконструируемых изображений, но и получать дополнительную информацию об элементном составе изучаемых объектов. Разработка собственных томографов позволяет получить доступ к экспериментальным данным (рентгенограммам) и параметрам работы всех узлов томографа, а, значит, позволяет оптимизировать протоколы измерений в зависимости от поставленных задач.

Рис. 5. Фотография лабораторного микротомографа ФНИЦ КФ РАН.

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

Если зондирование проводится с использованием параллельного пучка, то задачу трехмерной реконструкции можно решить, восстановив серию двумерных сечений объекта. Для реконструкции одного сечения нет необходимости использовать полный набор проекций. Требуется лишь одна строка фиксированного номера от каждой угловой проекции. Все эти строки соответствуют одному горизонтальному сечению восстанавливаемого 3D распределения, которому можно приписать тот же номер. На рис. 6 слева представлено изображение, собранное из таких строк. Горизонтальная ось отвечает за номер столбца детектора, вертикальная за номер углового поворота. Справа на рис. 6 приведен результат реконструкции сечения.

Рис 6. Синограмма грудной клетки (слева); результат КТ сечение 3D изображения (справа).

Если для томографического зондирования используется монохроматическое рентгеновское излучение, то, опираясь на закон Бугера-Ламберта-Бера, задачу реконструкции можно свести к задаче обращения преобразования Радона. Преобразование Радона это интегральное преобразование, которое связывает значения функции со значениями ее интегралов по всевозможным прямым. Процедура обращения это восстановление неизвестной функции по известным значениям ее интегралов по прямым. Подынтегральная функция, которую и надо восстановить это распределение линейного коэффициента ослабления монохроматического рентгеновского излучения в объеме образца. Свойство обратимости преобразования Радона гарантирует точное восстановление неизвестной частотно-ограниченной функции при наличии достаточного числа интегралов по регулярно расположенным прямым. Это свойство использует алгоритм свертки и обратной проекции (Filtered Back Projection, FBP), реализованный в большинстве современных серийных томографов. Он состоит из двух шагов. Первый шаг линейная фильтрация зарегистрированных изображений. Второй шаг обратное проецирование, т.е. равномерное размазывание каждой полученной на предыдущем шаге одномерной функции по соответствующему направлению на все двумерное изображение с последующей суммацией. Результат работы алгоритма восстановленное пространственное распределение линейного коэффициента ослабления рентгеновского излучения заданной энергии. Если зондирование ведется не параллельным, а конусным пучком, то послойную реконструкцию организовать не удается, и приходится использовать более сложные алгоритмы. Об алгоритмах трехмерной реконструкции, например об алгоритме Фельдкампа, мы напишем как-нибудь в следующий раз. А теперь перейдем, наконец, к описанию нашего ПО.

Smart Tomo Engine

Сердцем Smart Tomo Engine служит библиотека томографической реконструкции, предоставляющая через API следующие функции: чтение томографических изображений (проекций); собственно томографическую реконструкцию (предлагается на выбор три алгоритма) и сохранение результатов (предлагаемые форматы: DICOM, PNG). Программный продукт дополнительно включает в себя графический интерфейс пользователя, обеспечивающий двухмерную визуализацию томографических изображений и результатов реконструкции. Основное назначение программного продукта выполнение реконструкции трехмерного цифрового изображения объекта по набору его трансмиссионных томографических изображений в рентгеновском диапазоне.

Для послойной двумерной реконструкции реализованы следующие алгоритмы:

• FBP Filtered Back Projection. Классический метод томографической реконструкции, комбинирующий обратное проецирование и линейную фильтрацию. Вычислительная сложность O(n³). Подробнее о методе можно почитать в [2]).
• DFR Direct Fourier Reconstruction. Алгоритм работает в частотной области и использует быстрое преобразование Фурье для фильтрации и обратного проецирования [3]. Вычислительная сложность O(n² log n) операций умножений.
• HFBP Hough FBP. Алгоритм реконструкции, который разработали наши ученые. Для обратного проецирования используется алгоритм Брейди быстрого вычисления преобразования Хафа, а для ускорения линейной фильтрации применяется метод Дериша [4,5]. Вычислительная сложность по сравнению с DFR снижена до O(n²) операций умножения (при O(n² log n) операций сложения).

Тестирование на Эльбрус

Мы протестировали наше ПО на отечественной платформе. Тестирование проводилось на машинах Эльбрус-401, Эльбрус-804 и Эльбрус-801СВ. Эльбрус-401 это рабочая станция с процессором Эльбрус-4С, Эльбрус-804 сервер с 4 процессорами Эльбрус-8С. (Мы уже тестировали на них наше ПО, разработанное для решения других задач, и почитать про это можно, например, тут.) Эльбрус-801СВ это новейшая разработка МЦСТ: рабочая станция с процессором Эльбрус-8СВ. Про принципиальные отличия Эльбрусов разных поколений нам рассказали коллеги из МЦСТ: Эльбрус-4С первый процессор, массово поставленный на рынок. Имеет 4 ядра с частотой 750800 МГЦ, 3 канала памяти DDR3-1600. Эльбрус-8С 8 ядер, частота 1.21.3 ГГц, 4 канала памяти DDR3-1600, и при этом в каждом ядре в 1.5 раза больше исполнительных устройств (ALU) для вычислений с плавающей запятой. Эльбрус-8СВ дальнейшее улучшение: 8 ядер с частотой 1.5 ГГц, память DDR4-2400 и ещё в 2 раза больше ALU. Эльбрус-8СВ лучше работает с невыровненными данными, и в нём масса других небольших улучшений по сравнению с Эльбрус-8С.

Характеристики процессоров представлены в таблице 1.

Таблица 1. Технические характеристик использованных процессоров.

Про оптимизацию на платформе Эльбрус мы уже писали тут и тут, поэтому не будем повторяться. Здесь мы не делали ничего сверхъестественного:

• использовали оптимизированную библиотеку EML (геометрические преобразования изображения (напр., аффинное преобразование), арифметические операции и т.д.);
• использовали интринсики там, где EML не смогла нам помочь; однако на Эльбрус-8СВ SIMD стал 128-битным, и мы не успели полностью на него перейти, поэтому интринсики все еще работали с 64-битными векторами.

Для тестирования Smart Tomo Engine мы собрали два датасета: с синтетическими и реальными данными. Синтетический датасет Шепп-Логан 3D был получен методом математического моделирования. Проекции рассчитаны послойно от трехмерного фантома Шеппа-Логана с использованием веерной схемы. Срез представлен на рис. 8 слева. Размер изображения фантома 511х511х511. Проекции рассчитаны для 420 углов, равномерно распределенных от 0.5 до 210 градусов. В эксперименте на вход Smart Tomo Engine подавалось 511 синограмм (изображение одной из них приведено на рис. 7 справа) размером 511х420. Выход 511 реконструированных слоев, размер каждого слоя 511х511. Размер фантома примерно соответствует изображениям, получаемым на современных стоматологических томографах: максимальный размер зоны сканирования челюсти обычно составляет 16 см, заявляемое производителями пространственное разрешение 0.3-0.4 мм. В таком случае размер регистрируемой проекции составит примерно 500х500 пикселей.

Рис. 7. Слева срез трехмерного фантома Шеппа-Логана, справа синограмма центрального слоя.

Реальные томографические данные (датасет "Майский жук") были собраны на микротомографе ФНИЦ КФ РАН, предназначенном для проведения научных исследований. Размер пикселя использованного детектора составлял 9 микрон. Экспериментальный образец высушенный майский жук. Было снято 400 проекций в параллельной схеме. Образец, закрепленный на держателе, поворачивался на углы в диапазоне от 0.5 до 200 градусов с шагом 0.5 градусов. Время измерения одной проекции составило 5 секунд. Размер измеренной проекции 1261х1175. Вход для Smart Tomo Engine 1261 синограмма размером 1175х400, выход 1261 восстановленный слой размера 1175х1175.

А теперь самое интересное результаты замеров и выводы

На этих датасетах мы провели замеры скорости выполнения реализованных нами алгоритмов реконструкции: FBP, DFR и HFBP. Время работы алгоритмов приведено в таблице 2. Замеры проводились на 5 машинах: Эльбрусе-401, Эльбрусе-804, Эльбрусе-801СВ, AMD Ryzen 7 2700 и AMD Ryzen Threadripper 3970X. Для каждой машины в таблице указано число процессоров, число физических ядер и максимальное число одновременно выполняемых потоков (указано в скобках). Замеры скорости реконструкции проводились в двух режимах: однопоточном (1П) и многопоточном (МП), реализованном с помощью библиотеки tbb версии 2017 update 7.

Таблица 2. Замеры времени работы программы, сек.

Анализируя полученные результаты, прежде всего отметим, что в многопоточном режиме 4-процессорный сервер Эльбрус-804 затратил на реконструкцию 511 слоев фантома алгоритмом HFBP 19 секунд, то есть каждый слой был восстановлен за 0.037 секунды, а послойная частота составила 26.8 слоев в секунду (26.8 ips). Чтобы понять, высокая это частота или низкая, приведем следующую оценку. За секунду гентри 16-срезового кардиологического томографа совершает чуть меньше двух оборотов, регистрируя порядка 30 синограмм. Мы восстанавливаем 26.8 слоя в секунду, т.е. проводим реконструкцию практически в режиме реального времени. Таким образом, проведение реконструкции с использованием российской платформы удовлетворяет требованиям по скорости, предъявляемым в кардиологии, где основным реперным параметром является период сокращения сердца, который в среднем составляет одну секунду.

Реконструкция в реальном времени требуется также для реализации нового протокола сканирования, предложенного недавно нашими учеными контролируемой реконструкции [6]. Использование этого протокола уменьшает лучевую нагрузку за счет того, что сбор рентгенограмм прерывается сразу, как только их набор оказывается достаточным для восстановления.

Для научных исследований таких жестких ограничений по времени нет, но выше требования к пространственному разрешению. Поэтому размеры восстанавливаемых сечений больше. При работе с датасетом, полученным с лабораторного микротомографа, на реконструкцию 1261 слоя потребовалось 189 секунды в многопоточном режиме (6.7 ips). Измерение входных данных на лабораторном томографе заняло 2000 секунд, а 3 с небольшим минуты, которые потребовались на реконструкцию всех слоев при использовании Smart Tomo Engine на Эльбрусе-804, соответствуют 10% этого времени. Ещё быстрее будет работать 4-процессорный сервер с процессором Эльбрус-8СВ, который в МЦСТ уже разработали и скоро планируют довести до готовности к серийному производству.

В полученных результатах интересны и сами по себе соотношения производительностей разных платформ на каждом из алгоритмов, с учётом тактовой частоты ядер. На FBP отставание Эльбрусов умеренное, и при нормировании относительно тактовой частоты получаются близкие результаты. Но на алгоритмах DFR и HFBP отставание всех Эльбрусов от платформы х86 значительно больше. Почему? Ответ кроется в недостаточной оптимизации нашего ПО под платформу Эльбрус, все же на x86_64 мы потратили 5 лет, а под Эльбрус, особенно под 8СВ, большую часть программ и алгоритмов мы еще вовсе не оптимизировали.

В ближайшее время мы планируем ускорения в трех направлениях. Первое, что мы сделаем, это оптимизируем наши вычисления на интринсиках. Сейчас наши вычисления сделаны для 64-битного SIMD, а у Эльбрус-8СВ SIMD стал 128-битным. Второе ускорение будет сделано командой МЦСТ. Уже сейчас ведутся разработки для поддержки двумерного и одномерного дискретного преобразования Фурье для входного вектора, размер которого не равен степени двойки. И так как пока его нет, мы пользовались библиотекой ffts, с некоторой доработкой как под Эльбрус, так и под х86.

Для оценки возможного ускорения нашей программы мы сделали замеры времени выполнения дискретного преобразования Фурье на процессоре Эльбрус-8СВ для входной комплексной матрицы размером 512 на 512. Неоптимизированная на Эльбрус библиотека ffts выполнила эту операцию за 27 миллисекунд, а eml справилась всего за 5.5. Мы ускорили, как могли, ffts с помощью вызовов EML в 2 раза, и в таблице 2 замеры проведены уже с учётом этой оптимизации. Таким образом, если оптимизацию проводить с той тщательностью, с которой сделана библиотека eml, то алгоритм DFR на Эльбрусе все еще может быть ускорен почти в 2,5 раза.

Третье, но не менее важное ускорение относится к алгоритму HFBP, который основан на применении преобразования Хафа. Данное преобразование также пока еще не представлено в библиотеке eml, а наша версия оптимизирована только с помощью векторных операций. И, так как данный алгоритм вычислительно эффективнее, чем DFR, наши теоретические выводы и оптимизированная под платформу x86_64 версия это показывают, то данный алгоритм тоже может быть ускорен еще в несколько раз. О результатах этих оптимизаций мы обязательно расскажем в следующий раз.

А вот и обещанное видео с работой программы на Эльбрус-8СВ.

Вот такой внутренний мир майского жука у нас получился.

Заключение

В статье мы представили вам нашу новую разработку программное обеспечение для томографической реконструкции Smart Tomo Engine, которое:

• включает в себя инновационный алгоритм HFBP, стабильно обгоняющий по производительности лидера прошлых лет DFR;
• поддерживает операционные системы: ОС Эльбрус, MS Windows, macOS, различные дистрибутивы Linux;
• поддерживает процессорные архитектуры: Эльбрус, x86, x86_64;
• является полностью отечественной разработкой;
• в составе программно-аппаратного комплекса на платформе Эльбрус подходит для медицинских и промышленных сканеров всех поколений, для новейших нано-томографов (приборов, которые реконструируют объекты с субмикронным разрешением), а также синхротронных центров.

Ну а главный результат этой статьи заключается в том, что комбинации отечественного процессора Эльбрус и Smart Tomo Engine достаточно для томографии в реальном времени, даже без дополнительных ускорений, работа над которыми уже ведется!

P.S. А еще мы не смогли удержаться и замерили производительность UNetа на Эльбрусе. UNet популярная нейросетевая архитектура для решения задач сегментации. Изначально Unet была разработана для решения задачи сегментации в медицине, а по обработанным этим нейросетевым подходом томографическим снимкам теперь определяют патологии и новообразования. Вычислительно тяжелые части нейронных сетей у нас реализованы на EML, а EML оптимизировано под разные поколения Эльбрусов, поэтому на таком замере можно лучше оценить реальную производительность разных процессоров. Замеры выполнены для одного ядра, без распараллеливания, чтобы не оглядываться на число ядер.

Обратите внимание на последние две цифры. Круто?.. А наши исследования продолжаются...

• Процессор Эльбрус.
• Южный мост.
• Печатные платы.
• Материнская плата.
• Световоды.
• Корпус и металлические детали корпуса.
• Пластиковые детали и ряд элементов конструкции.