Каковы характеристики истощения RDRAND на Ivy Bridge?

После ознакомления с Руководством по внедрению программного обеспечения Intel Digital Random Generator (DRNG) у меня есть несколько вопросов о том, что происходит с внутренним состоянием генератора, когда RDRAND вызывается. К сожалению, ответы, кажется, не в руководстве.

  1. Согласно руководству, внутри DRNG есть четыре 128-битных буфера, которые обслуживают случайные биты для RDRAND осушать. RDRAND сама предоставит 16, 32 или 64 бита случайных данных в зависимости от ширины регистра назначения:

    rdrand ax   ; put 16 random bits in ax
    rdrand eax  ; put 32 random bits in eax
    rdrand rax  ; put 64 random bits in rax
    

    Будет ли использование больших регистров назначения быстрее очищать эти 128-битные буферы? Например, если мне нужно только 2 бита случайности, стоит ли мне использовать 16-битный регистр вместо 64-битного? Будет ли это иметь какое-либо значение для пропускной способности DRNG? Я хотел бы избежать потребления больше случайности, чем необходимо.

  2. Гид говорит, что флаг переноса будет установлен после RDRAND выполняет:

    CF = 1   Destination register valid. Non-zero random value
             available at time of execution. Result placed in register.
    CF = 0   Destination register all zeros. Random value not available
             at time of execution. May be retried.
    

    Что значит "недоступно"? Могут ли случайные данные быть недоступны, потому что RDRAND вызовы исчерпали эти 128-битные буферы слишком быстро? Или недоступно означает, что DRNG не проходит проверки работоспособности и не может генерировать какие-либо новые данные? По сути, я пытаюсь понять, может ли CF=0 произойти только потому, что буферы (временно) пусты RDRAND вызывается.

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

Спасибо!

3 ответа

Решение

Часть 1. Имеет ли смысл тянуть 16, 32 или 64 бита?

Нет.

На Ivy Bridge ядра ЦП протягивают 64 бит по внутренним каналам связи к DRNG, независимо от размера регистра назначения. Так что если вы читаете 32 бита, он вытягивает 64 бита и выбрасывает верхнюю половину. Если вы читаете 16 бит, он вытягивает 64 и выбрасывает верхнюю 3/4.

Это не описано в инструкции по эксплуатации, поскольку может не соответствовать действительности в будущих продуктах. Может быть разработан чип, который хранит и использует неиспользуемые части 64-битного слова. Тем не менее, сегодня нет существенной необходимости делать это.

Для обеспечения максимальной пропускной способности наиболее эффективной стратегией является использование параллельных потоков. Это связано с тем, что в иерархии шин на кристалле существует параллелизм. Большую часть времени для обучения занимает транзитное время через автобусы. Параллельное выполнение этого транзита приведет к линейному увеличению пропускной способности в зависимости от количества потоков, вплоть до максимума 800 МБ / с. Второе - использовать 64-битные RdRand, потому что они получают больше данных за инструкцию.

Часть 2. Что на самом деле означает CF=0?

Это означает, что "случайные данные не доступны". Это связано с тем, что подробности того, почему он не может получить число, недоступны ядру ЦП, если он не отключится и не прочитает больше регистров, что он не собирается делать, поскольку он ничего не может сделать с информацией.

Если бы вы высосали из буфера вывода DRNG всухую, вы получили бы недостаточное значение (CF=0), но вы могли ожидать, что следующий RdRand будет успешным, потому что DRNG быстр.

Если произошел сбой DRNG (например, в источнике энтропии появился транзистор, и он больше не был случайным), то онлайн-тесты работоспособности обнаружат это и отключат DRNG. Тогда все ваши вызовы RdRand приведут к CF=0.

Однако на Ivy Bridge вы не сможете опустошить буфер. DRNG немного быстрее, чем шина, к которой он подключен. Эффект вытягивания большего количества данных за единицу времени (с параллельными потоками) будет заключаться в увеличении времени выполнения каждого отдельного RdRand, поскольку конкуренция на шине заставляет команды ждать в очереди на локальной шине DRNG. Вы никогда не сможете тянуть так быстро, что DRNG опустится. Вы асимптотически достигнете 800 МБ / с.

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

То, что останется верным, так это то, что базовый цикл (попробуйте до 10 раз, затем сообщите о сбое вверх по стеку), приведенный в руководстве для разработчиков программного обеспечения, будет продолжать работать в будущих продуктах, потому что мы заявили, что он будет и так Мы разработаем все будущие продукты, чтобы встретить это.

Поэтому нет, CF=0 не может произойти, потому что "буферы (временно) пусты при вызове RDRAND" на Ivy Bridge, но это может произойти на будущем кремнии, поэтому разработайте свое программное обеспечение, чтобы справиться с ним.

Не читайте ничего в 4*128-битный FIFO на выходе DRNG. Это, конечно, есть (я положил это там), но это не то, что имеет программный видимый эффект. Логика DRNG не дает данных гладко. Иногда он планирует другие вещи, такие как пересев или кондиционирование, в соответствии со спецификацией SP800-90. Таким образом, поток данных под нагрузкой является нерегулярным.

Длина буфера 4 была выбрана, потому что при 800 МБ / с (скорость локальной шины) 4 достаточно глубокий, чтобы предотвратить потерю памяти при максимальной нагрузке при заданном отклонении в наихудшем случае, поэтому постоянная плавная скорость составляет 800 МБ. / с поставка без прерывания на выходе.

Если бы присоединенная шина была медленнее, буфер был бы короче, потому что более короткого буфера было бы достаточно, чтобы предотвратить переполнение.

Относительно 2: http://download.intel.com/products/processor/manual/253665.pdf, 7.3.17

CF указывает, что спрос на случайные данные превышает пропускную способность DRNG.

Относительно 1:

Если вас беспокоит производительность, почему бы не прочитать 64-битное случайное значение из DRNG, тогда вы можете прочитать 2 бита из этих 32 раз, прежде чем вам понадобится снова вызвать инструкцию. Вам не нужно вызывать новый rdrand каждый раз, когда вам нужны биты.

Другие вопросы по тегам