Свежие комментарии

Вот Агнер наш Фог пишет, что insertf128 - вообще два такта. А sub/mul - по одному, вестимо.

Когда я покупал разница на 8G модули была раза в полтора! 3200 все уже считались оверклокерскими, с радиаторами, красивой упаковкой, такое.

Именно этот код (не повезло ему) был вообще неправильным. Я перемерял правильно, с cvt, и результаты с точностью до статпогрешности те же. Ничего конверсия не стоит, не в ней дело.

А битовая магия выглядит так же только там вместо старших нулей всё пакуется константой 0x4700 во-первых и множитель другой во-вторых. Т.е. с точки зрения паковки и mul-sub всё в точногсти так же, только константы другие (и каст вместо конверсии).

Я про cast вообще не понял.
Или битовая магия (cast + sub), или cvttps_epi32
А одного каста - мало ж.

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

Сразу в 256 бит распаковывать можно только в AVX2 (_mm256_unpack{hi|lo}_epi{8|16}()) — или я не понимаю как. Если подскажешь буду благодарен.

ключи для avx "-O3 -mfpmath=sse -ffast-math -mavx" и код с v в начале, да:

  3c:   c5 e9 60 c4             vpunpcklbw %xmm4,%xmm2,%xmm0
  40:   c5 e9 68 d4             vpunpckhbw %xmm4,%xmm2,%xmm2
  44:   c5 f9 61 cb             vpunpcklwd %xmm3,%xmm0,%xmm1
  48:   c5 f9 69 fb             vpunpckhwd %xmm3,%xmm0,%xmm7
  4c:   c5 e9 61 c3             vpunpcklwd %xmm3,%xmm2,%xmm0
  50:   c5 e9 69 d3             vpunpckhwd %xmm3,%xmm2,%xmm2
  54:   c4 e3 75 18 cf 01       vinsertf128 $0x1,%xmm7,%ymm1,%ymm1
  5a:   c4 e3 7d 18 c2 01       vinsertf128 $0x1,%xmm2,%ymm0,%ymm0

9G/sec это семплы. Т.е. 9G байтов переаботано в 9G флоатов (36G байтов, соотвественно).

vzeroupper не делается, но там вообще распаковка адовая получается:
                const __m128i mem0 = _mm_load_si128((__m128i*)from);
               
                const __m128i tmp16l = _mm_unpacklo_epi8(mem0, zero);
                const __m128i tmp16h = _mm_unpackhi_epi8(mem0, zero);

                const __m128i tmp32ll = _mm_unpacklo_epi16(tmp16l, zero);
                const __m128i tmp32hl = _mm_unpackhi_epi16(tmp16l, zero);
               
                const __m128i tmp32lh = _mm_unpacklo_epi16(tmp16h, zero);
                const __m128i tmp32hh = _mm_unpackhi_epi16(tmp16h, zero);
               
                const __m256i tmp0 = _mm256_insertf128_si256(zero256, tmp32ll, 0);
                const __m256i tmp1 = _mm256_insertf128_si256(zero256, tmp32lh, 0);

                const __m256 in0 = _mm256_castsi256_ps(_mm256_insertf128_si256(tmp0, tmp32hl, 1));
                const __m256 in1 = _mm256_castsi256_ps(_mm256_insertf128_si256(tmp1, tmp32hh, 1));

                const __m256 out0 = _mm256_sub_ps(_mm256_mul_ps(in0, mul), del);
                const __m256 out1 = _mm256_sub_ps(_mm256_mul_ps(in1, mul), del);

                /* Store 16 floats */
                _mm256_store_ps(to,      out0);
                _mm256_store_ps(to +  8, out1);
               
                count -= 16;
                from += 16;
                to += 16;
Куда его тут? Да, я ещё интерливинг пытался тут вставить (ну типа как половина данных готова так с ними и работать а не групировать операции по смыслу как я тут скопипастил) и удвоить объём работы в одном проходе цикла (тоже как с группировкой по смыслу так и сгруппировкой по локальности данных) и то и другое даёт изменнеия в пределах статпогрещности. Да, в этом коде zero, zero256, mul, del — константы, понятно. Нули, множитель (512/255) и просто 1 в соотвествующих веторах.

Таблица! Это было первое, что я попытался сделать. Это медленней в 2-3 раза чем следующий самый медленный вариант!

Я тут пытаюсь нащупать лучший способ сделать из массива байтов (т.е. целых чисел в диапазоне [0..255]) массив float'ов (32-ъх битных IEEE754) в диапазоне [-1.0..1.0] — т.е. с рескейлом и сдвигом. Смотрю я на варианты «что угодно», SSE4 (ведь нет уже живого железа без него? SSE3 это первый Core!), AVX1, AVX2+FMA (потому что, кажется, AVX2 без FMA3 не бывает). Смотрю на SkyLake (i7-6700K зажатый ровно на 40, что бы никакие трубобусты мне бенчмарки не пачкали). А, да, gcc 6.3.0 и clang 3.9.1 дают качественно одинаковые результаты. И нахожусь в некотором недоумении.

(1) Если разрешить -mavx2 -mfma3, то код писать вообще не надо. В смысле, тупой цикл по 1 элементу зараз на plain С с одним умножением и одним вычитанием даёт чуть больше 9G в секунду на 4GHz проце. Компилятор развернул и векторизовал ВСЁ. Я не смог написать руками лучше, хотя пытался раз 5. Мой лучший ручной результат с AVX2 — 8G в секунду.

(2) А со всем остальным лучше всего справляется ручной код не лезущий дальше SSE2. Ну, простенький, несколько анпэков, конверт, мул-суб, всё.

Что меня удивляет (кроме ума компилятора): что, например, с AVX всё равно лучше SSE2. Т.е. пока у нас нет FMA и, главное, _mm256_unpack{hi|lo}_epi{8|16}, от 256-битных регистров тут толку нет.

Это я что-то не так делаю? Ну не верю я, что такая типовая на вид задача не может выиграть от AVX, только от AVX2 :)

И, кстати, какова твоя статистика (есть ли она у тебя) с какого SSE можно начинать что бы уже никого по сути не обидеть?

Жаловаться не на что, но, вот, есть хотелка (пока вы с ориентацией воюете ещё): можно ли сделать одноразовый (как экспокоррекция при выключенном XMP) поворот (ну и зеркало до кучи)? Бывает, нужно повернуть фото для анализа и приходится включать запись XMP, чтобы воспользоваться этими функциями. Или не одноразовый, а "до закрытия" или "до перехода в другой фолдер" хранить в памяти.

Пятый. Шансов, я думаю, мало.

А мну это все настолько достало как-то раз, что я купил две 19" PDUшки, отболгарил от ненужных 19" органайзеров уши и приболтовал все это величие к стене за столом так, что его не видно и я как бы в домике. Жена может теперь невозбранно шарить шваброй в святая святых, правда, почему-то делает это как-то с опаской, видимо рефлекс наработался :)

будете уже третьим. Первый - уволок сегодня примерять (ему тут улицу перейти), если не войдет ему в стол - вернет.

Заманчиво...!

/странно видеть паутину из проводов (хотя мне тоже не удаётся поддерживать порядок "за столом" дольше двух недель (за полгода))/

Но мысль-то понятная?
Главное, чтобы всё железо было "ready", а не "sleep".
Да оно будет жрать ресурсы и электричество даже когда вы ушли в магазин (за "добавкой"), зато повторяемость гарантирована.
:-D