Оценка влияния TLB на память уничтожения жесткого algorhitms

28 ноября 2015, 10:24:19 AM	# 1
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Во время разработки комбайна CUDA для Эфириума, я столкнулся с проблемой, где hashrate на GTX750Ti резко падает, когда размер памяти буфера шахтер работает на превышает определенный порог (1 Гб на Win7 / Linux, 512 Мб на Win8 / 10) , После долгого обсуждения на форумах CUDA, один из разработчиков CUDA взвешивает и определил вопрос, как TLB уничтожение. Я в настоящее время провожу несколько исследований по этому вопросу и создал простую тестовую программу, которая измеряет эти эффекты. Она имитирует «Кинжал» часть алгоритма Эфириума в размерах разных буферов памяти (DAG) и записывает результаты в файл CSV. До сих пор, я пришел к выводу, что это не является Nvidia только проблема, но проявляется на оборудовании AMD, а также. И, видимо, это не ETH-единственная проблема, у меня есть некоторые доклады srcypt-JANE шахтеров, а также. Я в настоящее время ищу как можно больше комбинаций аппаратных средств / OS прийти к рекомендации для шахтеров, а также дизайнеров нового алго-х. Ниже приведен пример для ETH hashrate на GTX780 на Windows, с увеличением размера буфера (в МБ): Программа испытаний может быть dowloaded из https://github.com/Genoil/dagSimCL. Win-64 двоичные файлы находятся в папке x64 / Release. Вы также можете создать его самостоятельно, но только поддерживает MSVC файлы на Nvidia целенаправленные OpenCL. На аппаратном AMD вы можете запустить Код: набор GPU_MAX_ALLOC_PERCENT 100 первый. По умолчанию программа пытается не использовать все ОЗУ до вашего графического процессора до 4096Мб. Если у вас есть меньше системной памяти, вы можете добавить CMD строки параметров, чтобы проверить вплоть до нижнего максимума: Код: dagsimCL.exe 2048 Если у вас есть несколько GPU, вы должны добавить второй из параметров: Код: dagsimCL.exe 4096 1 Если вы установили несколько платформ OpenCL: Код: dagsimCL.exe 4096 0 1 Я был бы очень признателен, если вы могли бы участвовать в этом немного исследований и можно обсуждать любые обходные пути. Благодаря! постскриптум обратите внимание, что достигается hashrates с программой испытаний может быть значительно выше, чем то, что вы получаете с Actaully ethminer. Это происходит потому, что simautes только этапы Dagge, а не этапы Keccak.

Как заработать Биткоины?
Без вложений. Не майнинг.

29 ноября 2015, 9:05:57 AM	# 2
MaxDZ8 Сообщения: 673 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Получил 1806 Биткоинов Реальная история. Интересно. Пожалуйста, вы можете поделиться ссылками на все дискуссии? Учитывая, OpenCL, возможно, более высокий уровень, чем GL когда-либо было, я очень удивлен, один точно определила проблему аппаратного конструкта особенно графические процессоры традиционно управляются и существует огромный разрыв между различными операционными системами, которые в моем опыте не должно быть там для HW конструирует ... странный. У меня есть карта 1GiB так что мало я могу сделать. Я попытаюсь взглянуть в ближайшие несколько дней, если я отделил некоторое время. Первоначальный анализ в CodeXL дал мне противоречивые результаты. Вы исследовали различные схемы доступа?

29 ноября 2015, 1:41:46 PM	# 3
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Эта нить на форумах CUDA имеет самое непосредственное отношение: https://devtalk.nvidia.com/default/topic/878455/cuda-programming-and-performance/gtx750ti-and-buffers-gt-1gb-on-win7/ Кто-то там (@allnamac) написал совершенно независимую проверку, что проверить мои выводы. Это не так интересно, но показывает, что проблемы затрагивают как NVidia и AMD: http://gathering.tweakers.net/forum/list_messages/1659186

29 ноября 2015, 3:07:14 PM	# 4
Wolf0 Сообщения: 1764 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Цитата: MaxDZ8 от 29 ноября 2015 года, 9:05:57 AM Интересно. Пожалуйста, вы можете поделиться ссылками на все дискуссии? Учитывая, OpenCL, возможно, более высокий уровень, чем GL когда-либо было, я очень удивлен, один точно определила проблему аппаратного конструкта особенно графические процессоры традиционно управляются и существует огромный разрыв между различными операционными системами, которые в моем опыте не должно быть там для HW конструирует ... странный. У меня есть карта 1GiB так что мало я могу сделать. Я попытаюсь взглянуть в ближайшие несколько дней, если я отделил некоторое время. Первоначальный анализ в CodeXL дал мне противоречивые результаты. Вы исследовали различные схемы доступа? Какие различные модели доступа? Те, в Eth псевдослучайны по всему файлу DAG, IIRC.

30 ноября 2015, 1:29:57 PM

# 5

gielbier

Сообщения: 450

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Я все еще пытаюсь получить мой 7850 2GB сделать выше 1280MB, но получение отказа от ошибки памяти.
Даже с
установить GPU_MAX_ALLOC_PERCENT = 100/95 = GPU_MAX_ALLOC_PERCENT
установить GPU_MAX_HEAP_SIZE = 100
установить GPU_USE_SYNC_OBJECTS = 1

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
128 130,915 17,1593
256 130,547 17,111
384 129,763 17,0083
512 129,429 16,9645
640 129,359 16,9553
768 129,501 16,9739
896 130,307 17,0796
+1024 130,303 17,0791
1152 113,466 14,8722
+1280 103,826 13,6086

Но это, кажется, падение трудно. от 1,024->+1280

Фрагментированная (512) версии ниже:

Код:

128 130,953 17,1643
256 130,552 17,1117
384 130,483 17,1027
512 129,715 17,002
640 160,314 21,0126
768 166,186 21,7823
896 162,538 21,3042
+1024 166,417 21,8126
1152 135,096 17,7073
+1280 38,5741 5,05599
1408 23,306 3,05476
1536 17,4977 2,29346
1664 12,6435 1,65721
1792 12,2781 1,60932
+1920 10,8921 1,42764

Фрагментированная (256) версии ниже:

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
128 131,008 17,1715
256 130,584 17,1158
384 124,342 16,2977
512 114,388 14,9931
640 178,814 23,4376
768 160,401 21,0241
896 166,627 21,8401
+1024 156,984 20,5762
1152 141,14 18,4996
+1280 123,989 16,2515
1408 122,695 16,0819
1536 51,0244 6,68787
1664 29,0346 3,80563
1792 21,4296 2,80881
+1920 17,2236 2,25754

30 ноября 2015, 3:23:57 PM	# 6
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Я изменил исходный код немного, чтобы выделить в 256MB куски. Теперь должно быть возможно для AMD карты, чтобы получить использовать больше оперативной памяти. На моих GTX780, кривая hashrate это примерно то же самое (чуть-чуть медленнее) при использовании 256MB ломтей.

30 ноября 2015, 4:35:27 PM	# 7
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Цитата: Genoil от 30 ноября 2015 года, 3:23:57 PM Я изменил исходный код немного, чтобы выделить в ~~256 Мб~~ определяемые пользователем глыбы. Теперь должно быть возможно для AMD карты, чтобы получить использовать больше оперативной памяти. На моих GTX780, кривая hashrate это примерно то же самое (чуть-чуть медленнее) при использовании 256MB ломтей.

30 ноября 2015, 4:47:31 PM	# 8
apriyoni Сообщения: 308 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms У вас есть двоичный файл для переменного размера порции? Интересно, если будущее ethminer также может позволить пользователю выбрать размер патрона для оптимизации.

30 ноября 2015, 5:16:32 PM	# 9
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Цитата: apriyoni от 30 ноября 2015 года, 4:47:31 PM У вас есть двоичный файл для переменного размера порции? Интересно, если будущее ethminer также может позволить пользователю выбрать размер патрона для оптимизации. Бинарные находятся в папке x64 / Release на мерзавец репо

30 ноября 2015, 5:24:51 PM	# 10
apriyoni Сообщения: 308 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Цитата: Genoil от 30 ноября 2015 года, 5:16:32 PM Цитата: apriyoni от 30 ноября 2015 года, 4:47:31 PM У вас есть двоичный файл для переменного размера порции? Интересно, если будущее ethminer также может позволить пользователю выбрать размер патрона для оптимизации. Бинарные находятся в папке x64 / Release на мерзавец репо Какой параметр я использую в командной строке, чтобы изменить размер порции?

30 ноября 2015, 6:43:01 PM	# 11
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Цитата: apriyoni от 30 ноября 2015 года, 5:24:51 PM Цитата: Genoil от 30 ноября 2015 года, 5:16:32 PM Цитата: apriyoni от 30 ноября 2015 года, 4:47:31 PM У вас есть двоичный файл для переменного размера порции? Интересно, если будущее ethminer также может позволить пользователю выбрать размер патрона для оптимизации. Бинарные находятся в папке x64 / Release на мерзавец репо Какой параметр я использую в командной строке, чтобы изменить размер порции? Только номер: dagSimCL.exe 128

30 ноября 2015, 7:19:48 PM

# 12

Omegasun

Сообщения: 602

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Кажется, что код может быть оптимизирован дальше.

Я использовал размер порции 640, скорость изменяется.

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
+1024 171,293 22,4517
+1040 205,211 26,8974
1056 134,719 17,6579
1072 308,554 40,4428
1088 163,232 21,3952
1104 305,887 40,0932
+1120 158,693 20,8002
1136 306,434 40,165
1152 156,652 20,5326
1168 301,328 39,4956
1184 152,128 19,9397
1200 299,754 39,2894
1216 147,419 19,3225
1232 293,886 38,5203
1248 143,319 18,7851
1264 295,562 38,7399
+1280 143,378 18,7928
1296 420,797 55,1547
1312 187,432 24,5671
1328 297,962 39,0545
1344 179,346 23,5073
1360 302,645 39,6683
1376 184,994 24,2476
1392 296,381 38,8472
1408 187,815 24,6173
1424 295,367 38,7143
+1440 197,081 25,8318
1456 288,925 37,87
1472 201,804 26,4508
1488 289,776 37,9815
1504 206,96 27,1267
+1520 287,797 37,7221
1536 208,31 27,3037
1552 291,33 38,1852
1568 219,074 28,7145
1584 291,814 38,2486
1600 219,739 28,8016
1616 292,338 38,3173
1632 219,81 28,811
1648 293,074 38,4138
1664 231,998 30,4084
+1680 291,659 38,2283
1696 235,582 30,8782
1712 291,056 38,1493
1728 242,35 31,7653
1744 292,548 38,3449
1760 250,939 32,8911
1776 290,89 38,1275
1792 248,618 32,5868
1808 290,146 38,0301
1824 250,495 32,8329
+1840 290,413 38,065
+1856 252,41 33,0838
+1872 291,722 38,2365
+1888 256,025 33,5578
+1904 289,27 37,9152
+1920 255,669 33,511
+1936 8,29736 1,08755
+1952 277,308 36,3474
+1968 272,499 35,717
+1984 275,355 36,0913
2000 273,839 35,8926
+2016 271,384 35,5709
2032 270,993 35,5196
2,048 253,742 33,2585
2064 269,63 35,3409
2080 270,119 35,405
2096 273,058 35,7903
2112 271,964 35,6468
2128 274,38 35,9635
2144 268,958 35,2529
2160 273,752 35,8812
2176 262,851 34,4524
2192 272,935 35,7741
2208 258,234 33,8473
2224 272,811 35,7579
2240 250,648 32,8529
2256 274,222 35,9429
2272 246,125 32,2601
2288 278,434 36,4949
2304 240,086 31,4686
2320 276,598 36,2543
2336 235,735 30,8982
2352 274,523 35,9823
2368 226,982 29,751
2384 281,238 36,8625
2400 223,112 29,2438
2416 282,779 37,0644
2432 218,77 28,6746
2448 283,579 37,1693
2464 212,667 27,8748
2480 287,033 37,6219
2496 209,21 27,4216
2512 287,018 37,62
2528 202,401 26,5291
2544 285,671 37,4435
2560 198,479 26,0151
2576 23,6545 3,10044
2592 10,8985 1,42849

30 ноября 2015, 7:38:22 PM

# 13

Omegasun

Сообщения: 602

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Подробнее:

AMD Catalyst 7970 +15,7 Win 8,1

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
+1024 169,584 22,2277
1028 201,148 26,3649
1032 137,039 17,962
1036 304,848 39,957
+1040 168,196 22,0458
1044 306,698 40,1995
1048 168,269 22,0554
1052 306,984 40,237
1056 165,834 21,7362
+1060 304,877 39,9609
1064 163,642 21,4489
1068 307,009 40,2403
1072 165,116 21,6421
1076 308,427 40,4261
+1080 164,043 21,5015
1084 308,633 40,4532
1088 163,075 21,3746
+1092 307,799 40,3439
1096 160,319 21,0133
1100 306,587 40,185
1104 159,124 20,8566
1108 306,287 40,1457
1112 159,627 20,9226
1116 307,489 40,3032
+1120 158,726 20,8045
1124 305,745 40,0746
1128 159,441 20,8983
1132 306,6 40,1867
1136 158,056 20,7168
1140 303,038 39,7198
1144 157,432 20,6349
1148 305,833 40,0861
1152 156,652 20,5326
1156 305,136 39,9947
+1160 155,543 20,3874
1164 303,046 39,7209
1168 153,005 20,0547
1172 299,497 39,2556
1176 152,261 19,9571
+1180 300,396 39,3734
1184 152,327 19,9657
1188 301,339 39,4971
1192 151,254 19,8251
1196 300,391 39,3729
1200 150,914 19,7806
1204 299,912 39,31
1208 149,358 19,5767
1212 298,042 39,065
1216 146,716 19,2303
+1220 294,716 38,6291
1224 144,464 18,9352
1228 293,327 38,4469
1232 142,717 18,7062
1236 293,99 38,5338
1240 143,653 18,8288
+1244 293,986 38,5333
1248 143,824 18,8513
1252 294,655 38,6211
1256 143,908 18,8624
+1260 294,698 38,6266
1264 143,466 18,8044
1268 295,105 38,6799
1272 143,061 18,7513
1276 294,811 38,6414
+1280 143,163 18,7647
1284 422,562 55,386
1288 188,832 24,7506
1292 295,35 38,7121
1296 189,787 24,8757
1300 296,379 38,847
1304 188,287 24,6791
1308 298,672 39,1475
1312 186,728 24,4748
1316 297,253 38,9615
1320 183,426 24,042
1324 295,835 38,7757
1328 181,456 23,7837
1332 297,77 39,0293
1336 179,955 23,5871
1340 297,201 38,9548
1344 179,453 23,5213
1348 299,408 39,244
1352 180,218 23,6215
1356 301,928 39,5743
1360 181,53 23,7935
1364 298,281 39,0963
1368 185,617 24,3292
1372 302,053 39,5907
1376 185,688 24,3385
1380 299,94 39,3137
1384 186,133 24,3968
1388 298,336 39,1035
1392 186,56 24,4528
1396 295,824 38,7742
1400 187,393 24,562
1404 295,826 38,7746
1408 188,098 24,6543
1412 294,417 38,5898
1416 190,336 24,9477
1420 294,859 38,6477
1424 193,624 25,3786
1428 293,79 38,5076
1432 195,098 25,5718
1436 292,607 38,3526
+1440 197,223 25,8504
1444 291,125 38,1583
1448 198,542 26,0233
1452 289,802 37,985
1456 199,387 26,1341
1460 288,238 37,7799
1464 200,996 26,345
1468 288,351 37,7947
1472 202,043 26,4822
1476 288,643 37,8331
+1480 202,655 26,5624
1484 289,962 38,006
1488 203,537 26,678
1492 290,97 38,138
1496 205,972 26,9972
1500 288,161 37,7699
1504 207,029 27,1358
1508 287,617 37,6986
1512 206,491 27,0651
1516 287,496 37,6826
+1520 205,916 26,9899
1524 287,823 37,7255
1528 206,337 27,045
1532 287,394 37,6693
1536 208,207 27,2901
+1540 288,091 37,7606
1544 210,887 27,6414
1548 289,533 37,9496
1552 212,232 27,8177
1556 291,393 38,1934
1560 215,511 28,2475
1564 293,224 38,4335
1568 219,839 28,8147
1572 293,074 38,4139
1576 219,205 28,7316
+1580 292,927 38,3946
1584 219,551 28,777
1588 292,805 38,3786
1592 220,017 28,838
1596 292,63 38,3556
1600 220,541 28,9067
1604 292,791 38,3767
1608 219,929 28,8266
1612 290,807 38,1167
1616 220,381 28,8857
1620 292,645 38,3575
1624 219,375 28,7539
1628 290,738 38,1077
1632 220,587 28,9128
1636 292,731 38,3689
+1640 221,095 28,9794
1644 292,084 38,284
1648 227,149 29,7729
1652 291,895 38,2593
1656 230,119 30,1621
1660 293,108 38,4182
1664 231,49 30,3419
1668 291,726 38,2372
1672 232,928 30,5303
1676 293,916 38,5242
+1680 234,557 30,7439
1684 291,779 38,2441
1688 235,908 30,9209
1692 291,393 38,1934
1696 238,068 31,204
1 700 291,31 38,1826
1704 238,506 31,2614
1708 290,866 38,1244
1712 240,209 31,4846
1716 290,223 38,0402
1720 241,831 31,6973
1724 293,142 38,4227
1728 243,461 31,911
1732 291,057 38,1495
1736 244,488 32,0455
1740 291,978 38,2701
1744 247,518 32,4427
1748 292,685 38,3627
1752 247,4 32,4272
+1756 291,118 38,1575
1760 249,833 32,7461
1764 290,777 38,1127
1768 249,076 32,6469
1772 291,167 38,1639
1776 248,571 32,5807
+1780 291,049 38,1484
1784 247,46 32,4351
1788 291,456 38,2018
1792 246,624 32,3255
1796 290,457 38,0708
1 800 248,342 32,5506
1804 291,001 38,1421
1808 248,408 32,5593
+1812 290,238 38,042
1816 248,047 32,512
+1820 283,815 37,2002
1824 251,754 32,9978
1828 291,202 38,1685
+1832 248,827 32,6143
+1836 289,854 37,9918
+1840 249,792 32,7407
+1844 291,752 38,2406
+1848 249,65 32,7222
1852 291,76 38,2416
+1856 251,274 32,935
+1860 290,769 38,1117
+1864 249,961 32,7629
+1868 289,805 37,9854
+1872 252,607 33,1097
+1876 293,063 38,4123
+1880 253,033 33,1656
+1884 291,514 38,2093
+1888 254,853 33,4041
+1892 289,493 37,9444
+1896 254,539 33,363
1900 290,336 38,0549
+1904 256,004 33,5549
+1908 289,006 37,8806
+1912 256,708 33,6473
+1916 285,48 37,4185
+1920 255,686 33,5133
+1924 8,20708 1,07572
+1928 270,429 35,4457
+1932 274,044 35,9195
+1936 274,753 36,0125
+1940 273,052 35,7895
+1944 272,767 35,7521
+1948 272,661 35,7382
+1952 271,728 35,6159
+1956 272,43 35,708
+1960 264,622 34,6845
+1964 272,508 35,7181
+1968 262,64 34,4248
+1972 272,497 35,7168
+1976 264,491 34,6673
+1980 270,625 35,4714
+1984 264,232 34,6334
+1988 271,633 35,6035
+1992 266,205 34,892
+1996 270,912 35,509
2000 266,598 34,9436
+2004 271,738 35,6173
+2008 261,33 34,253
+2012 271,001 35,5206
+2016 260,38 34,1285
+2020 269,918 35,3786
2024 256,16 33,5754
2028 271,426 35,5763
2032 256,371 33,6031
2036 270,266 35,4243
2040 255,108 33,4375
2044 267,721 35,0907
2,048 253,612 33,2415
2052 266,675 34,9536
2056 261,409 34,2634
2060 268,425 35,183
2064 263,32 34,5139
2068 269,019 35,2608
2072 260,561 34,1523
2076 268,476 35,1897
2080 263,256 34,5055
2084 272,322 35,6937
2088 264,666 34,6903
2092 273,405 35,8357
2096 263,937 34,5948
2100 272,581 35,7277
2104 265,341 34,7788
2108 269,691 35,349
2112 265,216 34,7624
2116 274,05 35,9203
2120 264,289 34,6409
2124 273,125 35,799
2128 262,044 34,3467
2132 273,024 35,7858
2136 251,644 32,9835
2140 270,812 35,4959
2144 263,824 34,5799
2148 270,174 35,4122
2152 261,542 34,2809
2156 273,66 35,8691
2160 262,08 34,3513
2164 270,529 35,4588
2168 261,311 34,2505
2172 271,981 35,6491
2176 259,845 34,0584
2180 271,602 35,5994
2184 257,208 33,7127
2188 275,531 36,1143
2192 255,897 33,5409
2196 272,157 35,6721
2200 255,044 33,4292
2204 274,641 35,9978
2208 253,2 33,1874
2212 275,592 36,1224
2216 252,516 33,0978
2220 271,312 35,5614
2224 249,935 32,7595
2228 274,28 35,9504
2232 249,433 32,6937
2236 275,829 36,1535
2240 247,638 32,4584
2244 276,536 36,2461
2248 247,598 32,4532
2252 274,525 35,9825
2256 246,511 32,3107
2260 276,15 36,1955
2264 244,45 32,0405
2268 275,098 36,0576
2272 243,543 31,9217
2276 277,45 36,366
2280 241,421 31,6435
2284 277,051 36,3136
2288 239,379 31,3758
2292 277,136 36,3247
2296 239,134 31,3438
2300 278,188 36,4626
2304 237,303 31,1038
2308 280,271 36,7356
2312 236,599 31,0115
2316 278,368 36,4863
2320 234,686 30,7608
2324 278,092 36,4501
2328 233,993 30,6699
2332 277,043 36,3126
2336 234,41 30,7246
2340 276,13 36,1929
2344 232,09 30,4205
2348 278,554 36,5107
2352 228,067 29,8932
2356 277,828 36,4154
2360 224,97 29,4872
2364 278,849 36,5492
2368 224,327 29,4031
2372 280,193 36,7255
2376 224,697 29,4515
2380 280,091 36,7121
2384 222,211 29,1256
2388 279,278 36,6056
2392 220,997 28,9665
2396 281,534 36,9013
2400 221,729 29,0625
2404 282,74 37,0593
2408 220,127 28,8525
2412 282,141 36,9807
2416 217,894 28,5599
2420 282,731 37,0581
2424 218,422 28,629
2428 281,104 36,8448
2432 216,018 28,3139
2436 283,408 37,1469
2440 214,819 28,1568
2444 282,6 37,041
2448 214,679 28,1384
2452 283,089 37,1051
2456 212,861 27,9001
2460 285,962 37,4817
2464 210,865 27,6384
2468 286,566 37,5608
2472 210,772 27,6264
2476 285,056 37,3629
2480 208,119 27,2786
2484 286,163 37,508
2488 207,207 27,159
2492 287,098 37,6305
2496 206,643 27,0851
2500 286,126 37,5031
2504 205,334 26,9136
2508 285,176 37,3785
2512 204,538 26,8093
2516 287,837 37,7274
2520 201,79 26,449
2524 288,896 37,8662
2528 201,035 26,35
2532 286,915 37,6065
2536 199,967 26,21
2540 288,168 37,7707
2544 198,046 25,9582
2548 287,959 37,7433
2552 197,707 25,9139
2556 287,504 37,6837
2560 196,663 25,777
2564 24,5104 3,21262
2568 10,8853 1,42676

1 декабря 2015, 9:06:10 AM	# 14
Genoil Сообщения: 438 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Это интересно. Большое спасибо.

1 декабря 2015, 10:09:12 AM	# 15
MaxDZ8 Сообщения: 673 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Я посмотрел на ресурсы. Учитывая, что связанные нити 1) на немецком языке 2) сотни сообщений долго я не могу быть 100% уверен, что я получил его полностью. То, что я могу вам сказать, что я наблюдал значительное ниже, чем ожидалось, производительность памяти на GCN1.0 даже с гораздо меньшими буферами. Я думаю, что это также стоит отметить, прежде чем «вычислить на GPU» стал вещью графические ресурсы всегда была верхняя граница (! = От CL макс Alloc). Это мое понимание не такое ограничение не должно быть на месте в этой точке (и она должна быть больше, чем 1GiB в любом случае) ... Я все еще очень удивлен, это аппаратная проблема, чтобы проявить себя в таких больших пределах (если историческое ограничение еще не применяется). Оставляя в стороне максимальную Alloc, вы пробовали, как варьируя шаг влияет на результат (для буфера K MiB)?

1 декабря 2015, 1:59:38 PM

# 16

virasog

Сообщения: 742

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

От размера 640MB порции выше, изменяется скорость хэш от 20 до 40 МГц все время, то разница уменьшается от 20 МН / с до гораздо более низкой стоимости. Есть ли указать возможность оптимизации.

Кто-нибудь может сделать чанку работу в ethminers?

Последняя ethminer не отображает скорость хеширования, что затрудняет сравнение результатов. Интересно, это может быть также добавлены.

Код:

	задвижка (сл :: Const Ошибка& ERR)
		{
			ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << err.err () << "). ГПУ не может выделить DAG в одном куске. Bailing.");
			вернуться ложным;
#if 0 // Отключение отрывов для освобождения, так как он, кажется, не работает. Никогда не удается добывать блок. TODO: Фикс, когда время будет найдено.
			INT ERRCODE = err.err ();
			если (ERRCODE! = CL_INVALID_BUFFER_SIZE || ERRCODE! = CL_MEM_OBJECT_ALLOCATION_FAILURE)
				ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << ERRCODE << ")");
			cl_ulong результат;
			// если мы не на полпути попытаться выше убедитесь, мы начинаем чистый
			m_dagChunks.clear ();
			device.getInfo (CL_DEVICE_MAX_MEM_ALLOC_SIZE, &результат);
			ETHCL_LOG (
				"Не удалось выделить 1 большой кусок. Макс allocateable память "
				<< результат << ", Попытка выделить 4 порции."
			);
			// Ядро OpenCL имеет жесткий закодированное число 4 порций в данный момент
			m_dagChunksCount = 4;
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
				ETHCL_LOG ("Создание буфера для фрагмента " << я);
				m_dagChunks.push_back (кл :: Buffer (
					m_context,
					CL_MEM_READ_ONLY,
					(Я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7
				));
			}
			ETHCL_LOG ("Загрузка порций ядра");
			m_hashKernel = кл :: Kernel (программа, "ethash_hash_chunks");
			m_searchKernel = кл :: Kernel (программа, "ethash_search_chunks");
			// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
			недействительный * dag_ptr [4];
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				ETHCL_LOG ("Отображение ломоть " << я);
				dag_ptr [I] = m_queue.enqueueMapBuffer (m_dagChunks [I], правда, m_openclOnePointOne CL_MAP_WRITE: CL_MAP_WRITE_INVALIDATE_REGION, 0, (я == 3) (_dagSize - 3 * ((_dagSize? >> 9) << 7)): (_dagSize >> 9) << 7);
			}
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				тетср (dag_ptr [I], (символ *) _ даг + I * ((_ dagSize >> 9) << 7), (я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7);
				m_queue.enqueueUnmapMemObject (m_dagChunks [I], dag_ptr [I]);
			}
#endif
		}

1 декабря 2015, 10:18:30 PM

# 17

Eliovp

Сообщения: 961

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Привет,

как вы уже заметили, это действительно правильно, большой файл даг резко уменьшить скорость.

Я сделал несколько тестов тоже.

Первые результаты: 390X

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
128 261,88 34,3251
256 253,74 33,2583
384 261,27 34,2452
512 263394 34,5236
640 256832 33,6635
768 262678 34,4298
896 253595 33,2392
1 024 262,77 34,4418
1 152 260289 34,1166
1 280 262375 34,3901
1 408 262426 34,3968
1 536 261 992 34,3398
1 664 263126 34,4884
1 792 262872 34,4552
1 920 262 028 34,3446
2 048 262 432 34,3975
2 176 246609 32,3235
2 304 236,27 30,9684
2 432 222884 29,2138
2 560 206,16 27,0218
2 688 192144 25,1847
2 816 180781 23,6953
2 944 170.977 22,4103
3 072 162634 21,3168
3 200 155515 20,3837
3 328 149.158 19,5505
3 456 143477 18,8058
3 584 138379 18,1376
3 712 133821 17,5402
3 840 129724 17,0031
3 968 126137 16533

Второй результат: Fury X (остановлен @ 2816MB)

Код:

ДАГ размер (МБ) Пропускная способность (Гб / с) Hashrate (МН / с)
128 254497 33,3574
256 251412 32953
384 250,2 32,7942
512 249919 32,7574
640 249457 32,6969
768 249345 32,6821
896 249108 32,6511
1 024 248899 32,6237
1 152 248822 32,6136
1 280 248888 32,6223
1 408 248679 32,5948
1 536 248822 32,6137
1 664 248653 32,5914
1 792 248686 32,5957
1 920 248547 32,5775
2 048 248564 32,5798
2 176 244005 31,9823
2 304 217763 28,5426
2 432 165121 21,6427
2 560 135737 17,7913
2 688 118606 15,5459
2 816 106813 14,0002

"Indien nodig, является гет лучше mogelijk ом нагель Ват Testen те DOEN Хур. хеб нагель Andere kaarten ..."

2 декабря 2015, 12:12:36 PM

# 18

Genoil

Сообщения: 438

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Цитата: virasog от 01 декабря 2015 года, 1:59:38 PM

Код:

	задвижка (сл :: Const Ошибка& ERR)
		{
			ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << err.err () << "). ГПУ не может выделить DAG в одном куске. Bailing.");
			вернуться ложным;
#if 0 // Отключение отрывов для освобождения, так как он, кажется, не работает. Никогда не удается добывать блок. TODO: Фикс, когда время будет найдено.
			INT ERRCODE = err.err ();
			если (ERRCODE! = CL_INVALID_BUFFER_SIZE || ERRCODE! = CL_MEM_OBJECT_ALLOCATION_FAILURE)
				ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << ERRCODE << ")");
			cl_ulong результат;
			// если мы не на полпути попытаться выше убедитесь, мы начинаем чистый
			m_dagChunks.clear ();
			device.getInfo (CL_DEVICE_MAX_MEM_ALLOC_SIZE, &результат);
			ETHCL_LOG (
				"Не удалось выделить 1 большой кусок. Макс allocateable память "
				<< результат << ", Попытка выделить 4 порции."
			);
			// Ядро OpenCL имеет жесткий закодированное число 4 порций в данный момент
			m_dagChunksCount = 4;
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
				ETHCL_LOG ("Создание буфера для фрагмента " << я);
				m_dagChunks.push_back (кл :: Buffer (
					m_context,
					CL_MEM_READ_ONLY,
					(Я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7
				));
			}
			ETHCL_LOG ("Загрузка порций ядра");
			m_hashKernel = кл :: Kernel (программа, "ethash_hash_chunks");
			m_searchKernel = кл :: Kernel (программа, "ethash_search_chunks");
			// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
			недействительный * dag_ptr [4];
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				ETHCL_LOG ("Отображение ломоть " << я);
				dag_ptr [I] = m_queue.enqueueMapBuffer (m_dagChunks [I], правда, m_openclOnePointOne CL_MAP_WRITE: CL_MAP_WRITE_INVALIDATE_REGION, 0, (я == 3) (_dagSize - 3 * ((_dagSize? >> 9) << 7)): (_dagSize >> 9) << 7);
			}
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				тетср (dag_ptr [I], (символ *) _ даг + I * ((_ dagSize >> 9) << 7), (я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7);
				m_queue.enqueueUnmapMemObject (m_dagChunks [I], dag_ptr [I]);
			}
#endif
		}

Это может быть Оппертьюнитями для оптимизации. Фрагментированная реализация в текущем ethminer отключена, поскольку она не работает. Я посмотрю, смогу ли я найти какое-то время, чтобы проверить, если это может работать в ethminer.

2 декабря 2015, 5:54:48 PM

# 19

Dofnatues

Сообщений: 16

Цитировать по имени
цитировать ответ

Re: Оценка влияния TLB на память уничтожения жесткого algorhitms

Цитата: Genoil от 02 декабря 2015 года, 12:12:36 PM

Цитата: virasog от 01 декабря 2015 года, 1:59:38 PM

Код:

	задвижка (сл :: Const Ошибка& ERR)
		{
			ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << err.err () << "). ГПУ не может выделить DAG в одном куске. Bailing.");
			вернуться ложным;
#if 0 // Отключение отрывов для освобождения, так как он, кажется, не работает. Никогда не удается добывать блок. TODO: Фикс, когда время будет найдено.
			INT ERRCODE = err.err ();
			если (ERRCODE! = CL_INVALID_BUFFER_SIZE || ERRCODE! = CL_MEM_OBJECT_ALLOCATION_FAILURE)
				ETHCL_LOG ("Выделение / отображение одного буфер потерпел неудачу с: " << err.what () << "(" << ERRCODE << ")");
			cl_ulong результат;
			// если мы не на полпути попытаться выше убедитесь, мы начинаем чистый
			m_dagChunks.clear ();
			device.getInfo (CL_DEVICE_MAX_MEM_ALLOC_SIZE, &результат);
			ETHCL_LOG (
				"Не удалось выделить 1 большой кусок. Макс allocateable память "
				<< результат << ", Попытка выделить 4 порции."
			);
			// Ядро OpenCL имеет жесткий закодированное число 4 порций в данный момент
			m_dagChunksCount = 4;
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
				ETHCL_LOG ("Создание буфера для фрагмента " << я);
				m_dagChunks.push_back (кл :: Buffer (
					m_context,
					CL_MEM_READ_ONLY,
					(Я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7
				));
			}
			ETHCL_LOG ("Загрузка порций ядра");
			m_hashKernel = кл :: Kernel (программа, "ethash_hash_chunks");
			m_searchKernel = кл :: Kernel (программа, "ethash_search_chunks");
			// TODO Примечание: Если мы когда-нибудь изменится к _dagChunksNum, кроме 4, то размер нужно будет перерасчет
			недействительный * dag_ptr [4];
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				ETHCL_LOG ("Отображение ломоть " << я);
				dag_ptr [I] = m_queue.enqueueMapBuffer (m_dagChunks [I], правда, m_openclOnePointOne CL_MAP_WRITE: CL_MAP_WRITE_INVALIDATE_REGION, 0, (я == 3) (_dagSize - 3 * ((_dagSize? >> 9) << 7)): (_dagSize >> 9) << 7);
			}
			для (без знака = 0; я < m_dagChunksCount; я ++)
			{
				тетср (dag_ptr [I], (символ *) _ даг + I * ((_ dagSize >> 9) << 7), (я == 3)? (_dagSize - 3 * ((_dagSize >> 9) << 7)): (_dagSize >> 9) << 7);
				m_queue.enqueueUnmapMemObject (m_dagChunks [I], dag_ptr [I]);
			}
#endif
		}

Если вы можете заставить его работать, вы сэкономите много AMD карты быть полезным в течение месяца или два.

Кстати, почему последняя ethminer (1.1.0) не имеет скорость?

10 декабря 2015, 8:16:43 AM	# 20
зловещий Сообщения: 381 Цитировать по имени цитировать ответ	Re: Оценка влияния TLB на память уничтожения жесткого algorhitms Кроме того, все, что громить TLB как наступил 280x обладает большей пропускной способностью (~ 300GBs) по сравнению с 390x только имея 262 GBs Fury X только 249 ГЗ (Также, кроме пропускной способности памяти GPU тайминги, как представляется, является основным фактором) PS: может быть 280x оптимизировал тайминги от свай (обновления биоса)?

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW

Заголовок