UnixBench Эльбрус-4С и R1000

Это неверная методика. Все такие тесты оптимизированы под классические компьютеры (если даже не под x86). У первого (Эльбрус 4С) колоссальный потенциал оптимизации при написании своего кода. Однако готовый код переписывать под эти архитектуры никто не будет.

Какая в целом стоит задача перед этими системами?

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

Этот тест в составе ОС, которая идёт к машине есть. Т.е. оптимизирован?

Сильно сомневаюсь. Он скомпилирован ;) Вот это факт. А оптимизирован - вряд ли.

Есть более «тупая мерялка»

time python -m timeit 'sum(range(10**7))'
4C
==
10 loops, best of 3: 4.91 sec per loop
real    3m18.549s
user    3m11.350s
sys     0m7.200s

R1000
======
real 9m18.846s

Замерена скорость питона, а не потенциал оптимизации. Судя по задаче - сойдет.

Какой там питон если не секрет? python --version и python3 --version что говорят?

Python 2.7.3 и там и там.
Тут проскакивала ещё мерялка:

#include <assert.h>
#include <stdlib.h>
#include <stdbool.h>

#ifdef VECTOR
#include <vector>
#endif

int main()
{
    const int n = 1214739071;
    int prime_count=0;
    assert( sizeof(char)==1 ); /// ну мало ли...
#ifdef VECTOR
    std::vector<char> is_prime(n+1);
#else
    char* is_prime = (char*) malloc(n+1);
    if( !is_prime ) return 1;
#endif
    for( int i=2; i<=n; ++i )  is_prime[i] = true;

    is_prime[0] = is_prime[1] = false;

    for( int p=2; p*p<=n; ++p )
    {
        if( is_prime[p] )
        {
            for( int i=p*p; i<=n; i+=p )
            {
                is_prime[i] = false;
            }
        }
    }

    for( int i=0; i<20; ++i )
    {
        if( is_prime[i] )  printf("%d ",i);
    }

    for( int i=0; i<=n; ++i )
    { 
        prime_count += is_prime[i];
    }

    printf( "prime_count=%d\n", prime_count );

    return 0;
}

4С лучше, в любом случае. Кстати, а откуда доступ к этим машинам? Для какой цели именно они?

Это неверная методика.

Почему ? Мне кажется, как раз верная. Эти изделия изготовлены для исполнения, совместно с компилятором, инструкций «чужого» процессора и оптимизации их налету. Как раз и видно эффективность решения в целом а не сферического коня в вакууме (Эль-75). Никто не будет писать код под «Эльбрус» без компилирующей прослойки, это не эффективно, и код надо будет генерировать каждый раз под новый процессор (количество ядер разное). Ядра эльбруса - это да же не потоки, а нечто более низкое.

По R1000 кроме того что это SPARC, ничего о них не знаю.

Что у них за любовь к ядрам ветки 2.6 ??? Старье же.

Денег только на одну. Типа сервак будет. Многопоточка, но не так чтобы мульон запросов. Молотить циферки и, чтобы не умерла она от этого дела, залипнув от напряга, т.к. МГц там не пойми как считать.
У R1000 - 1000Мц, но сливает 800МГц 4C.

подозреваю, что просто ниасилили портирование 3.х.

Никто не будет поднимать версию просто так. Как изначально портировали 2.6, так и работают. На хомячков пох.

И да вопрос - R1000, судя по сайту, 4-х ядерный процессор, а в тесте помянуто 16, это 4-х процессораная система ?

И вот да же в тесте видно, что 4-х процессораная система на R1000 обходит 4-х процессорный эльбрус.

Причём эффективность спарков на лицо 783/192 = 4,078, а 544/213 = 2,55, то есть масштабируемость парка получше. А эльбрус ведет себя как суперскаляр.

У R1000 - 1000Мц, но сливает 800МГц 4C.

Да, но и нанометров у спарка больше. А насчёт слива я не уверен, SPARC масштабируется сокетами (то есть можно добавлять CPU и прирост производительности линейный будет) а вот эльбрус ограничен 4мя сокетами, да и производительность у него не линейно приростает.

Подозреваю что это какой нить МСВС 3.0 сгнивший.

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

не хотят с dts связываться.

Coremark V1.0

4C
====

make XCFLAGS="-DMULTITHREAD=64  -DUSE_PTHREAD" REBUILD=1
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 13271
Total time (secs): 13.271000
Iterations/Sec   : 2260.568156
Iterations       : 30000
Compiler version : GCC4.4
Compiler flags   : -O2   -lrt
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x5275
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 2260.568156 / GCC4.4 -O2   -lrt / Heap


R1000
=======

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 16631
Total time (secs): 16.631000
Iterations/Sec   : 1803.860261
Iterations       : 30000
Compiler version : GCC4.4
Compiler flags   : -O2   -lrt
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x5275
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 1803.860261 / GCC4.4 -O2   -lrt / Heap

Евромеханика. Ясно. А не пробовали там Solaris 10 гонять ? Было бы интересно! В Linux той версии NUMA крива и не эффективна.

На солярку МЦСТ забила как-то. Она есть у них, но только для старых микро-90s.

Оригиналы :) На солярку забили, а линукс то же древний :)

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

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

Потому что это железки для военных, и кукареки айфонохомячков им побоку.

А что, nbench-byte можешь запилить?

У кое-какой неклассической кукурузы тоже был потанцевал, бгг.

по богомипсам конечно же

Вы про Эльбрусы, похоже, знаете столько же, сколько и про эти спарки.

Не щупал именно эльбрусы, но прочитал патенты (для примера US patent 7143401) и прекрасно понимаю что такое ILP и TLP.

Код на Эльбрусах обратно совместим

Хорошо, скомпилировав код для 4С, что Вы получите на 8С ? Ответ - загруженные 4 ядра, то есть компилятор, на момент компиляции, не знал про 8-мь ядер.

Потому что это железки для военных

Какая разница для кого железка, если она (железка) тупа и медленна ?

То что везде пишут «эльбрус наш» это все фуфло, выпуск на фабрике в Тайване все перечеркивает.

Все такие тесты оптимизированы под классические компьютеры (если даже не под x86)

бред, тесты написаны на кошерном С. который платформонезависим.

У первого (Эльбрус 4С) колоссальный потенциал оптимизации при написании своего кода.

осталось подождать, пока родят компилятор, раскрывающий весь потанцевал? ну-ну...

Эти изделия изготовлены для исполнения, совместно с компилятором, инструкций «чужого» процессора и оптимизации их налету.

не совсем. отделяйте мух от котлет.

изначально - пилилось под х86-совместимость (ну т.е. набор аппаратно-программных костылей, чтобы х86 виртуалка крутилась с минимальным оверхидом). ванговали «убийцу пентиума-4», но получился лютый фэйл с дикими тормозами в х86, который оперативно был запрятан под коврик и упоминается теперь вскользь.

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

и да, проблема не в количестве ядер (компилятор вообще не генерит код под N ядер, это делает программист). проблема - в VLIW, который отвратно переваривает ветвления.

Даже openmp все ядра что есть грузит, но обычно потоки создают вручную.

изначально - пилилось под х86-совместимость

Так оно и сейчас так живёт. Костыли видны в виде CF карты/разъёма которые видно на видосах https://youtu.be/gCqb65_Sz_I?t=56s

Убийцей Пентиумов оно не стало, по двум причинам:

- Пентаковский делал ядро пентиума, а этот товарисчь давно раскуривал Эль-76 (автор)

- Бабаян купили со всеми потрохами, да же медальку дали.

компилятор вообще не генерит код под N ядер

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

проблема - в VLIW

Да же не в нём, вон nvidia свой denver пилит. Вопрос во времени, товарищи из МЦСТ упустили его, и появились HyperThreading, ManyCore CPU, сильно изменилась среда которую планировали эмулировать, и догнать не получится уже никогда.

Хорошо, скомпилировав код для 4С, что Вы получите на 8С ? Ответ - загруженные 4 ядра, то есть компилятор, на момент компиляции, не знал про 8-мь ядер.

Не правильный ответ. Не путайте многоядерность и длинную команду.
В одной из последних модели добавили два fpu(кажется в 8C). Код для старых процессоров просто не будет их использовать. Эти два модуля fpu будут простаивать, да.
Тем не менее, многопоточную программу скомпилированную для 4С можно будет запустить на 8С с использованием всех восьми ядер. Тут нет никакой магии.

никакого аппаратного планирования исполнения в процессоре нет

Оно и не нужно. Потому что ядра используются потоками, которые делаются каким-нибудь pthreads. Их никто и нигде не планирует аппаратно.
А вот операции на ядре - да, это уже то о чём вы говорите. Но чем в старом коде для 4C не задействованные модули на 8С отличаются от старого кода под i686(а то и старее) на современном i7 с кучей simd? Рандомная лапша x86 не оптимизируется динамически под современные процессоры - всё равно надо бегать, пересобирать код, а то и переписывать что бы получить стопроцентную производительность.

если она (железка) тупа и медленна ?

Насколько медленна? В круизис играть не позволяет, или решать какие-либо практические задачи? У западных партнёров POWERPC G5, и самолёты вроде не падают.

То что везде пишут «эльбрус наш» это все фуфло, выпуск на фабрике в Тайване все перечеркивает.

Эльбрус-1С делается у нас. Тут же не в процессоре проблема, а в производственной линии.

Тем не менее, многопоточную программу скомпилированную для 4С можно будет запустить на 8С с использованием всех восьми ядер. Тут нет никакой магии.

Ткните в документацию, где прямо об этом написано, а то как то после прочтения патентов, складывается ровно обратное мнение.

У западных партнёров POWERPC G5

Без «G5» наверное? :) Обрадую Вас, «Эльбрусы» (именно VLIW) в самолетах и прочей военной технике никто не ставит. Ставят микросхемы серий 1890ВМ/1990ВМ (Комдив-32/64).

Без обид, ты немножечко не в теме о том, что я имею ввиду. Из твоих текущих представлений твои слова отчасти справедливы.

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

Это как чтобы выжать из ARM NEON его потенциал, нужно приложить некоторые усилия - подробностей не знаю, но вроде как либо явно задействовать Си-обертки, либо как-то особо оформить код. Тут аналогично.

Использует ли unixbench или другие подобные тесты особенности архитектуры Эльбрус? Честно - сомневаюсь.

Поправьте, если ошибаюсь.

Все такие тесты оптимизированы под классические компьютеры (если даже не под x86). У первого (Эльбрус 4С) колоссальный потенциал оптимизации при написании своего кода

лол!? и что прикажешь делать с этим «потенциалом»? :-)

когда программа тормозит у клиента — бегать и объяснять всем «вы не разбираетесь.. тут есть огромный потенциал оптимизации производительности!»..

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

а разработчик компилятора я так понял тож не сможет задействовать весь потенциал, так как optimization fence какбэ всё будет ограничивать..

Но для их (результатов) получения - нужно особым способом писать код

Вот Вы мне скажите - кто это будет делать ? Ну то есть, понятно что спецзадачи будут оптимизированы, а общее ПО кто переделывать будет ? Притом что оно всё «иностранное», в том смысле что российских разработчиков там кот наплакал (раз), будут ли принимать в основную ветку «оптимизации написанные особым способом» не понятно.

Это как чтобы выжать из ARM NEON его потенциал

А что с ним не так ? Заморочки с выравниванием данных только. Но это вполне себе обычный SIMD.

Так оно и сейчас так живёт.

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

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

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

а планировщик - раскидывает (микро)операции по исполнительным устройствам. и в случае vliw - да, он отсутствует, поток команд генерится компилятором. из-за чего производительность в лучшем случае будет сравнима с аналогичным по ширине in-order суперскалярным камнем, но скорее - будет сливаться.

Да же не в нём

в нем.

вон nvidia свой denver пилит

и причем тут суперскалярный денвер к тупому VLIW?

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

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

и причем тут суперскалярный денвер

«The report also points to the team, packed full of CPU „jockeys“ from Intel, AMD, HP, Sun and Transmeta. They have tons of experience in superscalar, OoO (out of order) execution design, micro-code, VLIW, hyper-threading, and multi-core.» source - http://www.tomshardware.com/news/vmware-veeam-management-pack-vcenter-fault-t...

Не знаю, пошло ли в массы но было точно.

Но то что VLIW это не хорошо - согласен.

Хорошим справочником может послужить http://vak.ru/doku.php/proj/besm/elbrus-1kb

Не знаю, пошло ли в массы но было точно.

что «было»? команда, которая имела опыт в т.ч. в разработке VLIW? ну были так такие люди, и чо? причем это к архитектуре?

Но то что VLIW это не хорошо - согласен.

всему свое место. VLIW-у очень хорошо в DSP живется. ну т.е. там, где надо тупо лопатить большие объемы данных с минимумом условных переходов. ну т.е. там, где планировщик нафиг не нужен.

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

и причем тут суперскалярный денвер к тупому VLIW?

Tegra K1 - VLIW.
Tegra X1 - ARM.
Tegra X2 - VLIW.

Tegra X1 vs Tegra X2

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

По тестам выходит обратное.

что «было»?

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

TEGRA K1 PROCESSOR SPECIFICATIONS

GPU: 192 NVIDIA CUDA® Cores

CPU: NVIDIA 4-Plus-1™ Quad-Core ARM Cortex-A15 «r3»

http://www.nvidia.com/object/tegra-k1-processor.html