Каковы характеристики истощения RDRAND на Ivy Bridge?
рассмотрев Intel Digital Random Number Generator (DRNG) руководство по реализации программного обеспечения, у меня есть несколько вопросов о том, что происходит с внутренним состоянием генератора, когда RDRAND
вызывается. К сожалению, ответов, похоже, нет в руководстве.
-
согласно руководству, внутри 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? Я бы хотел избежать употребления большего количества случайностей, чем необходимо.
-
руководство говорит флаг переноса будет установлен после
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
вызывается.
Примечание: у меня обзор ответы to этот вопрос о пропускной способности и задержке RDRAND, но я ищу другую информацию.
спасибо!
3 ответов
часть 1. Имеет ли значение вытягивание 16, 32 или 64 бит?
нет.
на Ivy Bridge ядра CPU вытягивают 64 бита по внутренним коммуникационным каналам к DRNG, независимо от размера регистра назначения. Поэтому, если Вы читаете 32 бита, он тянет 64 бита и выбрасывает верхнюю половину. Если Вы читаете 16 бит, он тянет 64 и выбрасывает верхние 3/4.
Это не описано в документации инструкции, потому что это не может продолжайтесь быть истинны в будущих продуктах. Чип может быть разработан, который скрывает и использует неиспользуемые части 64-битного слова. Однако сегодня для этого нет существенного императива производительности.
для самой высокой пропускной способности наиболее эффективной стратегией является вытягивание из параллельных потоков. Это потому, что существует параллелизм в иерархии шины на чипе. Большая часть времени для инструкции-это время транзита через автобусы. Выполнение этого транзита параллельно выход линейное увеличение пропускной способности с количеством потоков, до максимума 800MBytes / s. Второе-использовать 64-битные RdRands, потому что они получают больше данных за инструкцию.
часть 2. Что означает CF=0 на самом деле?
Это означает "случайные данные недоступны". Это связано с тем, что подробности о том, почему он не может получить номер, недоступны ядру процессора без его выключения и чтения дополнительных регистров, чего он не собирается делать, потому что есть это никак не связано с информацией.
Если вы высосали выходной буфер DRNG dry, вы получите underflow (CF=0), но вы можете ожидать, что следующий RdRand преуспеет, потому что DRNG быстрый.
Если DRNG не удалось (например, транзистор выскочил в источнике энтропии, и он больше не был случайным), то онлайн-тесты на работоспособность обнаружат это и выключат DRNG. Тогда все ваши вызовы RdRand дадут CF=0.
однако на мосту Плюща, вы будете не сможет переполнение буфера. DRNG немного быстрее, чем автобус, к которому он прикреплен. Эффект вытягивания большего количества данных за единицу времени (с параллельными потоками) будет заключаться в увеличении времени выполнения каждого отдельного RdRand, поскольку конфликт на шине заставляет инструкции ждать в очереди на локальной шине DRNG. Вы никогда не можете тянуть так быстро, что DRNG будет underflow. Вы асимптотически достигнете 800 Мбайт / с.
Это также не описано в документация, потому что это может не сохраниться в будущих продуктах. Мы можем предусмотреть продукты где шины более быстры и сердечники более быстро и DRNG смогли бы быть underflowed. Эти вещи еще не известны, поэтому мы не можем претендовать на них.
что останется верным, так это то, что базовый цикл (попробуйте до 10 раз, а затем сообщите о сбое в стеке), указанный в руководстве по программному обеспечению, будет продолжать работать в будущих продуктах, потому что мы сделали утверждение, что он будет и так мы проектируем все будущие продукты для того чтобы встретить это.
поэтому нет, CF=0 не может произойти, потому что" буферы оказываются (временно) пустыми, когда вызывается RDRAND " на Ivy Bridge, но это может произойти на будущем кремнии, поэтому разработайте свое программное обеспечение, чтобы справиться.
ничего не считывайте в 4 * 128 бит FIFO на выходе DRNG. Это, конечно, есть (я положил его там), но это не то, что имеет видимый эффект программного обеспечения. Логика DRNG не производит данные гладко. Он когда-то планирует другие вещи, такие как пересев или кондиционирование, в соответствии со спецификацией SP800-90. Таким образом, поток данных под нагрузкой нерегулярен.
длину буфера 4 было выбрано потому, что в 800MBytes/с (скорость локально автобус) 4 достаточно глубоко чтобы предотвратить underflow при вытягивании с максимальной скоростью, учитывая наихудший вариант планирования экскурсии, поэтому есть постоянная, плавная поставка 800MByte/s без перерыва в выходе.
Если присоединенная шина была медленнее, буфер был бы короче, потому что более короткого буфера было бы достаточно, чтобы предотвратить утечку.
по поводу 2: http://download.intel.com/products/processor/manual/253665.pdf, 7.3.17
CF указывает, что спрос на случайные данные превышает пропускную способность DRNG.
в отношении 1:
Если вас беспокоит производительность, почему бы не прочитать 64-битное случайное значение из DRNG, то вы можете прочитать 2bits из этого 32 раза, прежде чем вам нужно снова вызвать инструкцию. Вам не нужно вызывать новый rdrand каждый раз, когда вам нужно вдребезги.