"Обычно хакер пишет программы не ради выгоды,
а ради собственного удовольствия. Такая программа
может оказаться полезной, а может остаться
всего лишь игрой интеллекта."
Генри С. Уоррен. Алгоритмические трюки для программистов [1]
Сегодня мы продолжим наши заметки об Эльбрусе. Первую статью, посвященную запуску и оптимизации системы распознавания паспорта, можно прочитать тут.
Однажды мы с коллегами заинтересовались, как самые простые методы оптимизации работают на Эльбрусе.
Процессор Эльбрус имеет VLIW (Very Long Instruction Word) архитектуру — то есть оперирует “широкими” командными словами. Это означает, что компилятор lcc анализирует исходный код программы при компиляции, определяет зависимости между командами и формирует широкие командные слова. В одном таком слове можно уместить до 23 действий, которые будут исполняться одновременно. Если использовать SIMD (Single Instruction Multiple Data), то это число может возрасти до 33 и более операций. Команды в широком слове исполняются параллельно, обеспечивая загрузку всех 6 арифметико-логических устройств на каждом процессоре. Распараллеливание и загрузка всех вычислителей целиком ложится на плечи оптимизирующего компилятора, что позволяет значительно упростить аппаратуру для анализа и исполнения команд и снизить энергопотребление до 45 Вт для Эльбрус-4С [2, 3].
Мы в Smart Engines задались вопросом, как будут работать все привычные оптимизации, такие как, например, развертывание циклов, на столь непривычной платформе с “умным” компилятором.
Мы рассмотрели простые примеры на С++ и сравнили результаты работы на Эльбрус-4С и Intel Core i7-6700K. На Эльбрусе использовался компилятор lcc версии 1.20.17, для Core i7 — Microsoft Visual Studio Community 2015. Для lcc мы использовали флаги компиляции -O3 и -ffast-math.
Для начала, приведем характеристики Эльбрус-4С и Intel Core i7-6700K:
| Эльбрус-4С | Intel Core i7-6700K | |
|---|---|---|
| Архитектура | Эльбрус | Skylake-S |
| Частота, GHz | 0.8 | 4 |
| Число ядер | 4 | 4 (8 c Hyper-Threading) |
| Технологический процесс | 65 nm | 14 nm |
| Cache L1 size, data | 64 Kb | 32 Kb |
| Cache L1 size, instructions | 128 Kb | 32 Kb |
| Cache L2 size | 8 Mb | 1 Mb |
| Cache L3 size | - | 8 Mb |
| Тип оперативной памяти | DDR3-1600 | DDR4-2133 |
| Потребляемая мощность, Вт | 45 | 91 |
Тактовая частота этих процессоров значительно отличается: 800 МГц у Эльбрус-4С и 4 ГГц у Intel Core i7. Также заметим, что Эльбрус имеет другую структуру кэш-памяти: отсутствует L3 кэш, однако размер L2 кэша составляет 8 Mb (по 2 Mb на ядро), в то время как у рассмотренного Core i7 1 Mb (по 0.25 Mb на ядро). L1 кэш на Эльбрусе также больше, особенно кэш инструкций (128 Kb против 32 Kb).
Пример 1. Развертывание циклов
Эта оптимизация направлена на уменьшение числа итераций цикла (а значит и уменьшение количества проверок условия выхода из цикла) путем увеличения тела цикла. Такая оптимизация хорошо подходит для простых циклов, которые встречаются практически в каждой программе.
Теперь рассмотрим пример:
#define N 64000
unsigned int x = 0;
unsigned int a[N];
for (int i = 0; i < N; ++i)
a[i] = i;
//Оптимизируемый цикл
for (int k = 0; k < N;)
{
x += a[k];
a[k++] = k;
}Последний цикл мы и попробовали развернуть. Результаты замеров времени (для 10000 итераций цикла) приведены в таблице 1. Стоит отметить, что на Эльбрусе использовался 32-битный режим адресации (флаг компилятора -mptr32). Мы также рассчитали время работы на 1 ГГц путем умножения измеренного времени на тактовую частоту процессора в ГГц. Полученная таким образом безразмерная величина позволяет сравнить производительность Эльбрус и Core i7 с учетом различия в тактовой частоте.
Таблица 1. Время работы в зависимости от N — числа развернутых итераций.
| Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|
| N | Время, мс | Время в пересчете на 1 ГГц | Время, мс | Время в пересчете на 1 ГГц |
| 1 | 401 | 320 | 255 | 1020 |
| 2 | 400 | 320 | 275 | 1100 |
| 4 | 401 | 320 | 261 | 1044 |
| 8 | 401 | 320 | 247 | 988 |
| 16 | 401 | 320 | 361 | 1444 |
| 32 | 452 | 362 | 262 | 1048 |
| 64 | 451 | 362 | 262 | 1048 |
Можно видеть, что развертывание цикла в данном примере не дает выигрыша во времени работы как на современном Core i7, так и на Эльбрус-4С. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает эффективнее Core i7 с учетом отношения частот.
Пример 2. Обработка данных различной длины
В этом примере мы обрабатываем массив по 1, 4 или 8 байтам. Исходный массив а был выровнен на 8 байт.
#define MASK1 0xF1
#define MASK4 0xF1F2F3F4
#define MASK8 0xF1F2F3F4F5F6F7F8
for (k = 0; k < n; ++k)
{
а[k] &= MASK1;
}Результаты замеров времени приведены в таблице 2.
Таблица 2. Время работы в зависимости от N — числа обрабатываемых байт.
| Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|
| N | Время, мс | Время в пересчете на 1 ГГц | Время, мс | Время в пересчете на 1 ГГц |
| 1 | 2400 | 1920 | 811 | 3244 |
| 4 | 600 | 480 | 201 | 804 |
| 8 | 300 | 240 | 102 | 408 |
Можно видеть, что обработка по 4 и 8 байт работает быстрее как на современном Core i7, так и на Эльбрус-4С, причем времена уменьшаются кратно числу обрабатываемых байт. Кроме того, Эльбрус работает эффективнее Core i7 с учетом отношения частот.
Пример 3. Использование SIMD
В этом примере мы решили протестировать интринсики и рассмотрели вычисление скалярного произведения чисел типа float при n = 12800.
Неоптимизированный цикл:
float result = 0.0;
for (int i = 0; i < n; ++i)
{
result += x[i] * y[i];
}С использованием SSE:
float *pX = x;
float *pY = y;
__m128 Sum = _mm_setzero_ps();
int num = n / 4;
for (int i = 0; i < num; ++i, pX += 4, pY += 4)
{
Sum = _mm_add_ps(Sum, _mm_mul_ps(_mm_load_ps(pX), _mm_load_ps(pY)));
}
float result = _mm_extract_ps(Sum, 0) + _mm_extract_ps(Sum, 1) + _mm_extract_ps(Sum, 2) + _mm_extract_ps(Sum, 3);С использованием EML [4] (оптимизированная библиотека под Эльбрус):
double result;
eml_Vector_DotProd_32F(x, y, n, &result);Результаты замеров времени приведены в таблице 3. Размер SIMD-регистра на Эльбрус-4С составляет 64 бита (instruction set версии 3), что в общем-то соответствует наблюдаемому ускорению в 2 раза между версией без оптимизаций и версией с SIMD. На Core i7 все тоже довольно правдоподобно, мы оперировали 128-битными регистрами, в которые помещается 4 числа типа float. Кроме того, заметно, что Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.
Таблица 3. Время работы подсчета скалярного произведения.
| Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|
| Время, мс | Время в пересчете на 1 ГГц | Время, мс | Время в пересчете на 1 ГГц | |
| Без оптимизации | 263 | 210 | 99 | 396 |
| С SIMD | 110 | 88 | 24 | 96 |
Пример 4. Подсчет расстояния Хэмминга между двумя массивами
Здесь мы вычисляли расстояние Хэмминга между двоичным представлением двух массивов, т.е. взяли расстояния Хэмминга между двоичными представлениями соответствующих чисел в массивах и нашли их сумму. Для массивов с 8-битными данными мы использовали побитовое ИСКЛЮЧАЮЩЕЕ ИЛИ и предподсчитанную таблицу расстояний:
int result = 0;
for (int i = 0; i < n; ++i)
{
result += popcnt_table[x[i] ^ y[i]];
}Для 32- и 64-битных данных мы использовали побитовое логическое ИСКЛЮЧАЮЩЕЕ ИЛИ и интринсики _mm_popcnt_u32, _mm_popcnt_u64 на Intel и интринсики __builtin_e2k_popcnts, __builtin_e2k_popcntd на Эльбрусе. Общая длина массивов x и y в байтах оставалась неизменной и равной n = 512. Результаты замеров времени приведены в таблице 4.
Таблица 4. Время подсчета расстояния Хэмминга в зависимости от числа обрабатываемых байт N.
| Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|
| N | Время, мс | Время в пересчете на 1 ГГц | Время, мс | Время в пересчете на 1 ГГц |
| 1 | 630 | 504 | 155 | 620 |
| 4 | 110 | 88 | 47 | 188 |
| 8 | 76 | 61 | 15 | 60 |
В этом примере мы видим, что интринсики для подсчета числа единиц в 64-битном и 32-битном регистрах и на Эльбрусе, и на Core i7 дают значительное ускорение относительно версии с предподсчитанной таблицей. Кроме того, 32-битная команда popcnt на Эльбрусе работает быстрее, чем на Core i7 с учетом отношения частот. А вот в 64-битной случае времена работы на Core i7 и Эльбрусе сравнялись.
Пример 5. Устранение зависимости по данным
Данный пример позаимствован из книги Криса Касперски “Техника оптимизации программ. Эффективное использование памяти” [5]. Он демонстрирует, как устранение зависимости по данным помогает повысить производительность. Массив a заполнен нулями, n = 2097152.
Пример с зависимостью по данным:
int x = 0;
for (size_t a = 0; a < BLOCK_SIZE; a += 8 * sizeof(int))
{
x = *(int *)((char *)p1 + a + 0 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 1 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 2 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 3 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 4 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 5 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 6 * sizeof(int));
a += x;
x = *(int *)((char *)p1 + a + 7 * sizeof(int));
a += x;
}Каждый следующий индекс элемента зависит от значения, вычисленного предыдущей командой, поэтому загрузка элементов из памяти происходит последовательно, после завершения выполнения предыдущей инструкции.
Теперь код без зависимости:
int x = 0;
for (size_t a = 0; a < BLOCK_SIZE; a += 8 * sizeof(int))
{
x += *(int *)((char *)p2 + a + 0 * sizeof(int));
x += *(int *)((char *)p2 + a + 1 * sizeof(int));
x += *(int *)((char *)p2 + a + 2 * sizeof(int));
x += *(int *)((char *)p2 + a + 3 * sizeof(int));
x += *(int *)((char *)p2 + a + 4 * sizeof(int));
x += *(int *)((char *)p2 + a + 5 * sizeof(int));
x += *(int *)((char *)p2 + a + 6 * sizeof(int));
x += *(int *)((char *)p2 + a + 7 * sizeof(int));
}Результаты замеров времени приведены в таблице 5. Устранение зависимости по данным работает как на Эльбрусе, так и на Core i7, причем на Core i7 время работы различается примерно в 11 раз, а на Эльбрусе — практически в 20! Код с зависимостью по данным отработал на Эльбрусе медленнее, чем на Core i7 в пересчете на 1 ГГц, а вот без зависимости Эльбрус всего в 4 раза медленнее Core i7 (при различии частот в 5 раз). Такие результаты на Эльбрусе можно объяснить наличием механизма асинхронной подкачки массивов (array prefetch buffer), которая работает эффективно, если подкачиваемые элементы располагаются последовательно.
Таблица 5. Время чтения зависимых и независимых данных.
| Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|
| Время, мс | Время в пересчете на 1 ГГц | Время, мс | Время в пересчете на 1 ГГц | |
| Зависимые данные | 605 | 484 | 87 | 348 |
| Независимые данные | 32 | 26 | 8 | 32 |
Пример 6. Многопоточные вычисления
Разумеется, мы не могли не рассмотреть такой метод оптимизации, как распараллеливание. Для чистоты эксперимента мы взяли полностью независимые задачи (вычисление скалярного произведения двух массивов типа double). В таблице 6 приведено время последовательной работы N задач (Tпосл), время работы N задач в N потоков (Tпар) и ускорение E:
Таблица 6. Время последовательного и параллельного вычисления скалярного произведения в зависимости от числа задач и потоков N.
| Эльбрус-4С | Эльбрус-4С | Эльбрус-4С | Intel Core i7 | Intel Core i7 | Intel Core i7 | |
|---|---|---|---|---|---|---|
| N | Tпосл, мс | Tпар, мс | E=Tпосл/Tпар | Tпосл, мс | Tпар, мс | E=Tпосл/Tпар |
| 2 | 2628 | 1316 | 2.00 | 1033 | 500 | 2.07 |
| 4 | 5259 | 1318 | 3.99 | 1994 | 500 | 3.99 |
| 8 | 10513 | 2634 | 3.99 | 3987 | 503 | 7.93 |
| 16 | 21045 | 5268 | 4.00 | 7980 | 1009 | 7.91 |
| 20 | 26321 | 6583 | 4.00 | 9967 | 1263 | 7.89 |
| 32 | 42053 | 10535 | 3.99 | 15948 | 2014 | 7.92 |
| 40 | 52566 | 13170 | 3.99 | 19936 | 2528 | 7.89 |
Видно, что на Core i7 ускорение практически в 8 раз достигается на 8 потоках и дальше варьируется незначительно. На Эльбрусе ускорение в 4 раза достигается на 4 потоках и также с увеличением числа потоков не меняется. Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.
Выводы
Привычные методы ускорения вычислений вполне работают на Эльбрусе и в этом плане программирование для него не требует специфических знаний и умений. В рассмотренных элементарных примерах для оптимизации кода Эльбрус показал себя просто замечательно с учетом тактовой частоты в 800 МГц и в два раза меньшей потребляемой мощности по сравнению с Core i7.
P.S. А еще мы запустили нашу систему распознавания паспорта на SPARC! Это означает, что теперь мы сможем писать статьи о распознавании на еще одной вычислительной архитектуре.
Update. В результаты примера 1 вкралась ошибка, благодаря комментариям VLev мы ее обнаружили и исправили. Результаты обновлены.
Использованные источники
[1] Генри С. Уоррен, мл. Алгоритмические трюки для программистов. М.: Издательский дом "Вильямс", 2014. ISBN 978-5-8459-1838-3 – 512 С.
[2] http://www.elbrus.ru/arhitektura_elbrus.
[3] http://www.mcst.ru/mikroprocessor-elbrus4s.
[4] http://www.mcst.ru/vysokoproizvoditelnye_biblioteki.
[5] Крис Касперски. “Технологии оптимизации программ. Эффективное использование памяти”. Спб.: БХВ-Петербург, 2003. ISBN 5-94157-232-8 – 464 С.
Комментарии (78)
zapimir
15.12.2016 11:41+3А Вы учитываете, что у современных Intel частота сильно плавающая? К примеру у меня на i5-6600K она при небольшой нагрузке опускается до 800 МГц, в то время как при нагрузке включается еще и TurboBoost.
и в два раза меньшей потребляемой мощности по сравнению с Core i7
Это распространенное заблуждение, TDP у Intel очень часто далёк от реального потребления. К примеру, у того же i5-6600K тоже TDP 91 Вт, получается они одинаково «едят»? Так что сравнивать по TDP бессмысленно. Тем более, что TDP для Intel учитывает ещё и встроенную видяху, чего у Эльбруса нет. Вы бы ради интереса взяли померили потребление от розетки для системыSmartEngines
15.12.2016 15:53Действительно, энергопотребление мы сравнивали только по TDP, что не совсем корректно, и было бы интересно измерить реальную потребляемую мощность. Возможно мы проведем и такой эксперимент. TurboBoost при замерах мы отключили.
kosmos89
15.12.2016 22:12+1TDP для Intel учитывает ещё и встроенную видяху
Он вообще не понятно что учитывает, потому что мой 4790K по паспорту имеет TDP 88 Вт, а по факту в FPU stress test потребляет 120 Вт. И это без учета встроенного видео.
Grox
16.12.2016 02:06+1Из вики: Требования по теплоотводу (TDP) показывают не максимальное теоретическое тепловыделение процессора, а лишь требования к производительности системы охлаждения.
FPU stress test это не типичная нагрузка для процессора, поэтому давно не указывают максимальное потребление процессора. Он его почти никогда не достигает, кроме как в таких тестах, в которых нет ожидания памяти и вся работа только через кэш или даже просто регистры, т.е. никаких простоев, максимум нагрузки.
RainM
15.12.2016 13:51+6Есть же штатные тулы для сравниения быстродействия — SPEC 2000/2006 CPU, зачем изобретать синтетические велосипеды?
+ Все примеры на счетные циклы, что явно не слишком репрезентативно.
+ Среди примеров нет ни одного с ветвлениями внутри цикла.
P.S. Всегда умиляла любовь поклонников Эльбруса нормировать показатели на частоту.SmartEngines
15.12.2016 14:21Цель данного поста не сравнить производительность Эльбрус и Core i7, для этого наши примеры не очень подходят. Мы хотели показать, что несмотря на VLIW-архитектуру Эльбруса и написанный специально для нее оптимизирующий компилятор, простые методы оптимизации на нем работают также, как и на Core i7, и в этом смысле разработка программ для Эльбруса не требует дополнительных затрат на специфичную оптимизацию.
lgorSL
15.12.2016 15:45+12Цель данного поста не сравнить производительность Эльбрус и Core i7
Ага, и в каждом примере шаблонные строчки
Пример 1. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.
Пример 2. Кроме того, Эльбрус работает эффективнее Core i7 с учетом отношения частот.
Пример 3. Кроме того, заметно, что Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.
Пример 4.Кроме того, 32-битная команда popcnt на Эльбрусе работает быстрее, чем на Core i7 с учетом отношения частот. А вот в 64-битной случае времена работы на Core i7 и Эльбрусе сравнялись.
Пример 5 Код с зависимостью по данным отработал на Эльбрусе медленнее, чем на Core i7 в пересчете на 1 ГГц, а вот без зависимости Эльбрус всего в 4 раза медленнее Core i7 (при различии частот в 5 раз).
Пример 6 Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.Кстати, тут неправда. Вы подменяете сравнение производительности процессоров сравнением мощности ядер, но у i7 8 виртуальных ядер и при большом количестве потоков он работает в 2.6*2 = 5.2 раз быстрее. (например, в параллельном варианте для n=32 у вас время больше 10 сек для Эльбруса и всего лишь 2 сек для i7)
рассмотренных элементарных примерах для оптимизации кода Эльбрус показал себя просто замечательно с учетом тактовой частоты в 800 МГц и в два раза меньшей потребляемой мощности по сравнению с Core i7
Вы всю статью хвалите Эльбрус и во все таблицы пихаете отнормированные на частоту числа, вы бы ещё на "подгоночный коэффициент" их домножали, оно быть хоть честнее было.
Если бы целью было сравнение эффектов от оптимизаций, можно было бы неоптимизированный вариант брать за эталон и с ним уже сравнивать: "вот, такие-то действия ускоряют программу в 9 раз на i7 и в 20 раз на Эльбрусе".
RainM
15.12.2016 16:11В том то и вопрос, что данные тесты изначально достаточно неплохо ложатся на VLIW. Если говорить про SPEC, то там есть примеры другого класса, например gcc или perl, где поток управления превалирует над числодробительными цикловыми вычислениями.
SmartEngines
15.12.2016 17:51По Эльбрус-4С уже опубликовано немало обзоров с результатами более или менее стандартных тестов производительности, 7-zip сжатие/распаковка, например. Для Эльбрус-2С+ есть результаты на SPEC 2000 на сайте МЦСТ. Поскольку мы занимаемся обработкой изображений и распознаванием, нам интереснее рассматривать профильные для нас задачи, которые довольно просто распараллеливаются и хорошо подходят для VLIW-архитектур.
eldarmusin
19.12.2016 13:31+3А что скажет конечный пользователь системы?
Ничего страшного что я подождал результата в 2,6-10 раз дольше на Эльбрусе, чем на iCore, ведь в переводе на частоту, Эльбрус всё равно быстрее?
Вполне возможно что для оцифровки литерратуры советского периода в фоновом режиме Эльбрус покажет себя замечательно. Ведь возможно энерго-эффективнее справится с задачей.
Но если говорить о рамках пограничного контроля в аэропортах с большим потоком — то уж лучше iCore. Любой простой и любая задержка стоят денег.
Брюссель
Осло
easyman
15.12.2016 14:17Надо сравнивать деньги и время, необходимые для расчета одной и той же задачи.
Мне из статьи не стало понятнее, существуют ли задачи, в которыхсовокупнаястоимость владения…
Электричество = деньги.
Железо = деньги.
Время = деньги.
stalkerg
15.12.2016 14:36+1Я всё жду того когда они откроют свои форки gcc и glibc как того требует лицензия. Тогда и будет понятнее про оптимизации и прочее.
DmitryBabokin
15.12.2016 16:03А кто говорил про gcc на Эльбрусе? У них свой компилятор.
crea7or
15.12.2016 16:09Так только слухи и есть. Как раз пишут что у них форк gcc. Хотя сейчас уже логичнее llvm пилить во всю.
anger32
15.12.2016 19:57У них свой компилятор, именуют они его не иначе как lcc. Фронтенд у него с gcc по большей части совместим, бэкенд свой. По glibc же напишите им запрос соответствующий, будет интересно узнать что напишут в ответ.
stalkerg
16.12.2016 13:02+2lcc и есть форк gcc даже если не полностью то куски от туда они взяли… GPL лицензия требует открытие всего проекта если вы хоть что то взяли от GPL.
Про glibc, gcc они уже отвечали что "мы типо пилим для военных и мы чихали на ваш GPL".
Кроме того они правили Mesa, DRM и т.д. то же без фидбека сообществу. Короче пока они будут красть чужой труд я однозначно против их конторы. (пару раз был у них в гостях к слову пока учился в универе)
vanxant
15.12.2016 22:32По слухам, ллвм они пилят, но пока все в очень ранней стадии
crea7or
15.12.2016 22:41+3Им надо всё открывать и выпускать(думаю не без гос.поддержки) что-то вроде Raspberry Pi с минимальным процессором, ну и не дорого распродать. Тогда в стране появятся люди знакомые с архитектурой. И дело с инструментарием пойдёт и развитие побыстрее. Наверно. Иначе это всё так и останется в печальном состоянии, а жаль.Свой процессор это здорово, я бы и сам поковырялся.
homm
15.12.2016 14:47Замечание по таблице. Сейчас данные располагаются так:
Эльбрус абс | Эльбрус/ГГц | Intel абс | Intel/ГГц
Но ведь сравнение идет между Эльбрусом и Intel, а не между Эльбрус абс и Эльбрус/ГГц. Последнее всегда дает отношение 0.8, зачем держать эти колонки вместе. Правильный порядок:
Эльбрус абс | Intel абс | Эльбрус/ГГц | Intel/ГГц
Что касается перерасчета на ГГц. А зачем это вообще? Ну так, забавный факт, который не имеет реального применения. У вас есть задача, есть ресурсы: кол-во процессоров/денег на процессоры либо киловатты энергии. Т.е. имеет смысл знать реальное время и перерасчет на стоимость или потребление. Но перерасчет на какие-то внутренние технические характеристики ничего полезного не дает.VaalKIA
15.12.2016 23:45Хотел бы заметить, что метрика на МГц или ГГц более правильная чем просто метрика производительности для процессоров изготовленных по разным топонормам, ведь очевидно, что переход на новую топонорму сделает процессор более производительным, поэтому на МГц это более точная метрика, но она всё равно очень долека от правды. К примеру, такой комментарий в аналогичной статье: https://habrahabr.ru/post/307512/#comment_9748816
Народу, безусловно, интересен потенциал архитектуры, а не конкретно этот камень, поэтому было бы логичным сравнить с топовым процессором от Intel на архитектуре 65нм, предлагаю два варианта:
Intel Pentium EE 955 3,46 ГГц. Presler
Intel Core 2 Quad Q6700 2,67 ГГц Kentsfield
оба 65нм второй вышел позже и как раз харктеризуется тем что метрика на ГГц тут будет не корректна, потому что производиельность у него должна быть не ниже. Вот хотелось бы узнать сравнение именно с этими процессорами. А так же ключевой вопрос (к эльбрусовцам): когда Эльбрус-8С выйдет, который до конца 2015г. «сделан»?
http://mcst.ru/vosmiyadernyj-mikroprocessor-s-arkhitekturoj-elbrus
crea7or
15.12.2016 16:06+2Ну серьёзно, полное игнорирование тестов SPEC наводит на плохие мысли. Когда уже сделаете?
И раз уж тут про оптимизацию, где купить попробовать и где взять компилятор? У МЦСТ всё ведь закрыто. Зачем статья если её вообще не к чему применить? Интереснейший проект и всё закрыто.
Тем кто понимает про архитектуры процессов и так всё это знают — дайте тесты! В конце концов Intel Itanium тот же VLIW. А для него куча всего доступно.http2
15.12.2016 23:03Itanium не умер? :)
crea7or
15.12.2016 23:21Чего вдруг.
http2
16.12.2016 00:08А, это видимо я слышал звон об:
Windows XP 64-bit Edition — это издание разрабатывалось специально для рабочих станций с архитектурой IA-64 и микропроцессорами Itanium. Это издание Windows XP более не развивается с 2005 года, после того, как HP прекратил разработку рабочих станций с микропроцессорами Itanium.
:)
RoseWoodsAlloy
15.12.2016 19:56А можно расскладку производительность на ватт? А то в пересчетах на гигагерцы 65 нанометров выглядит, наверное — не плохо…
DustCn
15.12.2016 20:32+61. Нормировка к частоте это пустой звук, т.к. Эльбрус именно из за своей архитектуры никогда не достигнет частоты i7.
2. SSE для i7? Серьезно? А теперь давайте возьмем AVX2+FMA.
3. Где результат для сравнения EML vs MKL?
4. Где результат для double операций?
http2
15.12.2016 22:35на Эльбрусе использовался 32-битный режим адресации
иМожно видеть, что обработка по 8 байт работает быстрее на Эльбрус-4С
То есть в 32 разрядной ОС Эльбрус сможет работать с 64 байтными числами нативно? :)
Интелы (x86) вроде так не умеют. :)SmartEngines
17.12.2016 12:04ОС Эльбрус 64-разрядная, однако можно принудительно включить для приложения 32-разрядную адресацию с помощью флага компилятора -mptr32. Обработка по 8 байт работает быстро в дефолтном, 64-разрядном режиме.
http2
15.12.2016 22:42Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.
В вебе (nginx | php7 | mysql 5.7) используется simd-арифметика или обычная? :)
Вроде больше текст (обычная целочисленная?).
Было бы выгодно их использовать в веб-серверах. :)
Какая максимальная частота Эльбруса? :)
Какие цены по сравнению с примерно равным по производительности Интелом? :)
Есть поддержка последних линуксов? :)http2
15.12.2016 23:10С сайта Эльбруса:
Качество эмуляции архитектуры х86 подтверждается успешным запуском на платформе Эльбрус более 20 операционных систем (в том числе несколько версий Windows) и сотен приложений.
А есть ли нативная поддержка? :)
И какой оверхед эмуляции? :)
Стоит отдельно отметить, что в настоящее время вирусов для платформы «Эльбрус» просто не существует.
И даже в режиме эмуляции? :)http2
16.12.2016 00:41Накладные расходы эмуляции видимо незначительные, так как 300 МГц проц сделал 500 МГц Pentium M. :)
С вики о планах на будущее в 2009 (2013?) году (офф сайт):
«Эльбрус-8С» — 250 ГФлопс, 28 нм к 2015 г. — восьмиядерный микропроцессор с архитектурой Эльбрус.
Вышла чуток задержка, на оф. сайте его еще нет. :)
heleo
16.12.2016 12:03С их осью доводилось недавно сталкиваться.
Их железо раздобыть не так просто, правда у них есть виртуалки с возможностью компиляции исходников под платформу эльбруса, но опять же это обычные привычные нам дистрибутивы линуха для x86.
Сама ось Эльбрус последних версий — релиз Debian с вполне неплохим набором пакетов хотя и не очень полным. Правда крупные пакеты они собирают сами из исходников и там наблюдаются проблемы с тем как могут быть расположены скрипты, конфиги и прочее. К примеру сборка апача меня удивила тем, что привычных a2ensite и иже с ним не было, зато был один здоровый конфигурационный файл) И таких мелочей довольно много.
Правда есть и плюсы. У них есть багтрекер где они вполне лояльно относятся к замечаниям и вполне адекватно реагируют.
http2
15.12.2016 22:52Intel Core i7
Число ядер 4 (8 c Hyper-Threading)
при N = 8 показал ускорение в 8 раз.
То есть при N = 4 процессор был загружен не на 100%? :)
Или на 100%, но нашлись дополнительные вычислительные блоки для Hyper-Threading? :)
Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.
А почему тут не приводили к 1 ГГц? :)
YourChief
15.12.2016 23:17+7Можно видеть, что развертывание циклов работает как на современном Core i7, так и на Эльбрус-4С. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.
Кобыла может тянуть телегу со скоростью 8 км/ч, автомашина может ехать со скоростью 180 км/ч. Мощность кобылы — 1 л.с, мощность двигателя автомашины — 308 л.с. С поправкой на мощность, кобыла эффективнее в 13,7 разhttp2
16.12.2016 00:53-11. Кобыла может проехать там, где ваши 308 л.с. застрянут, хоть их и 308 :)
2. Кобыла может ехать и больше 8 км/ч. :)
3. Кобыла обходится условно бесплатно.
4. Расскажите это жителям моего села, что им нужна машина 308 л.с., а не кобыла. :)
5. Кобылу можно использовать и как легковик (верхом) и как грузовик (с телегой). :)
6. Не под каждую машину запрежешь плуг. Как-то глупо орать поле Жигулем, а тем более Бентли. :)
ef_end_y
16.12.2016 01:47+3Это демагогия уровня «раньше компьютеров не было и жить было лучше» (с) моя бабушка
http2
16.12.2016 03:54-2Почему же демагогия. :)
Или ты уже электричество употребляешь вместо еды? :)
Или ты в лес по грибы поедешь на Бентли? :)
Кстати, с твоей бабушкой можно частично и согласиться.
Не было компов — не было и проблем с компами, ну люди выходили на улицу. :)
А так да, можно залипать в компе.
У меня открыли были интернет клуб когда-то. Так один чувак там все летние каникулы провел, а потом говорил — «ах какие афигенные у миня каникулы были» :)
Я ж не спорю, что есть плюсы и у авто (как бы несомненные, поэтому и не описывал их, можете сделать это Вы :) ).
Просто не нужно так надменно смотреть на коня. :)
И для коня найдем применение.
iga2iga
16.12.2016 00:37А почему все еще 65нм? Или его разрешено производить только в России? Очень бы хотелось увидеть это чудо на 22нм хотя бы и еще меньше. Ну и на больших частотах. Заказать изготовление на стороне нельзя?
semenyakinVS
16.12.2016 04:39Не всё сразу. На вики со ссылкой на некий документ «Российские технологии «Эльбрус» для пер-
сональных компьютеров» пишут, что «к 2020 году планирует[ся] выпускать 14-нм процессор Эльбрус-32С». Нужно ещё четыре годика подождать. Не дешёвое это дело — уменьшать нанометры. Technologic gap в два прыжка не перепрыгнуть.
Заказать изготовление на стороне нельзя?
Во-первых, сама идея Эльбрусов заключается в том, чтобы своё и себя делать. Если заказывать — то легче сразу готовые процессоры закупать. Во-вторых, как я понимаю, Эльбрусы использует во многом военка. А там народ строгий — ану как враг прослушки какие-то в процессоры засунет. Поэтому, думаю, такое решение проблемы не подойдёт.
Надеюсь, автор статьи поправит если чего-то не так сказал.asdfghjk12
16.12.2016 16:53+1Эльбрусы как раз на стороне и делают. В России только 90 нм пока освоили…
VLev
16.12.2016 02:47+1В такой простой синтетике обычно сравнивают не разные процессоры, а достигнутую производительность с теоретически возможной.
Сооветственно, как интерпретировать приведённые результаты?
вот берём «Пример 1. Развертывание циклов»
результат для i7: Время, мс 5-255.
Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).
Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
результаты$ g++ -O3 -o t1 t1.cpp; time ./t1
real 0m0.973s
user 0m0.968s
sys 0m0.000s
$ g++ -O2 -o t1 t1.cpp; time ./t1
real 0m2.834s
user 0m2.828s
sys 0m0.000s
$ g++ -O1 -o t1 t1.cpp; time ./t1
real 0m2.796s
user 0m2.792s
sys 0m0.000s
$ g++ -O0 -o t1 t1.cpp; time ./t1
real 0m14.453s
user 0m14.444s
sys 0m0.000sselgjos
16.12.2016 16:53Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию
Почему?
VLev
16.12.2016 18:17потому что там навскидку видно 5 команд:
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.selgjos
17.12.2016 15:24В частности, только один для сохранения данных.
Действительно как и у коре2.
В целом ясно. Не совсем пальцем в небо как я думал, но всё же не далеко от этого. В действительности и реальности там никаких тактом и не пахнет, но это ладно. Сразу ответить не могу — отвечу позже. Спасибо за карму.
VLev
17.12.2016 16:46я же специально написал: «Беглый взгляд на цикл».
>там никаких тактом и не пахнет
В реальности получается две итерации за 3 такта. ;)
SmartEngines
16.12.2016 17:22Мы использовали внешний цикл в каждом примере. Конкретно в примере 1 было сделано 10000 итераций внешнего цикла. На Core i7 компиляция выполнялась на Microsoft Visual Studio, оптимизация /О2. Одна итерация цикла заняла ~1.5 такта.
Смотрим ассемблер:
000000013F1D6780 xor eax,eax 000000013F1D6782 mov dword ptr [k (013F1EF280h)],eax 000000013F1D6788 test r8d,r8d 000000013F1D678B jle main+10Bh (013F1D67ABh) 000000013F1D678D mov rcx,r13 000000013F1D6790 add edx,dword ptr [rcx] 000000013F1D6792 mov dword ptr [rcx],eax 000000013F1D6794 inc eax 000000013F1D6796 lea rcx,[rcx+4] 000000013F1D679A cmp eax,r8dVLev
16.12.2016 18:48Таким образом, самый плохой результат (255мс) — это реально 1.5 такта на итерацию, что уже соответствует околотеоретической производительности.
Хорошо.
Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
конкретно речь о строчке
a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
Суть:
в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
Утверждение: на одном ядре i7 это невозможно сделать за 5мс.
PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.SmartEngines
17.12.2016 13:02Вы правы, никакого ускорения с помощью раскрутки цикла в данном примере получить нельзя. Обновили результат в посте, спасибо :)
VLev
17.12.2016 16:40хорошо.
Теперь применяем те же рассуждения к Эльбрусу.
получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
- раскрутка цикла делается компилятором Эльбруса автоматически (за такт ядро Эльбруса может сделать только один переход — см доки)
- в «расчете на гигагерц» в этом тесте производительность Эльбруса и core-i одинаковые — две итерации за такт (если использовать максимальный уровень оптимизации компилятором)
selgjos
17.12.2016 19:13-1Видно, что для достижения около-теоретической производительности никакой раскрутки цикла не потребовалось.
Во-первых «около» — это на 50% медленнее? Отличная история — поймать результат лсд и рассуждать об «раскрутка не потребовалась» особенно вкупе с тем, что собственно поймали его ограничение. Вот ведь дураки пацаны — апаратный анроллер запилили, а у экспертов на хабре случилось «не потребовалось».
И даже не самое важно — стоит его зантроллить и он покажет максимальный трупут.
никаких ускорений на порядки раскрутка циклов дать не может
Слишком не хочу на это отвечать. Могу только сказать — могут. Сраться на эту тему мне лень — слишком сложно и долго — можете просто игнорировать этот пункт.VLev
18.12.2016 00:21>Во-первых «около» — это на 50% медленнее?
это на пол-такта медленнее оценки.
>поймать результат лсд
какой результат?
>Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
>поймали его ограничение
Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
>стоит его зантроллить и он покажет максимальный трупут.
исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.
>Могу только сказать — могут
Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
А насчет «могут или не могут» — я за время своей практики многое встречал.
Тем не менее — пример приветствуется.selgjos
18.12.2016 06:08это на пол-такта медленнее оценки.
Оценки в один такт один такт. Что является на 50% медленнее.
какой результат?
Полученный.
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
Когда нечем крыть — обвини. Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд? Ситуация в целом типичная — человек не понимает что и почему происходит. Он получает результат и на делает выводы не учитывая того, чего он не видит и не понимает.
Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
Ну пошли объяснения уровня детского садика. Что такое «ширина конвейера»? И почему её не хватает? Почему же эта ширина конвейера не учитывалась при:
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
А я скажу почему — это всё просто пустой трёп. Эксперт рассчитывал на то, что на разницу между его выводами и реальностью он ответит «не у теоретическая производительность недостижима», либо как-то так.
Моя сентенция относилась к конкретному примеру
Враньё. Если бы она относилась — она бы на это указывала. Относительно к примеру она вообще не имеет смысла. Вроде как у нас есть «теоретическая производительность» и реальная и разница между ними +50%, то зачем повторять ещё раз то, что итак из этого следует при этом в обобщенной форме?
где было показано ускорение в 30 что ли раз за счёт раскрутки.
Меня мало волнует что там написано. Зачем сливаться на это? Я где-то хоть раз упомянул статью и её выводы? Нет. А если нет — зачем мне про это писать?
А насчет «могут или не могут» — я за время своей практики многое встречал.
Но ведь ваши выводы глупы, а понимание слабо. Толку с такой практики? Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт. Да, это моя ошибка — что-то я решил не вытягивать из вас подобные заявления, а они были бы.
По поводу примеров. В данном случае каждая итерация зависит от счётчика, который имеет трупут 1 значение/такт. Не учитывая того, о чём я не буду сейчас говорить, чтобы не давать вам пути для съезжания. В этот примере это нивелируется тем, что это совпало собственно с трупутом записи. Чисто случайно.
Если бы это было чтение, то мы бы получили -100%, а если учитывать всё остальное — 150%. А если нам надо чуть больше на итерации считать?
Ну и конечно же юзкейсы уровня нескольких итераций.VLev
18.12.2016 14:16>Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд?
1. Эксперт — это кто?
2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.
>Что такое «ширина конвейера»? И почему её не хватает?
число портов запуска, я это уже писал
> Почему же эта ширина конвейера не учитывалась при:
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Компилируем то же на icc иполучаем:..B1.5: # Preds ..B1.4 ..B1.5
addl (%rsp,%rdx,4), %edi #13.3
movl %edx, (%rsp,%rdx,4) #14.3
incq %rdx #14.5
cmpq $64000, %rdx #11.21
jl ..B1.5 # Prob 99% #11.21
selgjos
18.12.2016 17:26число портов запуска, я это уже писал
у современных core-i 7 портов выполнения (>5), но они неуниверсальны
Дак больше 5?
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Да нет, просто кто-то не осилил спастить код и написать его вменяемо.
ну и заодно — угадайте, сколько именно тактов работает такой цикл
И сколько же?
Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
В чём же заключается моя ошибка?
На самом деле, до того как Вы пришли — я этого не говорил.
Собственно намекал и моя ошибка была в том, что я это не вытянул. Да.
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
Очень смешно когда «экперт» с познанием уровня 20летний давно рассуждает о чём-то. Я кстати даже не заметил перлов выше. Надо ответить на них.VLev
18.12.2016 19:22> И сколько же?
это Вы у своих голосов разузнайте. Потом поговорим, если ещё будет о чём. ;)
Да, Вспомнил, кого Вы мне живо напомнили: Глеба Капустина из рассказа Шукшина «Срезал»
ww898
19.12.2016 18:29+3«Время в пересчете на 1 ГГц» — это очковтирательство чистой воды. Напишите один и тот же алгоритм для 1Mhz и 1Ghz — это будут принципиально разные вещи по архитекруте, по площади кристалла или FPGA, по… всему! Интерес вызывает только абсолютное время выполнения задачи. Чем меньше тем лучше.
worker
20.12.2016 16:12а что с JVM и CLR? сразу транслируется в VLIW коды или в x86 потом VLIW?
Maccimo
20.12.2016 22:59Про JVM доклад был: https://www.youtube.com/watch?v=yOwvNykK__o
Естественно, никакого x86 там нет.
tzlom
А почему вы прересчитываете на ГГц процессора? У компьютеров и память разная. Тот же 2й тест — я думаю он упирается не в частоту а в память.
SmartEngines
Мы не учитывали различия по памяти, поскольку у Эльбрус-4С и Core i7 не только разная скорость ОЗУ, но и разная структура кэш-памяти, алгоритмы кэширования, есть array prefetch buffer на Эльбрус. Поэтому мы использовали более наглядную и простую характеристику.
lgorSL
У них не только память разная, у них разные архитектуры. Было бы удивительно, если бы архитектура VLIW давала меньшую производительность на такт в задачах, которые явно хорошо параллелятся.
Логичнее сравнивать отношение производительности к потребляемой мощности, но Эльбрус проиграет.