Как Вам объяснить, эльбрус несколько иначе относится к однопоточным программам. Компилятор на нём лучше анализирует, сколько инструкций он может выполнить за такт и выполняет их, если это возможно. Если это элементарно (без серьёзного анализа, который, видимо g++ для архитектуры эльбрус пока делать не умеет) сделать нельзя (алгоритм не позволяет делать действия параллельно, т.к. одно действие основано на результатах другого, то эльбрус будет нехило тормозить, что и показал тест ниже со сливом в 25 раз). Детали реализации выполнения нескольких операций за одну единицу времени, заметьте, даже не за такт, т.к. распределенным вычислениям или многопроцессорным системам(про последние не уверен на 100%) вообще пофигу на такты в разных вычислительных модулях, т.к. главное, чтобы обработанные данные правильно синхронизировались, (куча отдельных процессоров, хитрая архитектура с длинными командами и несколькими АЛУ (как раз наш случай), работающими независимо и одновременно, которые по возможности выполняются на разных АЛУ или вообше GPU архитектура и т.д.) тут роли абсолютно никакой не играют.

А теперь задумайтесь, что я сказал некорректного в посте выше, от которого «Сквозит от вас абсолютным непониманием темы.» То что числодробтилку на x86-64 архитектуре грамотные разработчики будут распараллеливать по возможности и не во вред вычислительной сложности алгоритма, пусть и не так элементарно, как в задумке это должен делать Эльбрус (надеюсь, что по соображениям разработчиков этим должен заниматься компилятор, а не человек, иначе архитектура очень сложна для понимания).

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

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

ЗЫ, если я прав, что вы имеете непосредственное отношение к разработке Эльбрусов, то хотелось бы услышать про общий путь, так сказать, идеал, к чему стремится Эльбрус. Замена ли это иностранных процессоров на отечественные или же новая, хорошая архитектура, которая в будущем при должном финансировании сможет конкурировать с Intel и AMD не только на отечественном рынке?

там длинная команда плавающей длины.

«которая в будущем при должном финансировании сможет конкурировать с Intel и AMD не только на отечественном рынке?»

Кто ж ее пустит на мировой рынок? Будете только в КНДР ее продавать.

[vbrosmode] Её в кндр будут делать, нахрен им её ещё и покупать? [/vbrosmode]

Бабаян возглавлял МЦСТ в 1992-2004 годах; за это время они произвели SPARC-совместимый Эльбрус-90микро и мегатонны обещаний о том, как они всех порвут своим E2k. Через 3 года после ухода Бабаяна МЦСТ выкатил настоящий E2k. Вопрос - каким курсом двигался Бабаян, если, по его словам, «архитектура» у него была готова аж в 1991?

Глянь его лекции и перестань выдумывать бред: http://www.iis.nsk.su/ershov_lectures/2008 2е видео с 24ой минуты где то - про начало разработки архитектуры эльбрус 3 про сотрудничество с санками про переход в интел итд. Можешь и сначала глянуть, рассказывает про историю отечественных машин (Эльбрус/БСЭМ) довольно интересно.

Бабаян возглавлял МЦСТ в 1992-2004 годах; за это время они произвели SPARC-совместимый Эльбрус-90микро и мегатонны обещаний о том, как они всех порвут своим E2k. Через 3 года после ухода Бабаяна МЦСТ выкатил настоящий E2k. Вопрос - каким курсом двигался Бабаян, если, по его словам, «архитектура» у него была готова аж в 1991?

Глянь его лекции и перестань выдумывать бред

Есть какие-то претензии по фактам? Нет? Тогда заткнись.

Спасибо нам очень важно ваше мнение. Мы разместим его на рулоне вместе с другими.

Тут идёт активная работа с памятью, не исключено что затык там. Этот комп имеет весьма устаревшую уже обвеску. В новых процессорах это решено. Более-менее можно было бы исключить это если бы у нас был хотя бы Эльбрус-4С для теста.

К МЦСТ никакого отношения не имею, но всегда рад быть лоббистом за оплату, так что если меня читают, то пишите )

Нечего параллелить + работа с памятью.

помимо счётчиков и сравнений основная операция тут A=A^B;B=A^B;A=A^B; А в ней операции последовательные.

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

Может чисто сишный вариант лучше будет работать. Ещё попробовать убрать различные параметры -O3 -ffast -fno-inline. Проверить разные комбинации.

-std=c99 
#include <stdio.h>
#include <stdlib.h> 
int main()
{
        int n=214739550;
	int * prime = (int*)malloc((n+1) * sizeof(int)); 
	for(int i = 0; i < n; i++) prime[i]=1;
	prime[0] = prime[1] = 0;
	for (int i=2; i*i<=n; ++i)
		if (prime[i])
			for (int j=i*i; j<=n; j+=i)
                		prime[j] = 0;
	free(prime);return 0;
}

Так как статус этого документа мне не известен

Мифы, легенды, e2k.

Компилятор на нём лучше анализирует, сколько инструкций он может выполнить за такт и выполняет их, если это возможно

ЕМНИП компилятор там фигачит кучу спекулятивного кода: если задача параллелится, то результаты подхватываются, если нет - отбрасываются.

А возразить как обычно нечего.

Там целый сборник документов. Там же написано как с DSP работать. Что то по их асемблеру.

Запрашивал от своей конторы, прислали на почту.

Ты намекаешь что я это придумал? Твоя воля думать как угодно.

Усохни :) Что тебе возразить? Танк не нужен, есть велосипед.

Там же написано как с DSP работать

Умеет DSP непосредственно выполнять программы, расположенные в памяти Эльбруса, и прозрачно писать туда же результаты?

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

Хоть сейчас купи у них за 130К готовую собранную систему с Эльбрусом. Отладочные платы некоторых дорогих ПЛИС стоят в разы больше - мне с такими приходилось работать, так что сравнительно не дорого.

Дорого? Перехотел? Жди массового производства, если оно вообще состоится. А я бы этого хотел. Процессоры достойные, если подшаманить из них можно хорошо выжать.

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

А мне можно такую книгу? А то книга Ким-Перекатов-Ермаков от 2013 не содержит описания списка инструкций CPU.

На правах олдфага могу добавить: судя по публикациям «Программировании» рубежа 1980х-90х, у Эльбрус-3 была традиционная CISC-архитектура Эльбрус-1 и Эльбрус-2.

Я видел «Эльбрус» вживую. По-моему, 3-й или 2-й. Его примерно к середине 2000-х пришлось сдать на металлолом, так как специалистов не осталось. Но судя по тому, какие специалисты у нас в институте были — система команд могла быть любой. Спецы были вполне достойные.

А насчёт отечественного на базе SPARCv8 - чем не устраивает «Эльбрус-90микро» исп.31.01? ... Тоже вполне достойная тачка. Или танцору яйца мешают? Ведь работали мы на ZX Spectrum, и на БК/Векторах/Микрошах - никто не ныл. И на «псевдокоде» программы писали, листая учебники Кнута.

Или ты опять про свою «экономическую» окупаемость человека-часа для критически важных специалистов? Это их сейчас как собак не резаных. А в 1940-е годы брали в вычислительную математику только элиту, так как другие отсеивались в процессе решения задач. К концу 1970-х из-за переизбытка финансовых вливаний наш «Минсредмаш» стал загибаться и загнивать. А по-сути — настоящий специалист всегда востребован.

Чего вы привязялись так к этому железу?

своим собственным DE

Умеет DSP непосредственно выполнять программы, расположенные в памяти Эльбруса, и прозрачно писать туда же результаты?

Следующей проблемой стала интеграция в новую СнК четырёхъядерного DSP-кластера (IP-блока). Он работает в составе системы на кристалле под управлением универсальных ядер «Эльбрус», которым доступны все его адресуемые ресурсы – регистры и память. Во внутреннюю прямоадресуемую память кластера записывается программа для DSP-ядер, запуск и управление которыми осуществляется посредством операций универсальных ядер с регистрами кластера. Такие операции организованы аналогично обменам с внешними устройствами, поэтому далее они будут именоваться «I/O-обменами».

DSP-кластеру доступна не только его внутренняя память, но и память всей СнК. Пересылка данных между ними (DMA-обмен) осуществляется восьмиканальным DMA-контроллером DSP-кластера, выполняющим задания универсальных ядер «Эльбрус».

Двухъядерная гетерогенная система на кристалле ЭЛЬБРУС-2С+

Ключевые слова были «непосредственно» и «прозрачно»; вопрос был задан человеку, предположительно имеющему опыт работы или доступ к неопубликованной документации.

Двухъядерная гетерогенная система на кристалле ЭЛЬБРУС-2С+

Прямых ответов на заданные вопросы там нет.

x86_64:

gcc -std=c99 -O3 ./test005.c -o test005_O3.x64
time ./test005_O3.x64

real    0m3.108s
user    0m2.837s
sys     0m0.272s

gcc -std=c99 -O2 ./test005.c -o test005_O2.x64
time ./test005_O2.x64

real    0m3.231s
user    0m3.040s
sys     0m0.192s

e2k:

gcc -std=c99 -O2 ./test005.c -o test005_O2.e2k -mcpu=elbrus-2c+
time ./test005_O2.e2k 

real    0m14.844s
user    0m11.540s
sys     0m3.240s

gcc -std=c99 -O3 ./test005.c -o test005_O3.e2k -mcpu=elbrus-2c+
time ./test005_O3.e2k

real    0m15.612s
user    0m11.430s
sys     0m4.120s

Судя по всему эти тесты написаны под классическую архитектуру интелов и амд, и компилятор не может распараллелить код как надо.

Предлагаю придумать какие-то тесты, где всё было бы явно параллельно.

# generic options for gcc
CFLAGS = -s -static -ffast -fno-inline -mcpu=elbrus-2c+ -Wall -O3

./nbench 

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          239.03  :       6.13  :       2.01
STRING SORT         :          125.93  :      56.27  :       8.71
BITFIELD            :      3.3521e+07  :       5.75  :       1.20
FP EMULATION        :          14.362  :       6.89  :       1.59
FOURIER             :          9142.8  :      10.40  :       5.84
ASSIGNMENT          :          7.4754  :      28.45  :       7.38
IDEA                :          650.13  :       9.94  :       2.95
HUFFMAN             :          332.82  :       9.23  :       2.95
NEURAL NET          :          11.587  :      18.61  :       7.83
LU DECOMPOSITION    :          245.82  :      12.73  :       9.20
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.993
FLOATING-POINT INDEX: 13.508
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual MONOCUB E2C+DSP 500MHz
L2 Cache            : 
OS                  : Linux 2.6.33-elbrus.033.6.21.rt
C compiler          : gcc version 4.4.0 compatible.
libc                : libc-2.16.so
MEMORY INDEX        : 4.258
INTEGER INDEX       : 2.297
FLOATING-POINT INDEX: 7.492
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

./nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          2196.5  :      56.33  :      18.50
STRING SORT         :          1235.8  :     552.21  :      85.47
BITFIELD            :      6.8257e+08  :     117.08  :      24.46
FP EMULATION        :          733.08  :     351.76  :      81.17
FOURIER             :           53369  :      60.70  :      34.09
ASSIGNMENT          :          70.031  :     266.48  :      69.12
IDEA                :           13826  :     211.47  :      62.79
HUFFMAN             :          6143.7  :     170.37  :      54.40
NEURAL NET          :          126.12  :     202.61  :      85.22
LU DECOMPOSITION    :          3408.4  :     176.57  :     127.50
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 198.863
FLOATING-POINT INDEX: 129.487
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 4 CPU GenuineIntel Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz 800MHz
L2 Cache            : 6144 KB
OS                  : Linux 3.13.0-39-generic
C compiler          : gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 
libc                : 
MEMORY INDEX        : 52.473
INTEGER INDEX       : 47.590
FLOATING-POINT INDEX: 71.819
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Прочитай раз 20, пока мозг не начнёт соображать.

Ну вот, а товарищ peregrine нам загонял простыни. Тот же самый код на Си выполнился уже в 4 раза медленнее, а не 25, то есть процессор выполняет код эффективнее интела. Всё дело видимо в оптимизации С++ компилятора. Возможно загвоздка была в типе vector<bool>. Он у меня вызвал вопросы, что там внутри я доподлинно не знаю, потому переписал на Си.

Прочитай раз 20, пока мозг не начнёт соображать.

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

ОК, спасибо :) Жду еще больше тестов, но уже в понедельник смогу проверить.

Умеет DSP непосредственно выполнять программы, расположенные в памяти Эльбруса, и прозрачно писать туда же результаты?

Из документации:

В объектном файле коды mcore оформлены как секции данных e2k. Вся память mcore для данных маппируется в память процесса e2k, и коды e2k могут напрямую обращаться к данным mcore. Память mcore для кодов также маппируется в память e2k

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

Вся память mcore для данных маппируется в память процесса e2k, и коды e2k могут напрямую обращаться к данным mcore. Память mcore для кодов также маппируется в память e2k

Круто. А синхронизация? А ввод/вывод - я могу делать read прямо в память mcore, или read в промежуточный буфер, а потом memcpy в память mcore?

Будет время - попробую

Если попробуешь - отпишись.

Я попытался написать что-то, что может выполниться параллельно.

-std=c99
#include <stdio.h>
#include <stdlib.h> 
#include <time.h> 
int main()
{
	time_t start,finish;
        int n=1000000000;
	int a1,a2,a3,a4,a5,a6,a7,a8,a9,a10;
	int b1,b2,b3,b4,b5,b6,b7,b8,b9,b10;
	int c1,c2,c3,c4,c5,c6,c7,c8,c9,c10;
	a1=a2=a3=a4=a5=a6=a7=a8=a9=a10=0;
	time(&start);
	int i2=0;
	for (int i=1; i<=n; ++i)
	{
		i2=i*2;
		c1=i;c2=i;c3=i;c5=i;c6=i;c7=i;c8=i;c9=i;c10=i;
		b1=i2;b2=i2;b3=i2;b4=i2;b5=i2;b6=i2;b7=i2;b8=i2;b9=i2;b10=i2;
		a1+=b1+c1;
		a2+=b2+c2;
		a3+=b3-c3;
		a4+=b4-c4;
		a5+=b5*c5;
		a6+=b6*c6;
		a7+=b7/c7;
		a8+=b8/c8;
		a9+=b9^c9;
		a10+=b10^c10;
	}
	int sum = a1+a2+a3+a4+a5+a6+a7+a8+a9+a10;
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	a1=a2=a3=a4=a5=a6=a7=a8=a9=a10=0;
	i2=2;
	b1=i2;b2=i2;b3=i2;b4=i2;b5=i2;b6=i2;b7=i2;b8=i2;b9=i2;b10=i2;
	for (int i=1; i<=n; ++i)
	{
		c1=i;c2=i;c3=i;c5=i;c6=i;c7=i;c8=i;c9=i;c10=i;
		a1+=b1+c1;
		a2+=b2+c2;
		a3+=b3-c3;
		a4+=b4-c4;
		a5+=b5*c5;
		a6+=b6*c6;
		a7+=b7/c7;
		a8+=b8/c8;
		a9+=b9^c9;
		a10+=b10^c10;
	}
	int sum2 = a1+a2+a3+a4+a5+a6+a7+a8+a9+a10;
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	a1=a2=a3=a4=a5=a6=a7=a8=a9=a10=0;
	double fa1,fa2,fa3,fa4,fa5,fa6,fa7,fa8,fa9,fa10;
	fa1=fa2=fa3=fa4=fa5=fa6=fa7=fa8=fa9=fa10=0;
	double fb1,fb2,fb3,fb4,fb5,fb6,fb7,fb8,fb9,fb10;
	double fc1,fc2,fc3,fc4,fc5,fc6,fc7,fc8,fc9,fc10;
	double i3=1/2;
	fb1=i3;fb2=i3;fb3=i3;fb4=i3;fb5=i3;fb6=i3;fb7=i3;fb8=i3;fb9=i3;fb10=i3;
	for (int i=1; i<=n; ++i)
	{
		fc1=i;fc2=i;fc3=i;fc5=i;fc6=i;fc7=i;fc8=i;fc9=i;fc10=i;
		fa1+=fb1+fc1;
		fa2+=fb2+fc2;
		fa3+=fb3-fc3;
		fa4+=fb4-fc4;
		fa5+=fb5*fc5;
		fa6+=fb6*fc6;
		fa7+=fb7/fc7;
		fa8+=fb8/fc8;
		fa9+=fb9/fc9;
		fa10+=fb10/fc10;
	}
	double fsum = fa1+fa2+fa3+fa4+fa5+fa6+fa7+fa8+fa9+fa10;
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	fa1=fa2=fa3=fa4=fa5=fa6=fa7=fa8=fa9=fa10=0;
	for (int i=1; i<=n; ++i)
	{
		i3 = i;i3/=2.0;
		fc1=i;fc2=i;fc3=i;fc5=i;fc6=i;fc7=i;fc8=i;fc9=i;fc10=i;
		fb1=i3;fb2=i3;fb3=i3;fb4=i3;fb5=i3;fb6=i3;fb7=i3;fb8=i3;fb9=i3;fb10=i3;
		fa1+=fb1+fc1;
		fa2+=fb2+fc2;
		fa3+=fb3-fc3;
		fa4+=fb4-fc4;
		fa5+=fb5*fc5;
		fa6+=fb6*fc6;
		fa7+=fb7/fc7;
		fa8+=fb8/fc8;
		fa9+=fb9/fc9;
		fa10+=fb10/fc10;
	}
	double fsum2 = fa1+fa2+fa3+fa4+fa5+fa6+fa7+fa8+fa9+fa10;
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	double res = sum+sum2+fsum+fsum2;
	printf("END%.0f\n",res*0);
	return 0;
}

11
8
9
22
END0
real	0m49.641s
user	0m49.700s
sys	0m0.003s

Просьба указывать опции компилятора для x86, а то не ясно в связи с чем такая разница между двумя x86. У меня так:

gcc -std=c99 -O3 ./test006.c -o test006.x64
time ./test006.x64
4
3
4
4
END0

real    0m14.688s
user    0m14.698s
sys     0m0.000s

Но если сравнивать результат где 49 секунд, то эльбрус лишь в три раза дольше работал.

-bash-4.2$ gcc -std=c99 -O3 ./test006.c -o test006.e2k -mcpu=elbrus-2c+
-bash-4.2$ time ./test006.e2k
17
28
63
50
END0

real    2m37.721s
user    2m37.410s
sys     0m0.010s

Что-то не так.

Всё правильно, просто без -02. Чтобы выполнялось именно то, что я написал. В общем тупой подход не получился. При оптимизации на интел активно используется sse. Компилятор разобрался с этим делом.

ОК, тогда еще тесты можно, желательно указывая опции сборки (а они, такие как -O2/-O3 общие для эльбруса и x86). В понедельник узнаю статус документации, может она на общедоступном официальном их сайте лежит и я тогда ссылку на нее запощу, а если нет - к сожалению не могу, не хочу подставлять свою контору..

В принципе результат интересный. Видно что на местами менее двух раз разница без SSE. Выполнилось в 5 раз больше инструкций за такт.
11 17
8  28
9  63
22 50
Возможно стоит поработать с самым первым вариантом кода вычислявшего пи.

без оптимизации, без "-O"
#include <stdio.h>
#include <stdlib.h> 
#include <time.h> 
int main()
{
	time_t start,finish;
	long double sum,sum2,sum3,sum4;
	unsigned long long i,n;
	n = 1000000000;
	sum=sum2=sum3=sum4=0;
	time(&start);
	for (i=0;i<n;i++)
	{
		sum+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
	}
	sum=sum*4;
	printf("%.10Lf\n",sum);
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	sum=sum2=sum3=sum4=0;
	for (i=0;i<n;i++)
	{
		sum+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum2+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		
	}
	sum=(sum+sum2)*2;
	printf("%.10Lf",sum);
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	sum=sum2=sum3=sum4=0;
	for (i=0;i<n;i++)
	{
		sum+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum2+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum2+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
	}
	sum=sum+sum2+sum3+sum;
	printf("%.10Lf\n",sum);
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	time(&start);
	sum=sum2=sum3=sum4=0;
	for (i=0;i<n;i++)
	{
		sum+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum2+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum3+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
		sum4+=(1.0/(1.0+2.0*i))*((i%2==0) ? 1:(-1));
	}
	sum=sum+sum2+sum3+sum4;
	printf("%.10Lf\n",sum);
	time(&finish);
	printf("%.0f\n",difftime(finish,start));
	return 0;
}

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

Самое главное мы выяснили - ускорение есть. В новых моделях и частота в 2.6 раза выше и новые блоки добавились. Так что можно ожидать хорошего результата. В общем тест можно считать успешным. Благодарю вас за предоставленную возможность.

error: SSE register return with SSE disabled

По поводу документации

У тех, кто имеет доступ к Эльбрусу, должен быть и доступ к документации на ПО. Там есть такой документ «Руководство по оптимальному программированию для архитектуры Эльбрус». Рекомендую его к прочтению. Кроме него есть большой мануал по опциям оптимизации. И для полноты картины советую изучить документацию на библиотеку eml (в некотором смысле аналог интелевской MKL)

Да да, знаю :) А документация для избранных? У меня то она есть, она только тем кому разрешили доступ?

Пока нет на официальном сайте - думаю, что непубличная.

Увы, непубличные доки... Зайдите сюда http://www.mcst.ru/kontakty и там можно найти контакты. Запросить от имени своей организации «удаленный доступ по ssh», директор подпишет, отослать скан с корпоративной почты или факс на фирменном бланке.

Вот я лично чисто ради любопытства доступ получил - это было не сложно, и директор не возражал.

Все равно выглядит странно. Для AMD и Intel я не вижу процессоров в свободной продаже с 8+ ядрами и с техпроцессом ниже 32нм. А тут какбы рррраз и внезапно появился.

Что за ерунда?

http://www.citilink.ru/catalog/computers_and_notebooks/servers_and_net_equipm...

и далее по каталогу. Даже Core i7 уже с 8 ядрами есть

Надо еще этот процессор протестировать... ^_^

Тут интересно почему они закрыты и когда откроют. Чем больше будет информации тем меньше скепсиса.

Результаты тестов как БЕЗ оптимизаций, так и с O3, решил попробовать и с O3 заодно...

x86:

gcc -std=c99 ./test007.c -o test007.x64
time ./test007.x64
3.1415926526
8
3.141592652616
3.1415926526
25
3.1415926526
33

real    1m21.981s
user    1m21.937s
sys     0m0.096s

gcc -std=c99 -O3 ./test007.c -o test007_O3.x64
time ./test007_O3.x64
3.1415926526
10
3.141592652610
3.1415926526
10
3.1415926526
10

real    0m40.148s
user    0m40.172s
sys     0m0.004s

gcc -std=c99 ./test007.c -o test007.e2k -mcpu=elbrus-2c+
time ./test007.e2k
... тут текст утерян, но видно что долго
3.1415926526
402

real    18m39.185s
user    18m37.160s
sys     0m0.000s

gcc -std=c99 -fno-inline -ffast -O3 ./test007.c -o test007_O3.e2k -mcpu=elbrus-2c+
time ./test007_O3.e2k
3.1415926526
10
3.141592652610
3.1415926526
20
3.1415926526
19

real    0m58.272s
user    0m58.150s
sys     0m0.010s

Какие выводы можно сделать из результатов?

Для связности http://dz.livejournal.com/1009677.html

Можете напомнить, какая у Вас х86-я машина и версия gcc?