![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Скорость Эльбруса
Появились результаты измерения производительности Эльбруса, которым вроде бы можно доверять. Смотрите страницу 7: http://www.kpda.ru/upload/iblock/a80/senkov_25.11.2015.pdf
Тест Dhrystone у меня под рукой, так что я тут быстренько прикинул. Получается, последний Эльбрус-401 выпуска 2015 года в 16 раз медленнее моего iMac 2012 года. Процессоры соответственно Эльбрус-4С 800МГц и Intel Core i5 2.7ГГц.
Интересно, что производительность Эльбруса получилась равной скорости платы Raspberry Pi 2 Model B 1000MHz ($36 на Амазоне).
Тест Dhrystone у меня под рукой, так что я тут быстренько прикинул. Получается, последний Эльбрус-401 выпуска 2015 года в 16 раз медленнее моего iMac 2012 года. Процессоры соответственно Эльбрус-4С 800МГц и Intel Core i5 2.7ГГц.
Интересно, что производительность Эльбруса получилась равной скорости платы Raspberry Pi 2 Model B 1000MHz ($36 на Амазоне).
no subject
Первый запуск - Ubuntu 14.04 x86_64, gcc 4.8, флаги по умолчанию.
8 CPUs in system; running 8 parallel copies of tests
Dhrystone 2 using register variables 149182837.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 32653.5 MWIPS (8.8 s, 7 samples)
на одно ядро в таком случае будет 18647854.7 и 4081.7. (У AMD не чистое понятие "ядра" в таких процессорах, но в эту тему глубоко влезать не буду, желающие да загуглят.)
Во втором взял gcc 5.2.0 и -march=native (разрешает AVX).
8 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 27508601.1 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4544.8 MWIPS (9.4 s, 7 samples)
Резюмируя - если на плавучку цифры ещё более-менее нормальные (видимо, Эльбрус тоже векторизует?), то для целочисленных расчётов или у меня не те попугаи в принципе, или там совершенно страшный провал по скорости. Кто знает, как соотносятся lps этого варианта с Dps из pdf?
no subject
У десктопных процов плавучка всегда была хилой.
Потому что она не очень им нужна, а также из маркетинговых соображений, что надо в бюджете клиента место оставить для серверных процов и для рабочих станций (ну собственно, поэтому даже была линейка 486sx у которых не было матсопроцессора).
А процы для серверов и для рабочих станций, конечно всегда оптимизировали под плавучку, потому что это в дооблачную эру было их главное приложение.
После y2k конечно многое изменилось, но всё равно плавучка удел узкоспециализированных вычислителей.
А целочисленные у десктопов всегда были хорошими, ибо оно как раз более всего влияет на десктопную активность.
no subject
Ситуацию 80-х годов тут обсуждать нечего, а среди современных x86 (и не только?) процессоров это справедливо только для Intel (которые не в состоянии или принципиально не желают сделать даже такую банальность, как быстрая работа с денормализованными), и это не зависит от десктопа или сервера - Xeon у них точно так же тормозит, как В моём тесте AMD, который давно и прочно заботится о плавучке - вот, например, я недавно сравнивал (http://netch80.livejournal.com/39929.html).
> А процы для серверов и для рабочих станций, конечно всегда оптимизировали под плавучку, потому что это в дооблачную эру было их главное приложение.
Что-то непохоже. Скорее они готовы заставить пользователей и авторов компиляторов выгнуться и перейти на тотальный SSE.
> А целочисленные у десктопов всегда были хорошими, ибо оно как раз более всего влияет на десктопную активность.
Тут вопрос не в целочисленности как таковой (иначе то же деление уже бы ускорили по максимуму, а не гнали всё через ленивый, как турист под пальмой, SRT). Тут отсутствие SIMD для целочисленных в массовых реализациях (MMX не вспоминать), а как следствие - зависимость скорости работы от скорости шедулинга команд. А быстрый шедулинг простых команд больше зависит от отработанности системы исключения конфликтов в конвейере, от качества реализации базовых OoO подходов вроде Tomasulo, и тому подобного.
У меня сильное подозрение, что это то, на чём десять лет назад споткнулся Intel с IA-64. Можно легко заточить систему команд под конкретные количественные свойства процессора, как количество АЛУ и их сочетаемость - для этого всего лишь надо выставить конкретные потроха наружу. Но как только возникает вопрос о развитии или расширении (что будет, если я поставлю 3 АЛУ вместо 2?), кто будет переписывать программы под другой шедулинг и увеличенную ширину необходимого командного слова? А наоборот, что будет, если в пакете на исполнение послать 3 действия для АЛУ вместо 2, что на это скажут старые процессоры? IA-64 имел фиксированную ширину команды. Эльбрус-4 имеет нефиксированную пачку субкоманд и слово "commit" в конце, но пределы исполнения всё равно заданы. Можно ли исполнять команды быстрее, чем они поступают, и сколько блоков детекта потенциальных конфликтов потребуется для этого? Скорее всего, у Эльбруса крайне слабый шедулер, который тормозит по каждому чиху.
Вообще, VLIW в этом плане именно как ISA (а не как внутренние детали) выглядит крайне неудачно. И системы с трансляцией, как x86, и с прямым исполнением и минимумом OoO вроде переименования регистров, как быстрые версии современных RISC, его обгоняют. Он оказался как фиксация на машинном коде устаревшего компьютера вместо переносимого языка хотя бы уровня Паскаля.
no subject
- Суть в том, что на этапе исполнения машкода уже потеряна почти вся информация, что могла помочь оптимизации.
То есть вероятно VLIW может стать следующим шагом, но только если он будет работать на более высоком уровне абстракции - например в битовых свойствах, типа тех где обычно сидит ECC/права доступа/биты кеша, вписать данные что конкретное слово данных это не просто слово а элемент массива, или хэша, или б-дерева, и эти данные (плюс статистику) использовать чтобы выбрать конкретный алгоритм шедулера.
Или другими словами - это нужно совсем новую теорию процессора разрабатывать, со всеми вытекающими.