Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Честно говоря, меня во всем этом проекте заинтересовали не сами биткоины (ну их, эти денежные суррогаты ))), но скорее математическая сторона алгоритма SHA256.Вероятно вот это зря. Зная, что именно требуется вычислить, вероятно, можно сам требуемый результат использовать для ускорения вычислений.
Компилирую, для FPGA Cyclone IV и вижу, что эта штука займет 30,103 логических элементов.А работает это быстрее, чем конвейерная реализация? И насколько?
Конечно не быстрее. Pipeline конечно нужно делать.
Просто с pipeline невозможно точно сказать сколько ресурсов нужно для реальных вычислений. Поэтому я его временно удалил, чтобы понять и оценить «стоимость» каждого бита результата.
Просто с pipeline невозможно точно сказать сколько ресурсов нужно для реальных вычислений. Поэтому я его временно удалил, чтобы понять и оценить «стоимость» каждого бита результата.
Здравствуйте, nckma! Вы еще занимаетесь FPGA и в частности хеш суммами или забросили? Как с вами можно пообщаться на эту тему?
В реальности это вообще не будет работать, вернее будет, но при условии длительного сохранения данных на входе. Огромная куча комбинаторной логики — ад для любого более-менее серьезного проекта: гонки сигналов и прочие прелести обеспечены.
Возможно, я не прав, но быстрее четко и правильно организованного конвейера на ПЛИС не будет ничего.
Возможно, я не прав, но быстрее четко и правильно организованного конвейера на ПЛИС не будет ничего.
Интересный анализ. Однако, если учесть, что каждое следующее вычисление энергетически в сумме с предыдущим будет стоить выше полноценного вычисления всего хэша, одиночная экономия на первой проверке может перекрыться последующими затратами.
Хабр торт
Вот уже показалась призрачная экономия энергии. Я считаю, что каждая логическая функция кушает энергию.
На сколько я помню, логическая функция кушает два типа энергии — статическую и динамическую.
Если функция ничего не делает (не происходит переключений, например, N тактов стоит константа), то она не потребляет динамику.
В Quartus есть Power Estimator, который показывает сколько будет потреблять прошивка энергии при заданном количестве (частоте) переключений, тактовой частоты и пр. Возможно, для качественной оценки уменьшения количества энергии, надо поиграться с этой тулзой и посмотреть на результаты.
Забавно, как вы реверс-инжинирингом выясняете те физические ограничения вычислений криптографической хеширующей функции, которые туда изначально и намеренно заложены авторами этой функции математически. По-сути, если бы вам удалось сэкономить на операциях, вычисляя только часть хеша, то вы бы дискредитировали качество самой криптографической функции (что, конечно, вряд ли у вас получится).
Если же вы хотите только сэкономить энергию, а не найти уязвимость в криптографическом алгоритме с помощью оптимизатора в компиляторе, то стОит обратить внимание на модель так называемых обратимых вычислений.
Если же вы хотите только сэкономить энергию, а не найти уязвимость в криптографическом алгоритме с помощью оптимизатора в компиляторе, то стОит обратить внимание на модель так называемых обратимых вычислений.
спасибо за крутую статью!
Latency vs space стандартное противоречие в реализации. На самом деле самое оптимальное решение находится в интервале т.к. нужно обеспечить самую большую вычислительную мощность на единицу площади. посмотрите исходники кандидатов SHA3. Там предоставляются сразу как минимум 2 реализации (min latency, min space, не помню есть ли 3-я max hash/s/space).
По поводу первых 32 бит, которые должны быть нулями. Можно и нужно считать их сразу все вместе. Получится, во-первых, меньше логики, во-вторых, в ПЛИСах уже есть DSP блоки, на которые можно повесить дорогое сложение вместо драгоценных ячеек (в ASIC'ах всё по-другому).
По поводу параллельного вычисления нескольких хэшей. Уже много лет как есть midstate. Все обертки для майнеров уже загружают в любые (CPU/GPU/FPGA/ASIC) майнеры не оригинал, с которого нужно взять sha256, а промежуточный результат (состояние всех блоков в SHA256 на определённом раунде), который уже вычислен на процессоре.
Про самый главный трюк, который реально позволяет выжимать всё из кремния не рассказали. Вместо того, чтобы увеличивать частоту можно наоборот уменьшать её, но при этом увеличивать набор логики между защелками. Тогда можно сэкономить на «слишком хороших» задержках, которые всегда оказываются при слишком большом дроблении. Например, совместив 8 раундов в одном такте мы скорее всего выровняем фронт лучше, чем для одного раунда на такт.
С ASIC можно пойти дальше. Нам же никто не мешает использовать кристалл по-больше. Следовательно мы можем к всему прочему понизить вольтаж, но увеличить количество элементов на кристалле. Сбойные блоки можно отключить при тестировании. Остальные не влияют, т.к. задача майнинга специфична, можно перепроверять на надёжном процессоре. Итого потребление то же, а производительность больше. Понятное дело понижать получится до определённого предела и где-то будет оптимум.
// Скорее всего я здесь допустил много неточностей в терминах и некоторых формулировках, но примерная суть должна быть ясна.
По поводу первых 32 бит, которые должны быть нулями. Можно и нужно считать их сразу все вместе. Получится, во-первых, меньше логики, во-вторых, в ПЛИСах уже есть DSP блоки, на которые можно повесить дорогое сложение вместо драгоценных ячеек (в ASIC'ах всё по-другому).
По поводу параллельного вычисления нескольких хэшей. Уже много лет как есть midstate. Все обертки для майнеров уже загружают в любые (CPU/GPU/FPGA/ASIC) майнеры не оригинал, с которого нужно взять sha256, а промежуточный результат (состояние всех блоков в SHA256 на определённом раунде), который уже вычислен на процессоре.
Про самый главный трюк, который реально позволяет выжимать всё из кремния не рассказали. Вместо того, чтобы увеличивать частоту можно наоборот уменьшать её, но при этом увеличивать набор логики между защелками. Тогда можно сэкономить на «слишком хороших» задержках, которые всегда оказываются при слишком большом дроблении. Например, совместив 8 раундов в одном такте мы скорее всего выровняем фронт лучше, чем для одного раунда на такт.
С ASIC можно пойти дальше. Нам же никто не мешает использовать кристалл по-больше. Следовательно мы можем к всему прочему понизить вольтаж, но увеличить количество элементов на кристалле. Сбойные блоки можно отключить при тестировании. Остальные не влияют, т.к. задача майнинга специфична, можно перепроверять на надёжном процессоре. Итого потребление то же, а производительность больше. Понятное дело понижать получится до определённого предела и где-то будет оптимум.
// Скорее всего я здесь допустил много неточностей в терминах и некоторых формулировках, но примерная суть должна быть ясна.
Если на диаграмме развернуть результаты в интервалах 0-31, 32-63, ..., то останется всего один скачек функции. Это имеет какое-либо значение?
А на какой максимальной частоте может работать такой проект не оценивали? Квартус выдает оценку. Чтобы ножки не влияли на оценку, можно вставить регистры на входе и выходе.
Вообще, переходя к конвейеру растет площадь — добавляются регистры и, может быть, логика. Но и растет максимальная рабочая частота (правда она сильно зависит от типа и поколения ПЛИС). Не очевидно где будет оптимум. Продолжайте исследования!
Вообще, переходя к конвейеру растет площадь — добавляются регистры и, может быть, логика. Но и растет максимальная рабочая частота (правда она сильно зависит от типа и поколения ПЛИС). Не очевидно где будет оптимум. Продолжайте исследования!
Я начинал так с sha256 бороться:
habr.com/post/423839
habr.com/post/423839
От строки
"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
правильный SHA-256 хеш
"a8ae6e6ee929abea3afcfc5258c8ccd6f85273e0d4626d26c7279f3250f77c8e"
а не
"ab4e426e7b531a4b9c0625ba9279fac84746969912100d154a5566e912a20756"
https://sopkit.github.io/Encoding/sha256.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Можно ли вычислять биткоины быстрее, проще или легче?