https://github.com/novacoin-project/novacoin/commit/749faf6d4decb3b364cc981060fd4a26dab82df8
Дабы впредь не было недоразумений с кавычками.
Topic: NovaCoin (scrypt PoW + PoS hybrid) [self-mod] - page 123. (Read 744453 times)
Навели на дельную мысль насчет справки...
https://github.com/novacoin-project/novacoin/commit/749faf6d4decb3b364cc981060fd4a26dab82df8
Дабы впредь не было недоразумений с кавычками.
https://github.com/novacoin-project/novacoin/commit/749faf6d4decb3b364cc981060fd4a26dab82df8
Дабы впредь не было недоразумений с кавычками.
Собственно, в MSVC проекте никто ничего не менял, как я вижу. Так что если не вешается намеренно флаг USE_ASM, то должен собираться как и раньше без вопросов. Если добавили такой флаг в проект, то конечно же не соберет, потому как gnu специфичным моментам компилятор microsoft'а не обучен.
Попробую собрать, как доберусь до железки со студией.
Попробую собрать, как доберусь до железки со студией.
Попробовал собрать для x64.. но размеры NovacoinD и Novacoin-QT совпали до байта. А для MSVC не нужно что-нибудь поменять - как для других сборок makefile?
Думаю, что сегодня или завтра этот вопрос уже будет решен. 
Вопрос решен, попутно исправлено несколько мелочей. Однако же, заметной разницы в плане производительности по крайней мере на x86 точно не наблюдается. Видимо, с pshufb переворачивание шло достаточно быстро для того, чтобы всё упиралось в собственно вычисление sha256 хэша Сборки будут где-то ближе к полуночи.
Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. 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. Перечитал оригинальное сообщение и понял, что невольно ввел в заблуждение. Повторюсь, речь идет о небольшой кривизне в конкретной реализации, а не об алгоритме хэширования в целом.
EDIT: Добавил ремарки в изначальное сообщение.
EDIT2: Думаю, что сегодня или завтра этот вопрос уже будет решен.
Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. 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 ( ) );
}
Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.
Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову данной реализации функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. sha256(sha256(x)) на практике в этом случае выглядит как-то вроде sha256(swap(sha256(x))).
На это переворачивание тратится время, небольшое и потому несущественное при вычислении одного хэша. Однако в ситуации, в которой мы считаем 4 хэша за раз, последовательное переворачивание всех элементов стало бы узким местом. Поэтому используем pshufb, чтобы переворачивать результаты пачками по 4 значения вместо того, чтобы делать это по одному элементу последовательно.
К сожалению, это всё верно только для x86/x86_64, на ARM это узкое место сохраняется и потому более чем двухкратный прирост от недавних оптимизаций вряд ли возможен несмотря на то, что есть возможность считать 4 хэша за раз. В принципе, там есть SIMD набор инструкций под названием NEON, в котором могут быть подобные команды для пакетного переворачивания. Но я понятия не имею, что там и к чему, надо читать даташиты.
Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.
Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)Quote from: Balthazar
30s это все-таки долго, а сколько было раньше?
До последних обновлений (но когда scaninput уже стала многопоточной) - 85 или 95 секунд, забыл уже. Я ещё прикинул, что где-то втрое ускорилось. То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация Железка Платформа Кол-во потоков Время
SSE4 Core 2 Quad Q9550 2.833GHz Win64 4 30s
SSE4 функции в клиенте нет, то было просто для экспериментов. Сейчас клиент имеет SSE2, AVX и XOP 4way реализации SHA256. Опционально ещё включается обработка промежуточных результатов с помощью SSSE3, если доступно. Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.Реализация Железка Платформа Кол-во потоков Время
SSE4 Core 2 Quad Q9550 2.833GHz Win64 4 30s
30s это все-таки долго, а сколько было раньше?
Что означает "Network Weight" в кошельке? Значение постоянно меняется
Оценка совокупной мощности всех PoS майнеров, в монето-днях-в-секунду. 
Что означает "Network Weight" в кошельке? Значение постоянно меняется
То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация Железка Платформа Кол-во потоков Время
SSE4 Core 2 Quad Q9550 2.833GHz Win64 4 30s
SSE2 + SSSE3 26s
Upd: 30s было, видимо, под небольшой нагрузкой (проц ещё чем-то был занят).
Реализация Железка Платформа Кол-во потоков Время
SSE2 + SSSE3 26s
Upd: 30s было, видимо, под небольшой нагрузкой (проц ещё чем-то был занят).
Дополню таблицу MSVC сборка + yasm
Команда:
Реализация Железка Платформа Кол-во потоков Время
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 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
Видимо, у Sempron нет SSSE3.
Кроме того, на тех же AMD K8 часто бывает, что использование SSE2 не дает толком никакого прироста, так что на чем-то вроде Celeron D351 выросло бы где-то в 2.5-3 раза как раз. Пожалели транзисторов на SIMD блоки, очевидно, жаль что они только в K10 додумались это хоть как-то исправить.
Собственно, именно отсутствие оптимизированных под SSE2 приложений и выручило AMD в своё время, ведь многие современные приложения на AMD K8 работают медленнее, чем на их современниках от Intel, хотя для приложений того времени всё было совсем наоборот. Впрочем, по современным меркам и там и там они тормозят так, что разница в 2-3 раза не играет уже никакой роли.
Кроме того, на тех же AMD K8 часто бывает, что использование SSE2 не дает толком никакого прироста, так что на чем-то вроде Celeron D351 выросло бы где-то в 2.5-3 раза как раз. Пожалели транзисторов на SIMD блоки, очевидно, жаль что они только в K10 додумались это хоть как-то исправить.
Собственно, именно отсутствие оптимизированных под SSE2 приложений и выручило AMD в своё время, ведь многие современные приложения на AMD K8 работают медленнее, чем на их современниках от Intel, хотя для приложений того времени всё было совсем наоборот. Впрочем, по современным меркам и там и там они тормозят так, что разница в 2-3 раза не играет уже никакой роли.
Последние оптимизации scaninput касаются только многоядерных процессоров? Потому как на Core2 (4 ядра) скорость утроилась, а на одноядерном Sempron осталась без изменений (хотя тоже SSE2 поддерживает).
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 бит,
Реагирует, просто сложность там задана строго как число с плавающей точкой, что некорректно. Т.е. если вместо 2000 написать 2000.0, тогда поймет и не будет подставлять текущую.
Будет исправлено в ближайшем билде.
Будет исправлено в ближайшем билде.
Скачал билд 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"
}
]
< 1s
AVX 4way Xeon E5 2658v2 @ 2.4 GHz Win64 20 2s
Так и до психологической отметки 1s недалеко.
Обновленный билд:
http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-50.7z/download
Так и до психологической отметки 1s недалеко.
Обновленный билд:
http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-50.7z/download
Заменил реализацию на вытащенную из cpuminer и слегка допиленную:
SSE2 4way Core i7 970 @ 3.2 GHz Linux64 12 3s
Что-то как-то 4way не особенно чуствуется в сравнении с честно-одноблочным интеловским алгоритмом.
Ну да ладно, более универсальна хотя бы. На днях, возможно, обзаведусь Haswell или чем-то более новым и займусь дальнейшим допиливанием.
SSE2 4way Core i7 970 @ 3.2 GHz Linux64 12 3s
Что-то как-то 4way не особенно чуствуется в сравнении с честно-одноблочным интеловским алгоритмом.
Ну да ладно, более универсальна хотя бы. На днях, возможно, обзаведусь Haswell или чем-то более новым и займусь дальнейшим допиливанием.
Jump to: