Как быстро выяснилось обновленный клиент не работает, ни с моим core, ни в оригинале. Я пробовал компилировать клиента несколькими компиляторами (VC++ 6.0, Intel C++ 5.0, VC++ 7.0), результат всегда одинаковый - получаемый клиент не понимает формата буферов, на "flush" просто молчит, а на "fetch" ругается "Input buffers full (or projects are closed)". Кроме этого, готовый клиент не создает файл-буфера для выключенных проектов, а откомпилированный создает для всех. Еще раз повторюсь, все это происходит как с моими правками так и без них.
Насколько я понимаю все дело в исходниках, которые доступны на www.distrubute.net. Это просто не те исходные тексты (или не совсем те), из которых компилируется оригинальный клиент. Как минимум видны различие в версиях: в исходных текстах "2.8015-469-GTR-01041616", а в готовом клиенте "2.8015-469-GTR-01051420". Короче, очевидно что дело именно в исходных текстах. Разбираться что там не так - самая глупая трата времени, наверное ребята из dnet просто "поправили" исходные тексты чтобы их меньше докучали всякие хацкеры с кривыми пакетами и руками...
На днях попробовал оптимизировать subj. Можно сказать что получилось, новый core работает примерно на 1.11% быстрее, сделан на основе существующего "RG class 6", немного изменен порядок инструкций...
Для точного замера performance я использовал внутренний счетчик пентиума (rdtsc). Тест встроенный в клиента подтверждает результаты, точнее говоря, просто видно что новый core немного быстрее.
Предыдущее улучшение сделано 1999/07/13 by Mario Weilguni <mweilguni@sime.com> на +0.45%, так что еще +1.11% это не мало.
В dnet я пока ничего не писал, core нужно протестировать, а исходники "причесать". Кроме этого, возможно что мне удастся улучшить результат :-)
Любопытно узнать какие будут результаты на других CPU.
Bench проверялся только под W2K, у меня нет рядом других ОС.
Удачи !
P.S. для админов:
Я несколько минут назад писал сюда подобное сообщение, но позже его не увидел. Теперь вот не пойму кто глючит, то ли я, то ли связь, то ли форум. Если получится две копии - убейте одну, либо этот "хвостик".
Новый core RC5 для Pentium Pro/II/III/Celeron на P4. Странно... 04.12.01 20:47 Автор: RedAndr UfaTeam <Андрей Рыжков> Статус: Member
dnetc v2.8015-469-GTR-01051420 for Win32 (WindowsNT 5.0).
[Dec 04 17:25:30 UTC] Automatic processor type detection found
an Intel Pentium 4 processor.
[Dec 04 17:25:30 UTC] RC5: using core #0 (RG/BRF class 5).
[Dec 04 17:25:49 UTC] RC5: Benchmark for core #0 (RG/BRF class 5)
0.00:00:17.36 [1,451,623 keys/sec]
[Dec 04 17:25:49 UTC] RC5: using core #1 (RG class 3/4).
[Dec 04 17:26:09 UTC] RC5: Benchmark for core #1 (RG class 3/4)
0.00:00:16.74 [1,856,760 keys/sec]
[Dec 04 17:26:09 UTC] RC5: using core #2 (RG class 6).
[Dec 04 17:26:28 UTC] RC5: Benchmark for core #2 (RG class 6)
0.00:00:17.03 [1,956,019 keys/sec]
[Dec 04 17:26:28 UTC] RC5: using core #3 (RG re-pair I).
[Dec 04 17:26:48 UTC] RC5: Benchmark for core #3 (RG re-pair I)
0.00:00:17.16 [1,810,948 keys/sec]
[Dec 04 17:26:48 UTC] RC5: using core #4 (RG RISC-rotate I).
[Dec 04 17:27:07 UTC] RC5: Benchmark for core #4 (RG RISC-rotate I)
0.00:00:16.33 [1,769,750 keys/sec]
[Dec 04 17:27:07 UTC] RC5: using core #5 (RG RISC-rotate II).
[Dec 04 17:27:26 UTC] RC5: Benchmark for core #5 (RG RISC-rotate II)
0.00:00:17.18 [1,939,278 keys/sec]
[Dec 04 17:27:26 UTC] RC5: using core #6 (RG/HB re-pair II).
[Dec 04 17:27:46 UTC] RC5: Benchmark for core #6 (RG/HB re-pair II)
0.00:00:16.72 [1,726,333 keys/sec]
[Dec 04 17:27:46 UTC] RC5: using core #7 (RG/BRF self-mod).
[Dec 04 17:28:05 UTC] RC5: Benchmark for core #7 (RG/BRF self-mod)
0.00:00:16.72 [457,565 keys/sec]
[Dec 04 17:28:05 UTC] RC5: using core #8 (NB class 7).
[Dec 04 17:28:24 UTC] RC5: Benchmark for core #8 (NB class 7)
0.00:00:16.73 [2,134,610 keys/sec]
[Dec 04 17:28:24 UTC] RC5: using core #9 (jasonp P5/MMX).
[Dec 04 17:28:43 UTC] RC5: Benchmark for core #9 (jasonp P5/MMX)
0.00:00:17.24 [451,931 keys/sec]
Cводная таблица:
(NB class 7) 2,134,610
1522.47 RG class 6 (RG class 6) 1,956,019
1531.50 RG RISC-rotate II (RG RISC-rotate II)1,939,278
1604.46 RG 386/486 (RG class 3/4) 1,856,760
1639.52 RG re-pair I (RG re-pair I) 1,810,948
1684.04 RG RISC-rotate I (RG RISC-rotate I) 1,769,750
1725.77 RG/HB re-pair II (RG/HB re-pair II) 1,726,333
2050.38 NB class 7 (RG/BRF class 5) 1,451,623
2063.53 RG/BRF class 5 (RG/BRF self-mod) 457,565
13151.13 JP P5/MMX (jasonp P5/MMX) 451,931
Довольно странный, для меня, результат. Так как по днету выходит "NB class 7" самый быстрый, у тебя же он где-то в конце. "RG class 6" - нормально, в обеих тестах на втором месте (я не учитываю твои). "RG RISC-rotate II" - тоже в обеих на третьим. Ну и так далее, более менее совпадают, вполоть до "jasonp P5/MMX" на последнем. Так что, здесь нечто непонятное. Поэтому мне как то сумнительно первое место твоего ядра. Надо такой вопрос провентелировать! ;)
И кстати, нельзя ль, клиента под P4 соптимизировать, ну там SSE2 используя?
Re: Много тут...04.12.01 23:48 Автор: leo <Леонид Юрьев> Статус: Elderman
Для засечки времени я использую внутренний счетчик тактов процессора. Это самый объективный железный метод (по крайней мере до P4), естественно при правильном использовании. И в моем случае все по правилам, пока еще никто не ругался (исходники теста доступны на сайте).
Точность замера при икуственном тесте выше чем при тесте из клиента. Поэтому если сделать ну скажем 10-25 контрольных замеров, то результат должен подтвердиться.
Но с P4 результат на самом деле дикий, на один прогон расходуется 1522 тактов, это более чем в два раза хуже чем на P-III (701 такт). Видимо на P-4 такты посчитанные процессором не отражают реальных затрат времени. С другой стороны у меня каждый из двух P-III/450 выдает по 1.268 Mkey/sec, если пересчитать по частоте, то у тебя на P4 должно быть ~3.8 Mkey/sec, а на деле в два раза хуже, что в принципе соответствует моему тесту:
1.268 * 701 / 450 == 1,975.26 ~~ 1,977.52 == 1.956 * 1516 / 1500
Я сейчас восстановил доступность обновленного клиента, он кривой но тест в нем работает. Попробуй сделать замеры из него, ради чистоты эксперимента. Может в реальном dnet-клиенте работает другой NB Class 7, и это все объяснит ?
P4 у меня пока нет, и я этим вопросом не занимался. Может кто что сразу скажет ?
Еще к тебе просьба, на сайте (моем) валяется похожий тест скорости RC6. Прогони его ради интереса. Разница в коде в том, что при подборе ключей RC5 тормоза возникают в основном из-за ожидания готовности предыдущего результата, а в шифровании RC6 из-за занятости "executive". Будет интересно что получиться.
И к стати, "NB Class 7" сделан для K7, а для P4 скорее всего можно улучшить, и намного.
SSE2 - тоже вариант, но у меня пока P-III :-(
Удачи.
Re: Много тут...05.12.01 20:15 Автор: RedAndr UfaTeam <Андрей Рыжков> Статус: Member
> Я сейчас восстановил доступность обновленного клиента, он > кривой но тест в нем работает. Попробуй сделать замеры из > него, ради чистоты эксперимента. Может в реальном > dnet-клиенте работает другой NB Class 7, и это все объяснит ?
Примерно, в пределах погрешности совпадает с первой. Твоё ядро чуть похуже родного исходного (RG_class_6).
> P4 у меня пока нет, и я этим вопросом не занимался. Может > кто что сразу скажет ?
Есть мнение, что в П4 всякие сдвиги и ротейты криво реализованы, в результате чего их выполнение, в отличие скажем от П3, занимает больше одного такта. Необходимо бы проверить это. Хотя я видел информацию про это на самом интеле. Есть какая тестовая програмка, чтоб замерять время выполнения тех или иных инструкций?
> Еще к тебе просьба, на сайте (моем) валяется похожий тест > скорости RC6. Прогони его ради интереса. Разница в коде в > том, что при подборе ключей RC5 тормоза возникают в > основном из-за ожидания готовности предыдущего результата, > а в шифровании RC6 из-за занятости "executive". Будет > интересно что получиться.
Ок, смотри:
RC6-32/20/b implementation v1.02 (by Leo Yuriev) performance test
Sources available on http://leo-yuriev.narod.ru
data size 8 blocks (128 bytes):
null() take the 1076 CPU clocks, 134.50 per block
rc6_encode() take the 6596 CPU clocks, 824.50 per block
rc6_decode() take the 7052 CPU clocks, 881.50 per block
clear rc6_encode() time is 5520 CPU clocks, 690.00 per block
clear rc6_decode() time is 5976 CPU clocks, 747.00 per block
data size 16 blocks (256 bytes):
null() take the 1144 CPU clocks, 71.50 per block
rc6_encode() take the 12140 CPU clocks, 758.75 per block
rc6_decode() take the 13060 CPU clocks, 816.25 per block
clear rc6_encode() time is 10996 CPU clocks, 687.25 per block
clear rc6_decode() time is 11916 CPU clocks, 744.75 per block
data size 32 blocks (512 bytes):
null() take the 1240 CPU clocks, 38.75 per block
rc6_encode() take the 23248 CPU clocks, 726.50 per block
rc6_decode() take the 25104 CPU clocks, 784.50 per block
clear rc6_encode() time is 22008 CPU clocks, 687.75 per block
clear rc6_decode() time is 23864 CPU clocks, 745.75 per block
data size 64 blocks (1024 bytes):
null() take the 1432 CPU clocks, 22.38 per block
rc6_encode() take the 45424 CPU clocks, 709.75 per block
rc6_decode() take the 49136 CPU clocks, 767.75 per block
clear rc6_encode() time is 43992 CPU clocks, 687.38 per block
clear rc6_decode() time is 47704 CPU clocks, 745.38 per block
Что то не очень :(
> И к стати, "NB Class 7" сделан для K7, а для P4 скорее > всего можно улучшить, и намного.
Я тоже на это надеялся, но время идёт, процессор П4 уже давно продаётся, а что то никто то ли не может, то ли не хочет этом заниматься. Даже странно, учитывая сколько уже имеется на руках П4...
Постепенно прихожу к неутешительному выводу о фиговости П4.
> SSE2 - тоже вариант, но у меня пока P-III :-(
Может тогда просто SSE?
Re: Много тут...05.12.01 23:32 Автор: leo <Леонид Юрьев> Статус: Elderman Отредактировано 05.12.01 23:42 Количество правок: 1
Из наших тестов мне не ясно только одно - как код, который расходует больше тактов, в итоге дает больше keys/sec ?
> Есть мнение, что в П4 всякие сдвиги и ротейты криво > реализованы, в результате чего их выполнение, в отличие > скажем от П3, занимает больше одного такта. Необходимо бы > проверить это. Хотя я видел информацию про это на самом > интеле. Есть какая тестовая програмка, чтоб замерять время > выполнения тех или иных инструкций?
Померить в принципе можно, но это будут достаточно абстрактные цифры. В потоке, команды выполняются совершенно с другими временными затратами. Еще есть V-Tune - софт от Intel, который в принципе позволяет посмотреть, что реально (или около того) получается при выполнении. Если интересно, можешь скачать его с Intel, evaluation на месяц раздается всем желающим, но он большой...
> Ок, смотри: > > data size 64 blocks (1024 bytes): > null() take the 1432 CPU clocks, 22.38 per block > rc6_encode() take the 45424 CPU clocks, 709.75 per block > rc6_decode() take the 49136 CPU clocks, 767.75 per block > clear rc6_encode() time is 43992 CPU clocks, 687.38 per > block > clear rc6_decode() time is 47704 CPU clocks, 745.38 per > block > > Что то не очень :( Очень и очень плохо... На P3 получается ~200 так, вместо ~710.
Вот для сравнения (у меня):
data size 64 blocks (1024 bytes):
null() take the 603 CPU clocks, 9.42 per block
rc6_encode() take the 14628 CPU clocks, 228.56 per block
rc6_decode() take the 14880 CPU clocks, 232.50 per block
clear rc6_encode() time is 14025 CPU clocks, 219.14 per block
clear rc6_decode() time is 14277 CPU clocks, 223.08 per block
---
Для меня самое важное, то что пустой цикл на P4 тратит в ТРОЕ больше чем на P3. Как не крути, а это - показатель.
В "Optimization Reference Manual" по P4 действительно написано, что лучше изберать сдвигов, умножений и делений, но судя по тестам, получается что их лучше вообще не использовать :-)
> Постепенно прихожу к неутешительному выводу о фиговости П4. IMHO аналогично! RC6 - это мощная арифметическая нагрузка, где хороший CPU может сильно выиграть... Похоже что P4 только и умеет что данные копировать :-)
Но по-хорошему, чтобы делать выводы, нужно посмотреть что покажет V-Tune на "трудном" для P4 коде.
> > SSE2 - тоже вариант, но у меня пока P-III :-( > > Может тогда просто SSE?
SSE от MMX отличается только поддержкой плавающей точки, что в случае с RC5/6 ничего не дает. А SSE2 добавляет 32x4, a это уже "в тему".
Чтобы сделать подбор RC5 на SSE2, нужно постараться свести алгоритм к операциям над квартетами чисел.
Удачи !
Re: Много тут...06.12.01 00:14 Автор: RedAndr UfaTeam <Андрей Рыжков> Статус: Member
> Из наших тестов мне не ясно только одно - как код, который > расходует больше тактов, в итоге дает больше keys/sec ? Да, это то и самое странное...
> > Что то не очень :( > Очень и очень плохо... На P3 получается ~200 так, вместо ~710. > Для меня самое важное, то что пустой цикл на P4 тратит в > ТРОЕ больше чем на P3. Как не крути, а это - показатель. > В "Optimization Reference Manual" по P4 действительно > написано, что лучше изберать сдвигов, умножений и делений, > но судя по тестам, получается что их лучше вообще не > использовать :-) Что то я не пойму господ из интела, что они наделали в новом своём процессоре? Сдвиги нельзя, умножать, делить тоже... Что ж тогда делать? Не все же задачи можно к SSE2 привести. Или нет?
> > Постепенно прихожу к неутешительному выводу о фиговости П4. > IMHO аналогично! RC6 - это мощная арифметическая нагрузка, > где хороший CPU может сильно выиграть... Похоже что P4 > только и умеет что данные копировать :-) Как не странно мои задачи (квантовая химия) П4 считает быстрее не только П3, но и Атлона. Вероятно как раз за счёт более быстрой памяти. Ну и на этом спасибо! ;))
> > > SSE2 - тоже вариант, но у меня пока P-III :-( > > Может тогда просто SSE? > SSE от MMX отличается только поддержкой плавающей точки, > что в случае с RC5/6 ничего не дает. А SSE2 добавляет 32x4, > a это уже "в тему". > Чтобы сделать подбор RC5 на SSE2, нужно постараться свести > алгоритм к операциям над квартетами чисел. Ну в случае RC5, я думаю, тут всё просто. Можно просто запустить в параллель четыре задачки. Не так ли?
SSE2...06.12.01 00:29 Автор: leo <Леонид Юрьев> Статус: Elderman
> > Из наших тестов мне не ясно только одно - как код, > который > > расходует больше тактов, в итоге дает больше keys/sec > ? > Да, это то и самое странное... Время наверно подскажет...
> Как не странно мои задачи (квантовая химия) П4 считает > быстрее не только П3, но и Атлона. Вероятно как раз за счёт > более быстрой памяти. Ну и на этом спасибо! ;)) > > > SSE от MMX отличается только поддержкой плавающей > точки, > > что в случае с RC5/6 ничего не дает. А SSE2 добавляет > 32x4, > > a это уже "в тему". > > Чтобы сделать подбор RC5 на SSE2, нужно постараться > свести > > алгоритм к операциям над квартетами чисел. > Ну в случае RC5, я думаю, тут всё просто. Можно просто > запустить в параллель четыре задачки. Не так ли?
Э нет, не четыре задачки, а например сразу складывать C[0...3] = A[0...3] + B[0...3] В этом как бы суть всех SIMD (Single Instruction Multiple Data).
К стати, если у вас своя математика на C/C++ и/или Fortran очень советую попробовать компиляторы от Intel или VC++ 7.0 (из Visual Studio .NET beta2/RC1)
Вопрос (внутри).02.12.01 12:16 Автор: Grom [ HZ Ural ] <Gusynin Oleg> Статус: Member
Все хорошо, клиент работает быстрее, только не может загрузить блоки из файла:
[Dec 02 09:23:43 UTC] Open failed for 'check.log'
Buffer file record count is inconsistent.
[Dec 02 09:23:43 UTC] Automatic processor detection found 1 processor.
[Dec 02 09:23:43 UTC] Open failed for 'buff-in.rc5'
Buffer file record count is inconsistent.
[Dec 02 09:23:43 UTC] Buffer seek/read error. Partial packet discarded.
P.S. Кстати посмотри на своем сайте вроде FOREVER - так пишется.
Re: быстрее, только не может загрузить блоки из файла03.12.01 10:29 Автор: leo, только без пароля Статус: Незарегистрированный пользователь
У меня дома телефонная линия сдохла...
Я проверял код тестами встроенными в клиента. Возможно проблемы из-за того что клиент откомпилирован VC++ 7.0 (из Visual Studio .NET beta2).
Дома попробую.
Короче, на dnet выложены кривые исходники 04.12.01 11:11 Автор: leo <Леонид Юрьев> Статус: Elderman
Как быстро выяснилось обновленный клиент не работает, ни с моим core, ни в оригинале. Я пробовал компилировать клиента несколькими компиляторами (VC++ 6.0, Intel C++ 5.0, VC++ 7.0), результат всегда одинаковый - получаемый клиент не понимает формата буферов, на "flush" просто молчит, а на "fetch" ругается "Input buffers full (or projects are closed)". Кроме этого, готовый клиент не создает файл-буфера для выключенных проектов, а откомпилированный создает для всех. Еще раз повторюсь, все это происходит как с моими правками так и без них.
Насколько я понимаю все дело в исходниках, которые доступны на www.distrubute.net. Это просто не те исходные тексты (или не совсем те), из которых компилируется оригинальный клиент. Как минимум видны различие в версиях: в исходных текстах "2.8015-469-GTR-01041616", а в готовом клиенте "2.8015-469-GTR-01051420". Короче, очевидно что дело именно в исходных текстах. Разбираться что там не так - самая глупая трата времени, наверное ребята из dnet просто "поправили" исходные тексты чтобы их меньше докучали всякие хацкеры с кривыми пакетами и руками...
> Насколько я понимаю все дело в исходниках, которые > доступны на www.distrubute.net. Это просто не те исходные > тексты (или не совсем те), из которых компилируется > оригинальный клиент. Как минимум видны различие в версиях: > в исходных текстах "2.8015-469-GTR-01041616", а в готовом > клиенте "2.8015-469-GTR-01051420". Короче, очевидно что > дело именно в исходных текстах. Разбираться что там не так > - самая глупая трата времени, наверное ребята из dnet > просто "поправили" исходные тексты чтобы их меньше докучали > всякие хацкеры с кривыми пакетами и руками...
Вот что написали парни из днета:
-------------------------------------------------
Why is distributed.net still not completely open-source with all parts of its source code?
Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate.
Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disasemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such.
The source code available from this page is really all of the algorithmic code that would be of interest. The only code that is not present is the file-access and network socket code, which is not terribly interesting (nor pleasant to try to comprehend). The computational cores and platform-specific optimizations included in this package is what you would want to look at if you are interested in how the client works, or how you can increase the speed of the client for your processor.
-------------------------------------------------
Если кратенько резюмировать, то исходники, выложенные на днете, НАМЕРЕННО не содержат частей, отвечающих за файловый и сетевой обмен.
> > Сейчас напишу в dnet, пусть они сами разбираются.
см. выше...
Да я это уже тоже прочитал, когда искал кому писать в dnet04.12.01 18:11 Автор: leo <Леонид Юрьев> Статус: Elderman
> Есть ли разнцица для Athlona между клиентами версий *.463 и > *.469 ?
Не знаю, у меня никогда небыло процессоров от AMD, и я эти не интересовался.
Судя по исходникам, для K7 последние изменения были сделаны в бытность 459.
На сайте dnet должен быть список изменений во всех последних версиях.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
