Немного слов про умные компиляторы

Проверил gcc 7.1 https://godbolt.org/g/LzmHpU

Тоже не видит, правда если выставить sse2 или выше, то тогда использует SIMD.

Так что способность компиляторов выдавать оптимальный код сильно преувеличена...

А что он выдаёт, если -mfma написать?

https://godbolt.org/g/E3rfoq Почему компилятор 2017 года, с опциями максимальной скорости и с поддержкой инструкций AVX2 не видит, что сумму можно посчитать используя SIMD?

Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25017 for x86

На винфак.

gcc 7.1 https://godbolt.org/g/LzmHpU

-march=native и выравняй указатели.

Тоже векторизует, но по другому. У gcc проблема только с mmx.

Насчёт MSVC, вот что нашёл: https://msdn.microsoft.com/en-us/library/jj658585.aspx#BKMK_ReasonCode130x При компиляции с /Qvec-report:2 выдаёт:

info C5002: loop not vectorized due to reason 'Loop body contains no—or very little—computation'.

Вот нашёл свежую статью по поводу автовекторизации: http://informatik.uibk.ac.at/en/teaching/smb/theses/457.pdf Возможно кому-нибудь будет полезно чтобы понимать что могут сегодняшние компиляторы, а чего не могут.

Оффтопик, но мне в этой функции непонятно, почему такие ограничения для n, можно пояснить?

	if ((n < 16) or (n > 16777216) or ((n bitand 0x0f) != 0))
	{
		return false;
	}

Почему непременно количество байт в этом векторе должно быть кратно 64-м (32 бита=4 байта * 16)?

Это из-за того, что SIMD только с кусками по 64 байта работает что ли?

Откуда 64? Нет, там 16 байт должно быть кратно.

n bitand 0x0f <=> n & 0x0f <=> n & 15

Да SIMD работают кусками, MMX по 8 байт, SSE по 16 байт, AVX по 32 байта, AVX512 по 64 байта.

Я сам пока разбираюсь по этой книге: https://www.amazon.com/Modern-X86-Assembly-Language-Programming/dp/1484200659...

(можно в интернете найти pdf версию на торрентах)

и с помощью этого сайта: https://gcc.godbolt.org/

Почему компилятор 2017 года

Наверное потому, что маздайский компилятор не является компилятором? Это убогий мусор. Представляешь?

не видит, что сумму можно посчитать используя SIMD?

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

Вот пример ассемблерного кода, который в 3 раза более быстрый чем сгенерированный компилятором, и это лишь используя mmx инструкции. https://pastebin.com/b1yiSwNx

Это мусор, а не код.

Мусор не мусор. А для обучения я считаю отличный код. По крайней мере при том что я изучаю ассемблер недели две, я всё понял. А то что он обгоняет gcc 7.1(с учётом на ограничения используемых команд, так как этот код из темы про mmx) и MSVC 2017 делает его не таким плохим.

Выкатывай бенчмарки.

А для обучения я считаю отличный код.

В параллельной вселенной.

По крайней мере при том что я изучаю ассемблер недели две, я всё понял.

Ничего ты не понял. Ассемблер это про то, что не может сделать компилятор. Ничего из этого ты не понял и не сделал.

А то что он обгоняет gcc 7.1(с учётом на ограничения используемых команд, так как этот код из темы про mmx)

Что за «ограничения» такие? ммх протухло 20лет назад - к чему это сейчас?

MSVC 2017 делает его не таким плохим.

Как я уже говорил - это не компилятор.

А так - выкатывай бенчи. Посмотрим.

MSVC 2017 делает его не таким плохим.

Как я уже говорил - это не компилятор.

А что же это? Скажи, не томи.

Так у вас вектор состоит из int32, а - их количество. Если требуете n and h0F == 0, то количество обрабатываемых циклом данных кратно 4 байта * 16, а не 1 байт * 16. Верно?

Там массив из uint8_t.

Вот весь проект этого примера, там есть мои результаты и есть отдельно exe файл, если нет желания компилировать. У меня AMD FX 8300 4.0Ghz https://yadi.sk/d/8-I5rl6H3Kyipx

Предлагаю зарепортить баг в GCC.

ты сначала скажи, как ты сам компилятор собирал. у него туева хуча опций и половина может быть отключена.
а во-вторых, вот ликбез по оптимизации. написано про Intel, но суть не меняется: https://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints