LINUX.ORG.RU

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

 


2

3

Сразу вопрос. По каким попугаям оценить, у кого производительность выше?
Залил на обе машинки этот тест.

Эльбрус 4С

   BYTE UNIX Benchmarks (Version 5.1.3)                                                               
                                                                                                      
   System: MONOCUB GNU/Linux                                                                   
   OS: GNU/Linux -- 2.6.33-elbrus.033.6.63 -- #1 SMP Sat Dec 5 20:55:11 MSK 2015                      
   Machine: e2k (MONOCUB)                                                                             
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")                          
   CPU 0: E2S (1600.8 bogomips)                    
                                                                                                      
   CPU 1: E2S (2251.9 bogomips)                    
                                                                                                      
   CPU 2: E2S (1923.7 bogomips)                    
                                                                                                      
   CPU 3: E2S (1600.0 bogomips)                                                                       
                                                                                                      
   12:56pm  up 5 days  3:14,  2 users,  load average: 0.40, 0.09, 0.03; runlevel Jul                  
                                                                                                      
------------------------------------------------------------------------                              
Benchmark Run: Mon Jul 24 2017 12:56:47 - 13:26:03                                                    
4 CPUs in system; running 1 parallel copy of tests                                                    
                                                                                                      
Dhrystone 2 using register variables        2291941.5 lps   (10.0 s, 7 samples)                       
Double-Precision Whetstone                     1010.8 MWIPS (9.9 s, 7 samples)                        
Execl Throughput                                345.2 lps   (29.5 s, 2 samples)                       
File Copy 1024 bufsize 2000 maxblocks        115158.5 KBps  (30.0 s, 2 samples)                       
File Copy 256 bufsize 500 maxblocks           31426.0 KBps  (30.0 s, 2 samples)                       
File Copy 4096 bufsize 8000 maxblocks        389251.0 KBps  (30.0 s, 2 samples)                       
Pipe Throughput                              264312.7 lps   (10.0 s, 7 samples)                       
Pipe-based Context Switching                  70155.6 lps   (10.0 s, 7 samples)                       
Process Creation                                802.5 lps   (30.0 s, 2 samples)                       
Shell Scripts (1 concurrent)                    898.2 lpm   (60.1 s, 2 samples)                       
Shell Scripts (8 concurrent)                    297.7 lpm   (60.1 s, 2 samples)                       
System Call Overhead                         499089.2 lps   (10.0 s, 7 samples)                       
                                                                                                      
System Benchmarks Index Values               BASELINE       RESULT    INDEX                           
Dhrystone 2 using register variables         116700.0    2291941.5    196.4                           
Double-Precision Whetstone                       55.0       1010.8    183.8                           
Execl Throughput                                 43.0        345.2     80.3                           
File Copy 1024 bufsize 2000 maxblocks          3960.0     115158.5    290.8                           
File Copy 256 bufsize 500 maxblocks            1655.0      31426.0    189.9                           
File Copy 4096 bufsize 8000 maxblocks          5800.0     389251.0    671.1                           
Pipe Throughput                               12440.0     264312.7    212.5 

Pipe-based Context Switching                   4000.0      70155.6    175.4                           
Process Creation                                126.0        802.5     63.7                           
Shell Scripts (1 concurrent)                     42.4        898.2    211.8                           
Shell Scripts (8 concurrent)                      6.0        297.7    496.1                           
System Call Overhead                          15000.0     499089.2    332.7                           
                                                                   ========                           
System Benchmarks Index Score                                         213.4                           
                                                   
------------------------------------------------------------------------                              
Benchmark Run: Mon Jul 24 2017 13:26:03 - 13:55:53 
4 CPUs in system; running 4 parallel copies of tests                                                  
                                                   
Dhrystone 2 using register variables        9166126.3 lps   (10.0 s, 7 samples)                       
Double-Precision Whetstone                     4044.1 MWIPS (9.9 s, 7 samples)                        
Execl Throughput                               1321.1 lps   (29.4 s, 2 samples)                       
File Copy 1024 bufsize 2000 maxblocks        151441.3 KBps  (30.0 s, 2 samples)                       
File Copy 256 bufsize 500 maxblocks           39385.3 KBps  (30.0 s, 2 samples)                       
File Copy 4096 bufsize 8000 maxblocks        536897.5 KBps  (30.0 s, 2 samples)                       
Pipe Throughput                             1050143.7 lps   (10.0 s, 7 samples)                       
Pipe-based Context Switching                 278396.0 lps   (10.0 s, 7 samples)                       
Process Creation                               2823.1 lps   (30.0 s, 2 samples)                       
Shell Scripts (1 concurrent)                   2359.9 lpm   (60.1 s, 2 samples)                       
Shell Scripts (8 concurrent)                    340.2 lpm   (60.3 s, 2 samples)                       
System Call Overhead                        1640121.0 lps   (10.0 s, 7 samples)                       
                                                                                                      
System Benchmarks Index Values               BASELINE       RESULT    INDEX                           
Dhrystone 2 using register variables         116700.0    9166126.3    785.4                           
Double-Precision Whetstone                       55.0       4044.1    735.3                           
Execl Throughput                                 43.0       1321.1    307.2                           
File Copy 1024 bufsize 2000 maxblocks          3960.0     151441.3    382.4                           
File Copy 256 bufsize 500 maxblocks            1655.0      39385.3    238.0                           
File Copy 4096 bufsize 8000 maxblocks          5800.0     536897.5    925.7                           
Pipe Throughput                               12440.0    1050143.7    844.2                           
Pipe-based Context Switching                   4000.0     278396.0    696.0                           
Process Creation                                126.0       2823.1    224.1                           
Shell Scripts (1 concurrent)                     42.4       2359.9    556.6                           
Shell Scripts (8 concurrent)                      6.0        340.2    567.1                           
System Call Overhead                          15000.0    1640121.0   1093.4                           
                                                                   ========                           
System Benchmarks Index Score                                         544.5

R1000

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System:  GNU/Linux
   OS: GNU/Linux -- 2.6.33-elbrus.033.6.49.rt -- #1 SMP PREEMPT RT Mon Aug 3 20:14:37 MSD 2015
   Machine: sparc64 (R1000)
   Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
   CPU 0: R1000 (0.0 bogomips)
          
   12:50pm  up 11 days 10:44,  1 user,  load average: 0.33, 0.08, 0.05; runlevel Jul

------------------------------------------------------------------------
Benchmark Run: Mon Jul 24 2017 12:50:01 - 13:18:50
16 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        3025875.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                      917.8 MWIPS (9.9 s, 7 samples)
Execl Throughput                                804.3 lps   (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         53371.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           15319.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        150715.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                              213427.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  35418.4 lps   (10.0 s, 7 samples)
Process Creation                               1392.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1289.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    601.4 lpm   (60.1 s, 2 samples)
System Call Overhead                         284014.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    3025875.8    259.3
Double-Precision Whetstone                       55.0        917.8    166.9
Execl Throughput                                 43.0        804.3    187.0
File Copy 1024 bufsize 2000 maxblocks          3960.0      53371.1    134.8
File Copy 256 bufsize 500 maxblocks            1655.0      15319.3     92.6
File Copy 4096 bufsize 8000 maxblocks          5800.0     150715.5    259.9
Pipe Throughput                               12440.0     213427.0    171.6
Pipe-based Context Switching                   4000.0      35418.4     88.5
Process Creation                                126.0       1392.4    110.5
Shell Scripts (1 concurrent)                     42.4       1289.2    304.1
Shell Scripts (8 concurrent)                      6.0        601.4   1002.3
System Call Overhead                          15000.0     284014.9    189.3
                                                                   ========
System Benchmarks Index Score                                         192.2

------------------------------------------------------------------------
Benchmark Run: Mon Jul 24 2017 13:18:50 - 13:51:45
16 CPUs in system; running 16 parallel copies of tests

Dhrystone 2 using register variables       47917609.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    14677.4 MWIPS (10.0 s, 7 samples)
Execl Throughput                               3214.0 lps   (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         41191.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           10876.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        221690.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             3390922.6 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 613211.1 lps   (10.0 s, 7 samples)
Process Creation                               5189.2 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   7273.2 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    953.4 lpm   (60.4 s, 2 samples)
System Call Overhead                         794367.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   47917609.0   4106.1
Double-Precision Whetstone                       55.0      14677.4   2668.6
Execl Throughput                                 43.0       3214.0    747.5
File Copy 1024 bufsize 2000 maxblocks          3960.0      41191.0    104.0
File Copy 256 bufsize 500 maxblocks            1655.0      10876.9     65.7
File Copy 4096 bufsize 8000 maxblocks          5800.0     221690.8    382.2
Pipe Throughput                               12440.0    3390922.6   2725.8
Pipe-based Context Switching                   4000.0     613211.1   1533.0
Process Creation                                126.0       5189.2    411.8
Shell Scripts (1 concurrent)                     42.4       7273.2   1715.4
Shell Scripts (8 concurrent)                      6.0        953.4   1589.0
System Call Overhead                          15000.0     794367.9    529.6
                                                                   ========
System Benchmarks Index Score                                         783.1

★★

Последнее исправление: TomBOY (всего исправлений: 1)

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

TomBOY ★★
() автор топика
Ответ на: комментарий от TomBOY

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

I-Love-Microsoft ★★★★★
()

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

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

Это конкретно провал нагрузки на 1-о ядро.

TomBOY ★★
() автор топика
Ответ на: комментарий от TomBOY

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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С - 47 сек R1000 - 4:50 мин.

TomBOY ★★
() автор топика
Последнее исправление: TomBOY (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

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

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

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

robot12 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

TomBOY ★★
() автор топика
Ответ на: комментарий от ckotinko

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

anonymous
()

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

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

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

robot12 ★★★★★
()
Последнее исправление: robot12 (всего исправлений: 1)
Ответ на: комментарий от TomBOY

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

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

robot12 ★★★★★
()
Последнее исправление: robot12 (всего исправлений: 1)
Ответ на: комментарий от ckotinko

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

robot12 ★★★★★
()
Ответ на: комментарий от robot12

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

TomBOY ★★
() автор топика

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

TomBOY ★★
() автор топика
Ответ на: комментарий от TomBOY

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

robot12 ★★★★★
()
Ответ на: комментарий от robot12

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

TomBOY ★★
() автор топика
Ответ на: комментарий от robot12

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

DeaDDooMER
()

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

no-such-file ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

anonymous
()

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

xmikex ★★★★
()
Ответ на: комментарий от DeaDDooMER

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

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

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

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

robot12 ★★★★★
()
Ответ на: комментарий от Inshallah

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

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

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

robot12 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

NiTr0 ★★★★★
()
Ответ на: комментарий от robot12

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

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

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

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

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

NiTr0 ★★★★★
()
Ответ на: комментарий от robot12

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

anonymous
()
Ответ на: комментарий от NiTr0

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

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

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

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

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

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

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

проблема - в VLIW

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

robot12 ★★★★★
()
Ответ на: комментарий от robot12

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

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

DeaDDooMER
()
Ответ на: комментарий от robot12

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

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

DeaDDooMER
()
Ответ на: комментарий от robot12

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

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

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

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

Inshallah
()
Ответ на: комментарий от DeaDDooMER

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

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

robot12 ★★★★★
()
Ответ на: комментарий от Inshallah

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

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

robot12 ★★★★★
()
Ответ на: комментарий от NiTr0

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

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

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

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

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

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

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

user_id_68054 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

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

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

robot12 ★★★★★
()
Ответ на: комментарий от robot12

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

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

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

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

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

Да же не в нём

в нем.

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

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

NiTr0 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

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

«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 это не хорошо - согласен.

robot12 ★★★★★
()
Ответ на: комментарий от robot12

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

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

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

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

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

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

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

Tegra X1 vs Tegra X2

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

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

anonymous
()
Ответ на: комментарий от NiTr0

что «было»?

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

robot12 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.