Встроенные и постоянные переменные SIMD / состояние

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

поэтому главный вопрос, который у меня есть, - это использование встроенных типов данных SIMD, таких как __m256. И чтобы перейти к сути, мой вопрос заключается в том, чтобы делать такие вещи:

class PersistentObject
{
     ...
private:
     std::vector<__m256, AlignedAlloc<__m256, 32>> data;
};

это грубо, приемлемо, будет ли это срабатывать компиляторы, когда дело доходит до создания наиболее эффективного кода? Вот что меня сейчас смущает. Я на неопытном уровне, когда у меня есть точка доступа и исчерпаны все другие немедленные варианты, я даю SIMD внутреннеприсущему выстрел и всегда ищу, чтобы отказаться от моих изменений, если они не улучшают производительность (и я отступил так много изменений, связанных с SIMD).

но этот вопрос и путаница у меня есть о хранении SIMD внутренних типов настойчиво также заставили меня поймите, что я действительно не понимаю, как эти внутренние компоненты работают на фундаментальном уровне компилятора. Мой разум хочет думать о __m256 как абстрактный YMM регистрация (не обязательно выделенный). Это начинает щелкать со мной, когда я вижу инструкции по загрузке и хранению. Я думаю о них как о подсказках для компилятора для выполнения его распределения регистра.

и мне не нужно было думать об этом больше, чем раньше, потому что я всегда использовал типы SIMD временным способом: _mm256_load_ps к __m256, выполните некоторые операции, сохраните результаты обратно в 32-битный spfp 256-битный выровненный массив float[8]. Мне сошло с рук думать о __m256 как регистр YMM.

абстрактный регистр YMM?

но недавно я реализовывал структуру данных, которая пытается вращаться вокруг обработки SIMD (простой, представляющий кучу векторов в SoA-моде), и здесь становится удобно, если я могу просто работать преимущественно с __m256 без постоянно загрузка из массива поплавков и сохранение результатов после. И в некоторых быстрых тестах MSVC, по крайней мере, кажется, испускает соответствующие инструкции, отображающие мои внутренние компоненты в сборку (наряду с правильными выровненными нагрузками и хранилищами, когда я получаю доступ к данным из вектора). Но это нарушает мою концептуальную модель мышления __m256 как абстрактное YMM register, потому что хранение этих вещей постоянно подразумевает что-то вроде регулярной переменной, но в этот момент что происходит с нагрузками / movs а магазины?

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

извинения, если это глупый вопрос! Я действительно промокла насквозь от этой дряни.

Подробнее

большое спасибо за полезные комментарии до сих пор! Наверное, мне стоит поделиться. еще несколько деталей, чтобы сделать мой вопрос менее расплывчато. В основном я пытаюсь создать структуру данных, которая немного больше, чем коллекция векторов, хранящихся в форме SoA:

xxxxxxxx....
yyyyyyyy....
zzzzzzzz....

... и главным образом с намерением быть использованным для горячих точек где критические петли имеют последовательную картину доступа. Но в то же время некритические пути выполнения могут захотеть случайным образом получить доступ к 5-му 3-вектору в форме AoS (x/y/z), и в этот момент мы неизбежно делаем скалярный доступ (который прекрасно, если это не так эффективно, поскольку они не являются критическими путями).

в этом одном специфическом случае мне было бы намного удобнее с точки зрения реализации просто настойчиво хранить и работать с __m256 вместо float*. Это помешало бы мне посыпать много вертикального петлевого кода с _mm_loads* и _mm_stores* потому что общий случай в этом сценарии (как с точки зрения критического выполнения, так и основной части кода) реализуется с помощью встроенных SIMD. Но я не уверен, что это разумная практика над просто резервированием __m256 для кратковременных временных данных, локальных для некоторой функции, чтобы загрузить некоторые поплавки в __m256, выполнить некоторые операции и сохранить результаты, как я обычно делал в прошлом. Это было бы немного удобнее, но я немного обеспокоен тем, что этот удобный тип реализации может задушить некоторые оптимизаторы (хотя я еще не нашел, что это так). И если они не спотыкаются об оптимизаторы, то как я был думать об этих типах данных было немного не так все это время.

Итак, в этом случае, это похоже на то, что если это прекрасно делать, и наши оптимизаторы справляются с этим блестяще все время, то я смущен, потому что то, как я думал об этом материале и думал, что нам нужны эти явные _mm_load и _mm_store в кратковременных контекстах (локальных для функции, т. е.), чтобы помочь нашим оптимизаторам, все было неправильно! И это расстраивает меня, что это работает нормально, потому что я этого не делал думаю, это должно было сработать! :- D

ответы

если это поможет, у меня есть около 200k LOC написано именно так. IOW, I относитесь к типу SIMD как к первоклассному гражданину. Все нормально. Компилятор ручками их не иначе, чем любой другой примитивный тип. Так есть нет никаких проблем с этим.

оптимизаторы не настолько хлипкие. Они сохраняют верность в разумные интерпретации стандартов C / C++. Нагрузка / магазин внутренние компоненты действительно не нужны, если вам не нужны специальные (не выровненный, не темпоральный, в маске, так далее...)

тем не менее, пожалуйста, не стесняйтесь писать свои собственные ответы. Чем больше информации, тем веселее! Я действительно надеюсь улучшить это фундаментальное понимание того, как писать код SIMD с большей уверенностью, так как я нахожусь на этапе, когда я сомневаюсь во всем и все еще сомневаюсь в себе.

Отражает

еще раз большое спасибо всем! Теперь я чувствую себя намного яснее и увереннее. проектирование кода, построенного вокруг SIMD. По какой-то причине я был чрезвычайно подозрителен к оптимизатору только для встроенных SIMD, думая, что мне нужно написать свой код на самом низком уровне и иметь эти нагрузки и магазины как можно более локальными в ограниченной области функций. Я думаю, что некоторые из моих суеверий произошли от написания SIMD intrinsics первоначально против старых компиляторов почти пару десятилетий назад, и, возможно, тогда оптимизаторам, возможно, нужна была дополнительная помощь, или, может быть, я просто был иррационально суеверен все это время. Я смотрел на это так, как люди смотрели на компиляторы C в 80-х годах, помещая такие вещи, как register намеки здесь и там.