Здравствуйте, Cyberax, Вы писали:

C>Intel C++ — уже много лет параллелит. Там при максимальном уровне
C>предупреждений даже выдается гордая надпись: "xx.cpp(yyy) : (col. nn)
C>remark: LOOP WAS VECTORIZED."

C>В GCC 4.1 тоже векторизация появилась, в 4.2 ее заметно расширят.

Гордая надпись выдается только для циклов типа:
[/code]
for(int i=0;i<n;++i) { a[i]=b[i]; }

Чтобы параллелить такие циклы много ума не надо.
Однако уже для кода:
[/code]
float a[4],b[4];
void f() {
  a[0]=b[0];
  a[1]=b[1];
  a[2]=b[2];
  a[3]=b[3];
}
[ccode]
генерится четыре скалярные инструкции, вместо одной векторной!!! (в версии 9.0)
Вот когда компиляторы будут в состоянии заменять код сортировки пузырьком,
на код параллельной сортирующей сети Бэтчера, или хотябы
максимум из 128 элементов заменять на векторный максимум и цикл:
[/code]
char a[16],b[16];
short s=0;
for(int i=0;i<16;++i) { s+=abs(a[i]-b[i]); }
[ccode]
компилить в:
[asm]
movdqa xmm0,xmmword ptr [a]
psadbw xmm0,xmmword ptr [b]
movd eax,xmm0
...
[/asm]
тогда я соглашусь что параллелит.
В ближайшие 20 лет здесь ничего не изменится, как почти ничего не изменилось за прошлые 15.
Единственное что умеет делать Intel C++, это неплохо предсказывать вероятности переходов в циклах.
А чтобы делать то, о чем я написал выше нужен принципиально иной подход к построению оптимизаторов,
которого не видно даже на горизонте.

C>Вот пример такого "ассемблера":
C>[code]
C>uniform sampler2D coeffsABC;
C>uniform sampler2D coeffsDEF;

C>void main( void )
C>{
C>   // Get the texture coordinates
C>   vec2 st = gl_TexCoord[0].st;

C>   // Read the polynomial coefficients from the textures
C>   vec3 ABC = vec3(texture2D(coeffsABC, st)-0.50196); // 8-bit signed,
C>   vec3 DEF = vec3(texture2D(coeffsDEF, st)-0.50196); // 128/255 -> 0.0

C>   // Construct vectors with powers of u and v
C>   vec3 uv1 = vec3(fract(st*32.0), 1.0);
C>   vec3 u2uvv2 = uv1.xxy * uv1.xyy;

C>   // Calculate the pixel size in (u,v) space for antialiasing
C>   vec4 duvdxy = 32.0*vec4(dFdx(st), dFdy(st));
C>   float stepwidth = 0.5*length(duvdxy);

C>   // Make a checkered pattern to show texel borders
C>   //vec2 cst = floor(mod(st*32.0, 2.0));
C>   //float c = mod(dot(cst, vec2(1.0, 1.0)), 2.0);

C>   // Evaluate the implicit curve polynomial
C>   float f = dot(ABC,u2uvv2) + dot(DEF,uv1);

C>   // Compute the magnitude of the gradient of the polynomial
C>   vec2 gradf = vec2(dot(uv1, vec3(2.0*ABC.x,ABC.y,DEF.x)),
C>     dot(uv1, vec3(2.0*ABC.z,ABC.y,DEF.y)));
C>   float g = inversesqrt(dot(gradf, gradf));

C>   // Set the color to be black when P<=0.0, white otherwise
C>   float a = smoothstep(-stepwidth, stepwidth, f*g);
C>   gl_FragColor = vec4(a, a, a, 1.0);
C>}
C>

Если имелось в виду, что это типа не ассемблер, тогда вот это:

#include <emmintrin.h>

char *p;
__m128i u,v,w1,w2,t;
...
w1=_mm_shufflehi_epi16(u,15);
w2=_mm_shufflelo_epi16(v,7);

_mm_maskmoveu_si128(w1,w2,p);

t=_mm_cmpunord_pd(w1,w2);
...

есть истинный код на чистом C++

Здравствуйте, Cyberax, Вы писали:

C>Whistler wrote:
>> СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько
>> выросли, что намного себе дороже оптимизировать (сколько у тебя весит
>> программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или
>> 50 метров — всем по барабану).
C>В данный момент у меня на компьютере 42 процесса. Большая часть занимает
C>около мегабайта (общий объем занятой памяти 442Мб), всего памяти 1Гб.

C>Если бы программы занимали хотя бы в два раза больше места — у меня
C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.

Вы неправильно поняли, Вам пытались сказать, что если бы у вас процессы эти занимали всего 200 мегов вместо 400, то Вы бы не порадовались, ибо стоимость разработки этих же 42 процессов на АСМе была бы раз в 10 выше, и софт был бы дико дорогой. Получается, изготовление железа стало проще, чем создание софта.

Ник wrote:
> C>Если бы программы занимали хотя бы в два раза больше места — у меня
> C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
> Вы неправильно поняли, Вам пытались сказать, что если бы у вас процессы
> эти занимали всего 200 мегов вместо 400, то Вы бы не порадовались, ибо
> стоимость разработки этих же 42 процессов на АСМе была бы раз в 10 выше,
> и софт был бы дико дорогой.
Во-первых, стоимость софта к стоимости его разработки отношение имеет
весьма непрямое. Во-вторых, если писать на хорошо оптимизированном С/C++
— то коэффициент будет не "10", а сильно меньше.

Здравствуйте, Whistler, Вы писали:
W>
3. Маниакальная борьба за производительность — оптимизации до байта.

W> СЕГОДНЯ НЕ АКТУАЛЬНО: Вычислительные мощности компьютеров настолько выросли, что намного себе дороже оптимизировать (сколько у тебя весит программа 2 мегабайта или 100 мегабайт, сколько жрет памяти — 1 метр или 50 метров — всем по барабану). А вот глючность никуда не девалась — 20 лет назад бесила пользователей и сегодня пользователей бесит.

Программа — да. А вот узкое место, из-за которого все тормозит (У Вас ВСЕ летает? Я Вам завидую, у меня тормоза сплошные везде) нужно оптимизировать насколько это возможно. Да, код формочки глупо обычно оптимизировать. А код кодека, или поисковика по большому объему данных — очень и очень желательно.

W>Вывод: если проблемы производительности ушли сами собой по течению времени, за чем же ими заниматься?

А они правда ушли? Я чего-то не замечаю.

W>Не лучше потраченное на это время уделить вопросам стабильности?

Стабильность — это хорошо. Но и скорость нужно.

Здравствуйте, Cyberax, Вы писали:

C>Если бы программы занимали хотя бы в два раза больше места — у меня
C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
К сожалению, обычно экономия памяти при помощи кодирования на ассемблере обычно какая-то не такая.
Вот отказ от GC ещё может на это как-то повлиять, а переход на асм совсем не про то.
Скорее надо структуры данных и алгоритмы оптимизировать, а не процедуры на асме кропать

Erop wrote:
> C>Если бы программы занимали хотя бы в два раза больше места — у меня
> C>памяти бы не хватило. И при этом ничего особого на компьютере не стоит.
> К сожалению, обычно экономия памяти при помощи кодирования на ассемблере
> обычно какая-то не такая.
> Вот отказ от GC ещё может на это как-то повлиять, а переход на асм
> совсем не про то.
Вообще-то и говорилось в русле managed+GC vs unmanaged