SSE: хранилище маски влияет на байты, которые были замаскированы - PullRequest
0 голосов
/ 24 февраля 2020

В справочнике по встроенным функциям Intel есть несколько разделов, которые позволяют хранить части широкого регистра. Я имею в виду _mm_maskstore, _mm_mask_store и _mm_mask_compressstoreu, как.

Вопрос в том, можно ли их использовать, если моему потоку не принадлежит часть кешлайна, где бы он ни находился, или он прошел конец текущей страницы?

Пример:

struct S {
  std::int16_t write_here[10];
  std::atomic<std::int16_t> other_thread_can_use_this;
};

Можно ли написать с одним хранилищем simd в write_here? Или он может испортить данные из other_thread_can_use_this (например, загрузив их и записав обратно)?

1 Ответ

1 голос
/ 24 февраля 2020

Они делают подавление ошибок и поддерживают правильность; См. При использовании регистра маски с загрузкой и запоминанием AVX-512 возникает ли ошибка при недопустимом доступе к замаскированным элементам?

Определенно, не делает non-atomi c RMW.

Все это относится к SSE (медленному хранилищу NT) maskmovdqu, относительно эффективному маскированию меча / qword AVX vmaskmovps/pd и vpmaskmovd/q, а также хранилища с масками AVX512.

Но это может быть медленным.

AVX vmaskmov хранилища с полной маскировкой для страниц только для чтения очень медленно, принимая помощь микрокода для каждой инструкции. (Так что очень плохо работайте в al oop над массивом, делая if(a[i] == x) a[i] = y;, если не требуется никаких изменений, и страница была "чистой" и COW отображена на нулевую страницу.)

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

Опять же, архитектурно, это не влияет на байты, которые были замаскированы, только возможная производительность.

...