Author

Topic: NovaCoin (scrypt PoW + PoS hybrid) [self-mod] - page 123. (Read 744450 times)

legendary
Activity: 3108
Merit: 1359
Навели на дельную мысль насчет справки...

https://github.com/novacoin-project/novacoin/commit/749faf6d4decb3b364cc981060fd4a26dab82df8

Дабы впредь не было недоразумений с кавычками. Smiley
legendary
Activity: 3108
Merit: 1359
Собственно, в MSVC проекте никто ничего не менял, как я вижу. Так что если не вешается намеренно флаг USE_ASM, то должен собираться как и раньше без вопросов. Если добавили такой флаг в проект, то конечно же не соберет, потому как gnu специфичным моментам компилятор microsoft'а не обучен.

Попробую собрать, как доберусь до железки со студией.
full member
Activity: 145
Merit: 103
 Попробовал собрать для x64.. но размеры NovacoinD и Novacoin-QT совпали до байта. А для MSVC не нужно что-нибудь поменять - как для других сборок makefile?
legendary
Activity: 3108
Merit: 1359
Думаю, что сегодня или завтра этот вопрос уже будет решен. Roll Eyes
Вопрос решен, попутно исправлено несколько мелочей. Однако же, заметной разницы в плане производительности по крайней мере на x86 точно не наблюдается. Видимо, с pshufb переворачивание шло достаточно быстро для того, чтобы всё упиралось в собственно вычисление sha256 хэша Smiley

Сборки будут где-то ближе к полуночи.
legendary
Activity: 3108
Merit: 1359
Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. sha256(sha256(x)) на практике выглядит как-то вроде sha256(swap(sha256(x))).

Чо-та ты гонишь про переворачивание.
Вот так реализовывается на Qt sha256d
Code:
  inline explicit MyKey32 ( const quint8* buf, const int len )
  {
    quint8 tmp [32];
    resize ( 32 );
    SHA256 ( SHA256 ( buf, len, tmp ), 32, ptr ( ) );
  }
Откуда тут переворачивание? Как раз то, что вычислилось в первом вызове - отдаем на вход второму вызову

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

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

P.S. Перечитал оригинальное сообщение и понял, что невольно ввел в заблуждение. Повторюсь, речь идет о небольшой кривизне в конкретной реализации, а не об алгоритме хэширования в целом. Wink

EDIT: Добавил ремарки в изначальное сообщение.
EDIT2: Думаю, что сегодня или завтра этот вопрос уже будет решен. Roll Eyes
legendary
Activity: 1260
Merit: 1019
Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. sha256(sha256(x)) на практике выглядит как-то вроде sha256(swap(sha256(x))).

Чо-та ты гонишь про переворачивание.
Вот так реализовывается на Qt sha256d
Code:
  inline explicit MyKey32 ( const quint8* buf, const int len )
  {
    quint8 tmp [32];
    resize ( 32 );
    SHA256 ( SHA256 ( buf, len, tmp ), 32, ptr ( ) );
  }
Откуда тут переворачивание? Как раз то, что вычислилось в первом вызове - отдаем на вход второму вызову
legendary
Activity: 3108
Merit: 1359
Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.
Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)
SSSE3 для pshufb как раз и нужно. Собственно, непосредственно в хэшировании участия не принимает, но помогает.

Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову данной реализации функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. sha256(sha256(x)) на практике в этом случае выглядит как-то вроде sha256(swap(sha256(x))).

На это переворачивание тратится время, небольшое и потому несущественное при вычислении одного хэша. Однако в ситуации, в которой мы считаем 4 хэша за раз, последовательное переворачивание всех элементов стало бы узким местом. Поэтому используем pshufb, чтобы переворачивать результаты пачками по 4 значения вместо того, чтобы делать это по одному элементу последовательно.

К сожалению, это всё верно только для x86/x86_64, на ARM это узкое место сохраняется и потому более чем двухкратный прирост от недавних оптимизаций вряд ли возможен несмотря на то, что есть возможность считать 4 хэша за раз. В принципе, там есть SIMD набор инструкций под названием NEON, в котором могут быть подобные команды для пакетного переворачивания. Но я понятия не имею, что там и к чему, надо читать даташиты. Roll Eyes
full member
Activity: 145
Merit: 103
Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.
Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)
Quote from: Balthazar
30s это все-таки долго, а сколько было раньше?
До последних обновлений (но когда scaninput уже стала многопоточной) - 85 или 95 секунд, забыл уже. Я ещё прикинул, что где-то втрое ускорилось.
legendary
Activity: 3108
Merit: 1359
То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация             Железка                         Платформа          Кол-во потоков       Время
SSE4            Core 2 Quad Q9550 2.833GHz            Win64                     4                    30s
SSE4 функции в клиенте нет, то было просто для экспериментов. Сейчас клиент имеет SSE2, AVX и XOP 4way реализации SHA256. Опционально ещё включается обработка промежуточных результатов с помощью SSSE3, если доступно. Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.

30s это все-таки долго, а сколько было раньше?

Что означает "Network Weight" в кошельке? Значение постоянно меняется
Оценка совокупной мощности всех PoS майнеров, в монето-днях-в-секунду.
legendary
Activity: 1753
Merit: 1007
Что означает "Network Weight" в кошельке? Значение постоянно меняется
full member
Activity: 145
Merit: 103
То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация             Железка                         Платформа          Кол-во потоков       Время
SSE4            Core 2 Quad Q9550 2.833GHz            Win64                     4                    30s
SSE2 + SSSE3                                                                                                      26s
Upd: 30s было, видимо, под небольшой нагрузкой (проц ещё чем-то был занят).
legendary
Activity: 3108
Merit: 1359
Дополню таблицу Smiley MSVC сборка + yasm

Команда:

Code:
scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "days" : 365}'

Реализация  Железка                                Платформа          Кол-во потоков       Время
Generic         Xeon E5410 @ 2.33 GHz        Win64                  4                      30s
SSE4            Xeon E5410 @ 2.33 GHz        Win64                  4                      15s


AVX             Core i5 2520M @ 2.5 GHz          Win64               4            8s
legendary
Activity: 3108
Merit: 1359
Видимо, у Sempron нет SSSE3.

Кроме того, на тех же AMD K8 часто бывает, что использование SSE2 не дает толком никакого прироста, так что на чем-то вроде Celeron D351 выросло бы где-то в 2.5-3 раза как раз. Пожалели транзисторов на SIMD блоки, очевидно, жаль что они только в K10 додумались это хоть как-то исправить.

Собственно, именно отсутствие оптимизированных под SSE2 приложений и выручило AMD в своё время, ведь многие современные приложения на AMD K8 работают медленнее, чем на их современниках от Intel, хотя для приложений того времени всё было совсем наоборот. Впрочем, по современным меркам и там и там они тормозят так, что разница в 2-3 раза не играет уже никакой роли.
full member
Activity: 145
Merit: 103
Последние оптимизации scaninput касаются только многоядерных процессоров? Потому как на Core2 (4 ядра) скорость утроилась, а на одноядерном Sempron осталась без изменений (хотя тоже SSE2 поддерживает).
legendary
Activity: 3108
Merit: 1359
SSE2 4way          Core i7 970 @ 3.2 GHz        Linux64                  12                      3s
Благодаря pshufb теперь 2s.

Реагирует, просто сложность там задана строго как число с плавающей точкой, что некорректно. Т.е. если вместо 2000  написать 2000.0, тогда поймет и не будет подставлять текущую.

Будет исправлено в ближайшем билде.
Исправлено.

http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-53.7z/download

Пока сборки только 64 бит, 32 бит будет позжетеперь в архиве есть и 32 бит сборки.
legendary
Activity: 3108
Merit: 1359
Реагирует, просто сложность там задана строго как число с плавающей точкой, что некорректно. Т.е. если вместо 2000  написать 2000.0, тогда поймет и не будет подставлять текущую.

Будет исправлено в ближайшем билде.
legendary
Activity: 1200
Merit: 1021
Скачал билд novacoin-test-v0.5.4-50 (предыдущие не пробовал). По-моему, scaninput не реагирует на изменение сложности:
Code:
scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "vout" : [0, 1], "difficulty" : 2000, "days" : 90}'

[
{
"nout" : 0,
"hash" : "00000e6a31812f69b87977d77ad723648a076850021da3c1959c67bd637d2378",
"time" : "2015-12-27 09:49:15 UTC"
},
{
"nout" : 1,
"hash" : "00000aa904facb147ed5187ced7e9de1c184085751765635caa174c0de856cdd",
"time" : "2015-12-04 16:43:30 UTC"
},
{
"nout" : 1,
"hash" : "00000db40c00bd71f90ff4d47c1954456893fdc487203ee7f3ff2af5ecb55160",
"time" : "2016-01-06 06:41:22 UTC"
}
]
FAN
legendary
Activity: 2688
Merit: 1020
< 1s
 Smiley
legendary
Activity: 3108
Merit: 1359
AVX 4way          Xeon E5 2658v2 @ 2.4 GHz        Win64                  20                      2s

Так и до психологической отметки 1s недалеко. Smiley

Обновленный билд:

http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-50.7z/download
legendary
Activity: 3108
Merit: 1359
Заменил реализацию на вытащенную из cpuminer и слегка допиленную:

SSE2 4way          Core i7 970 @ 3.2 GHz        Linux64                  12                      3s

Что-то как-то 4way не особенно чуствуется в сравнении с честно-одноблочным интеловским алгоритмом. Cheesy

Ну да ладно, более универсальна хотя бы. На днях, возможно, обзаведусь Haswell или чем-то более новым и займусь дальнейшим допиливанием.
Jump to: