Вычисление числа Пи на ассемблере [Архив] - Страница 2 - Speccy

Просмотр полной версии : Вычисление числа Пи на ассемблере

Страницы : 1 [2]

ivagor

08.01.2016, 11:40

С 6502 гораздо легче и коды легко масштабировать, типа сделать 64/32-деление
Выкладывал тут версию легко масштабируемого деления для 8080, практически в стиле 6502, все в памяти. Но очень медленно.

blackmirror

08.01.2016, 13:04

Формула 12*atan(1/18)+8*atan(1/57)-5*(atan(/239) (http://algolist.manual.ru/maths/count_fast/pi.php), по сравнению с 4*atan(1/5)-atan(1/239) требует на пару процентов меньше делений, но в последней формуле, применительно к вычислению 100 знаков, делить на 239^2 требуется только в 11% случаев, во всех остальных - делить нужно на числа менее 256, то есть для i8080 самый оптимальный вариант. С 8 разрядным делением всё просто, в HL делимое, в BC делитель*128, DE=-BC, ну а дальше сначала складываем(вычитаем), делаем если нужно переход, добавляем разряд частного к A, потом удваиваем HL. Ну а в 16-разрядном сначала удвоение HL, переход по переполнению, сложение(вычитание), переход, в половине ветвей добавление разряда частного к A(можно сразу добавлять 2^n, ничего не сдвигая). На выходе должен получиться отрицательный остаток, чтобы к нему можно было добавить байт и сразу скорректировать остаток/частное, если было переполнение. В общем по сравнению с 8-разрядным делением, требующим 4 команды на бит, здесь потребуется дополнительный переход, и несколько команд в конце для добавления байта.

В качестве обобщения, прицеплю сюда небольшую модификацию беззнакового деления с 4 ветвями, можно выкинуть половину и чуть ускорить, если делителей более 2^15 не требуются, а для Z80 можно легко расширить до 32х разрядного делителя, если делать обмен регистров. 55501

Еще наткнулся в википедии на Метод БВЕ (http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%91%D0%92%D0%95) , смысл которого в том, что слагаемые группируются сначала парами, общий множитель выносится за скобки, а оставшиеся дроби приводятся к общему знаменателю и складываются, далее пары опять объединяются и таким же образом вычисляются новые дроби. А в конце нужно будет просто поделить два очень больших числа. Можно даже на завершающих шагах не вычислять больше требуемой точности, но плавающая точка с мантиссой переменной длины это наверно будет жесть и для 100 или 1000 цифр эффекта не даст.

litwr

06.02.2016, 23:09

Что-то тут всё стихло. :( Немного пооптимизировал версию для 8086.
По IBM PC 5150 - 40.4 c на 1000 знаков,
по IBM PC 5170 (AT 6 MHz) - 8.2 cек на 1000 знаков. АТ в 5 раз почти быстрее на пи, чем ХТ. Использовал эмулятор с http://pcem-emulator.co.uk/
Кажется, что он чуть быстрее, чем следует.

LeoN65816

28.02.2016, 02:07

Аналогичный бенчмаркнайзер на асме 65816 - "Решето Эратосфена" (http://txbobsc.com/aal/1985/aal8509.html#a1).

perestoronin

24.05.2016, 22:43

Для предварительной оценки сложности вычислений можно использовать встроенный в любой linux калькулятор командной строки (http://www.basicallytech.com/blog/archive/23/command-line-calculations-using-bc/), к примеру как расписано здесь (http://stackoverflow.com/questions/23524661/how-can-i-calculate-pi-using-bash-command)

$ { echo -n "scale=100;"; seq 1 2 200 | xargs -n1 -I{} echo '(16*(1/5)^{}/{}-4*(1/239)^{}/{})';} | paste -sd-+ | bc -l
3.141592653589793238462643383279502884197169399375 10582097494459230781640628620899862803482534211706 79

возможно сработает и такой там же предложенный способ, но только вот верные ли цифры я не проверял:

# echo "scale=1000; 4*a(1)" | bc -l
3.141592653589793238462643383279502884197169399375 105820974944592307\
81640628620899862803482534211706798214808651328230 664709384460955058\
22317253594081284811174502841027019385211055596446 229489549303819644\
28810975665933446128475648233786783165271201909145 648566923460348610\
45432664821339360726024914127372458700660631558817 488152092096282925\
40917153643678925903600113305305488204665213841469 519415116094330572\
70365759591953092186117381932611793105118548074462 379962749567351885\
75272489122793818301194912983367336244065664308602 139494639522473719\
07021798609437027705392171762931767523846748184676 694051320005681271\
45263560827785771342757789609173637178721468440901 224953430146549585\
37105079227968925892354201995611212902196086403441 815981362977477130\
99605187072113499999983729780499510597317328160963 185950244594553469\
08302642522308253344685035261931188171010003137838 752886587533208381\
42061717766914730359825349042875546873115956286388 235378759375195778\
18577805321712268066130019278766111959092164201988
1000 знаков этот метод общелкивает менее чем за секунду, а вот 10000 лучше не пробывать так считать - "подвесил" машину на пару минут точно :)

# echo "scale=10000; 4*a(1)" | bc -l
3.141592653589793238462643383279502884197169399375 105820974944592307\
81640628620899862803482534211706798214808651328230 664709384460955058\
22317253594081284811174502841027019385211055596446 229489549303819644\
28810975665933446128475648233786783165271201909145 648566923460348610\
45432664821339360726024914127372458700660631558817 488152092096282925\
40917153643678925903600113305305488204665213841469 519415116094330572\
70365759591953092186117381932611793105118548074462 379962749567351885\
75272489122793818301194912983367336244065664308602 139494639522473719\
07021798609437027705392171762931767523846748184676 694051320005681271\
45263560827785771342757789609173637178721468440901 224953430146549585\
37105079227968925892354201995611212902196086403441 815981362977477130\
99605187072113499999983729780499510597317328160963 185950244594553469\
08302642522308253344685035261931188171010003137838 752886587533208381\
42061717766914730359825349042875546873115956286388 235378759375195778\
18577805321712268066130019278766111959092164201989 380952572010654858\
63278865936153381827968230301952035301852968995773 622599413891249721\
77528347913151557485724245415069595082953311686172 785588907509838175\
46374649393192550604009277016711390098488240128583 616035637076601047\
10181942955596198946767837449448255379774726847104 047534646208046684\
25906949129331367702898915210475216205696602405803 815019351125338243\
00355876402474964732639141992726042699227967823547 816360093417216412\
19924586315030286182974555706749838505494588586926 995690927210797509\
30295532116534498720275596023648066549911988183479 775356636980742654\
25278625518184175746728909777727938000816470600161 452491921732172147\
72350141441973568548161361157352552133475741849468 438523323907394143\
33454776241686251898356948556209921922218427255025 425688767179049460\
16534668049886272327917860857843838279679766814541 009538837863609506\
80064225125205117392984896084128488626945604241965 285022210661186306\
74427862203919494504712371378696095636437191728746 776465757396241389\
08658326459958133904780275900994657640789512694683 983525957098258226\
20522489407726719478268482601476990902640136394437 455305068203496252\
45174939965143142980919065925093722169646151570985 838741059788595977\
29754989301617539284681382686838689427741559918559 252459539594310499\
72524680845987273644695848653836736222626099124608 051243884390451244\
13654976278079771569143599770012961608944169486855 584840635342207222\
58284886481584560285060168427394522674676788952521 385225499546667278\
23986456596116354886230577456498035593634568174324 112515076069479451\
09659609402522887971089314566913686722874894056010 150330861792868092\
08747609178249385890097149096759852613655497818931 297848216829989487\
22658804857564014270477555132379641451523746234364 542858444795265867\
82105114135473573952311342716610213596953623144295 248493718711014576\
54035902799344037420073105785390621983874478084784 896833214457138687\
51943506430218453191048481005370614680674919278191 197939952061419663\
42875444064374512371819217999839101591956181467514 269123974894090718\
64942319615679452080951465502252316038819301420937 621378559566389377\
87083039069792077346722182562599661501421503068038 447734549202605414\
66592520149744285073251866600213243408819071048633 173464965145390579\
62685610055081066587969981635747363840525714591028 970641401109712062\
80439039759515677157700420337869936007230558763176 359421873125147120\
53292819182618612586732157919841484882916447060957 527069572209175671\
16722910981690915280173506712748583222871835209353 965725121083579151\
36988209144421006751033467110314126711136990865851 639831501970165151\
16851714376576183515565088490998985998238734552833 163550764791853589\
32261854896321329330898570642046752590709154814165 498594616371802709\
81994309924488957571282890592323326097299712084433 573265489382391193\
25974636673058360414281388303203824903758985243744 170291327656180937\
73444030707469211201913020330380197621101100449293 215160842444859637\
66983895228684783123552658213144957685726243344189 303968642624341077\
32269780280731891544110104468232527162010526522721 116603966655730925\
47110557853763466820653109896526918620564769312570 586356620185581007\
29360659876486117910453348850346113657686753249441 668039626579787718\
55608455296541266540853061434443185867697514566140 680070023787765913\
44017127494704205622305389945613140711270004078547 332699390814546646\
45880797270826683063432858785698305235808933065757 406795457163775254\
20211495576158140025012622859413021647155097925923 099079654737612551\
76567513575178296664547791745011299614890304639947 132962107340437518\
95735961458901938971311179042978285647503203198691 514028708085990480\
10941214722131794764777262241425485454033215718530 614228813758504306\
33217518297986622371721591607716692547487389866549 494501146540628433\
66393790039769265672146385306736096571209180763832 716641627488880078\
69256029022847210403172118608204190004229661711963 779213375751149595\
01566049631862947265473642523081770367515906735023 507283540567040386\
74351362222477158915049530984448933309634087807693 259939780541934144\
73774418426312986080998886874132604721569516239658 645730216315981931\
95167353812974167729478672422924654366800980676928 238280689964004824\
35403701416314965897940924323789690706977942236250 822168895738379862\
30015937764716512289357860158816175578297352334460 428151262720373431\
46531977774160319906655418763979293344195215413418 994854447345673831\
62499341913181480927777103863877343177207545654532 207770921201905166\
09628049092636019759882816133231666365286193266863 360627356763035447\
76280350450777235547105859548702790814356240145171 806246436267945612\
75318134078330336254232783944975382437205835311477 119926063813346776\
87969597030983391307710987040859133746414428227726 346594704745878477\
87201927715280731767907707157213444730605700733492 436931138350493163\
12840425121925651798069411352801314701304781643788 518529092854520116\
58393419656213491434159562586586557055269049652098 580338507224264829\
39728584783163057777560688876446248246857926039535 277348030480290058\
76075825104747091643961362676044925627420420832085 661190625454337213\
15359584506877246029016187667952406163425225771954 291629919306455377\
99140373404328752628889639958794757291746426357455 254079091451357111\
36941091193932519107602082520261879853188770584297 259167781314969900\
90192116971737278476847268608490033770242429165130 050051683233643503\
89517029893922334517220138128069650117844087451960 121228599371623130\
17114448464090389064495444006198690754851602632750 529834918740786680\
88183385102283345085048608250393021332197155184306 354550076682829493\
04137765527939751754613953984683393638304746119966 538581538420568533\
86218672523340283087112328278921250771262946322956 398989893582116745\
62701021835646220134967151881909730381198004973407 239610368540664319\
39509790190699639552453005450580685501956730229219 139339185680344903\
98205955100226353536192041994745538593810234395544 959778377902374216\
17271117236434354394782218185286240851400666044332 588856986705431547\
06965747458550332323342107301545940516553790686627 333799585115625784\
32298827372319898757141595781119635833005940873068 121602876496286744\
60477464915995054973742562690104903778198683593814 657412680492564879\
85561453723478673303904688383436346553794986419270 563872931748723320\
83760112302991136793862708943879936201629515413371 424892830722012690\
14754668476535761647737946752004907571555278196536 213239264061601363\
58155907422020203187277605277219005561484255518792 530343513984425322\
34157623361064250639049750086562710953591946589751 413103482276930624\
74353632569160781547818115284366795706110861533150 445212747392454494\
54236828860613408414863776700961207151249140430272 538607648236341433\
46235189757664521641376796903149501910857598442391 986291642193994907\
23623464684411739403265918404437805133389452574239 950829659122850855\
58215725031071257012668302402929525220118726767562 204154205161841634\
84756516999811614101002996078386909291603028840026 910414079288621507\
84245167090870006992821206604183718065355672525325 675328612910424877\
61825829765157959847035622262934860034158722980534 989650226291748788\
20273420922224533985626476691490556284250391275771 028402799806636582\
54889264880254566101729670266407655904290994568150 652653053718294127\
03369313785178609040708667114965583434347693385781 711386455873678123\
01458768712660348913909562009939361031029161615288 138437909904231747\
33639480457593149314052976347574811935670911013775 172100803155902485\
30906692037671922033229094334676851422144773793937 517034436619910403\
37511173547191855046449026365512816228824462575916 333039107225383742\
18214088350865739177150968288747826569959957449066 175834413752239709\
68340800535598491754173818839994469748676265516582 765848358845314277\
56879002909517028352971634456212964043523117600665 101241200659755851\
27617858382920419748442360800719304576189323492292 796501987518721272\
67507981255470958904556357921221033346697499235630 254947802490114195\
21238281530911407907386025152274299581807247162591 668545133312394804\
94707911915326734302824418604142636395480004480026 704962482017928964\
76697583183271314251702969234889627668440323260927 524960357996469256\
50493681836090032380929345958897069536534940603402 166544375589004563\
28822505452556405644824651518754711962184439658253 375438856909411303\
15095261793780029741207665147939425902989695946995 565761218656196733\
78623625612521632086286922210327488921865436480229 678070576561514463\
20469279068212073883778142335628236089632080682224 680122482611771858\
96381409183903673672220888321513755600372798394004 152970028783076670\
94447456013455641725437090697939612257142989467154 357846878861444581\
23145935719849225284716050492212424701412147805734 551050080190869960\
33027634787081081754501193071412233908663938339529 425786905076431006\
38351983438934159613185434754649556978103829309716 465143840700707360\
41123735998434522516105070270562352660127648483084 076118301305279320\
54274628654036036745328651057065874882256981579367 897669742205750596\
83440869735020141020672358502007245225632651341055 924019027421624843\
91403599895353945909440704691209140938700126456001 623742880210927645\
79310657922955249887275846101264836999892256959688 159205600101655256\
375676
Интереснее конечно же посчитать оптимизированной программой на ассемблере для разных ретропроцессоров по формуле Мачина, или иной, более быстрой.
PS. Вероятно первым ретропроцессором, в железе, а не в эмуляторах, на котором я проверю скорость формулы Мачина, станет R65С02P4 (Rockwell) на новоделе Apple I. (http://mdesk.ru/a1/) от MDesk.

litwr

13.07.2016, 22:08

3ачахла тема. :( Никто железом не помогает... Но вот случилась оказия прогнать коммодорскую программу на бийбе (ВВС Микро) с вторым процессором 6502 на 4 МГц - такие штамповали массово с 1985-86. 100 знаков за 0.78 сек. Для бийбов делали тогда же ещё и платы на z80 6 МГц и без задержек.
На ВВС с середины 80-х ставили именно Rockwell 6512.

litwr

25.07.2016, 20:18

А вот ссылка на всех Мачинов в калькуляторе. Там Мачин быстрее шпигота на 5000, но чуть-чуть - http://sense.net/~egan/hpgcc/#Example%3A%20%20%CF%80%20Shootout

perestoronin

25.07.2016, 23:34

Там Мачин быстрее шпигота на 5000, но чуть-чуть
В том-то и прелесть всяких разложений и хитрых алгоритмов, что они позоляют выжать из процессора все, на что он способен.
А измерять производительность алгоритмов на Васиках, калькуляторах и тем более на Жабе (Java) - особой пользы, как и разницы в скорости - не заметить никак :)
А что касается 6502 и "русского обгрзызка" - то м.с. 1404 все еще в пути, как приедут - может и дособираю Обгрызок-1 и тогда посмотрим на что годен Эппл-1.

LeoN65816

26.07.2016, 06:31

Дайте, пожалуйста, "наводку" на 6502-реализацию какого-либо из этих алгоритмов. Попробую на АГАТе прогнать.

perestoronin

26.07.2016, 10:13

Дайте, пожалуйста, "наводку" на 6502-реализацию какого-либо из этих алгоритмов. Попробую на АГАТе прогнать.
Процитирую текст под спойлером первого поста:

Индексатор ссылок на ресурсы с исходниками некоторых других реализаций вычисления числа Пи
http://www.pi314.net/eng/programmes.php

На процессорах 6502:

На форуме 6502 в топике http://forum.6502.org/viewtopic.php?f=2&t=2239 есть архивчики для процессоров 6500 и 6502:
http://forum.6502.org/download/file.php?id=159&sid=11abefe5280c12cc3562659b6ca3a9f8
http://forum.6502.org/download/file.php?id=160&sid=11abefe5280c12cc3562659b6ca3a9f8
Интересно, как долго будет считаться число Пи на Денди :)

Mdesk

31.07.2016, 13:37

Реплика Apple I, Synertek 6502 CPU @ 1.023 MHz:
1000 знаков, вычисления – 1 мин. 52 сек., вычисления + вывод на экран – 2 мин. 17 сек.

Исходник (Мэчин/Тейлор) взял по последней ссылке в предыдущем сообщении (http://forum.6502.org/download/file.php?id=160&sid=11abefe5280c12cc3562659b6ca3a9f8). В нем в 930 строке вместо "ldx #-1" написал "ldx #$FF", а то ассемблер ругался.
Ассемблер и линковщик взял с 6502.org (cc65 от Ullrich von Bassewitz), потому что автор исходника им пользовался - получил бинарник.
Из бинарника HEX-редактором и текстовым редактором сделал командный файл для Apple I (это текст, как если бы мы вводили данные в память компа с клавиатуры).
Этот командный файл утилитой toaiff (http://www.willegal.net/appleii/appleii-first_page.htm) от Mike Willegal преобразовал в AIFF звуковой файл (собрал эту утилиту для WIN32).
Звуковой файл грузим в реплику Apple I и радуемся.

litwr

01.08.2016, 20:38

Mdesk, благодарности вам за интересные результаты. Получается, что по Мачину 8-битки более чем 2 раза быстрее считают, чем по "затвору" ("шпиготу"). Что подтвердило исходное мнение уважаемого perestoronin'a. Осталось уважаемому ivagor'y перевести всё на 8080 и Вектор выдаст 100 знаков секунд за 0.7 или даже меньше. Однако, формула Стёрмера ещё быстрее и через те же арктангентсы. А если кто реализует подход Чудновских на 8-битном "камне", то должно быть ещё быстрее.
Добавлю ещё, что впечатлен тем, как в 1949 30-тонная махина компьютера Eniac с помощью четырех энтузиастов, которые выступали и в качестве внешней памяти компьютера, в течении 70 часов (без сна?) считала π до более чем 2000 знаков, что даёт примерно 17 часов на 1000 знаков. http://jerkwerks.com/pi-day-rematch-apple-ii-vs-hp-41c/

- - - Добавлено - - -

А вот немного негатива. В оригинальной статье Рабиновича и Вагона (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.693.8211&rep=rep1&type=pdf) по затворному алгоритму приводится программа на паскале. Она правильно считает 100 знаков, но неправильно 1000 - там какая-то ошибка, математики не довели программу... Поэтому, просьба к уважаемому Mdesk, сообщите последние 8 знаков из расчёта.

Mdesk

01.08.2016, 20:52

Mdesk, сообщите последние 8 знаков из расчёта
64201989

LeoN65816

04.08.2016, 08:33

В оригинальной статье Рабиновича и Вагона (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.693.8211&rep=rep1&type=pdf) по затворному алгоритму приводится программа на паскале.
Перевёл эту прогу на паскакале сначала на Бейсик АГАТа (хотел в дальнейшем перевести на асм). Прогнал в эмуле. Всегда даёт лишний (лидирующий) ноль. Для 10 посчитал 10 знаков, для 100 посчитал 102 знака, для 1000 посчитал 1019 знаков... Гдей-то глюк...

litwr

06.08.2016, 23:21

64201989
9 - это 1001 цифра, получилась восточная сказка. :) По Мачину плохо, что трудно заранее определить минимальное число итераций для заданного числа цифр. И в алгоритме использовалась 256-значная система счисления, "затвор" так не может - он сразу ответ печатает, а не сначала накапливает, а потом переводит в 10-й вид.

Перевёл эту прогу на паскакале сначала на Бейсик АГАТа (хотел в дальнейшем перевести на асм). Прогнал в эмуле. Всегда даёт лишний (лидирующий) ноль. Для 10 посчитал 10 знаков, для 100 посчитал 102 знака, для 1000 посчитал 1019 знаков... Гдей-то глюк...
Сначала проще с паскалем разобраться, хороший компилятор fpc есть для всех платформ. 100 знаков считает правильно, хотя и с лидирующим нулем - всего 101 знак. А с 1000 - полная ерунда, больше половины знаков неверны. Но ваш результат совсем другой, с вставкой лишних нулей, но вроде бы с правильными прочими цифрами - что-то слегка не так перевели. Проблема с 1000 знаков в том, что нужно все переменные делать типа longint. Авторы наверное использовали паскаль, где тип integer 32-битный. Проверил на 3000 и 9000 знаков, с longint - все правильно.
Почти уверен, что оптимизированный "затвор", выдающий по 4 цифры за раз, быстрее исходного, хотя возможно он потребует чуть меньше памяти, 6.67 байт на цифру, вместо 7. А есть ещё "затвор без границ", но на его реализации даже спецы из HP больше 3000 знаков не смогли получить.
В https://rosettacode.org/wiki/Pi эта программка использует вспомогательную процедуру, в каком-то не совсем чистом паскале, но не работает совсем. Кстати, туда можно коды 6502, 8080, ... вставить, пока ещё не занято место.

litwr

01.09.2016, 13:54

https://www.youtube.com/watch?v=wlcGm8DSo6o&feature=youtu.be
z80 112 MHz в действии. :)

HardWareMan

01.09.2016, 17:22

Чегото не пойму я. https://ru.wikipedia.org/wiki/Acorn_Atom

litwr

01.09.2016, 19:49

Подключил человек из Голландии к своему Атому крутой сопроцессор и получает удовольствие от скорости и даже этим удовольствием делится. :)
http://stardot.org.uk/forums/viewtopic.php?f=44&t=8852

litwr

18.10.2016, 22:45

Кто-то ранее интересовался самым крутым 8-битным процессором 6809. Сделал и для него "затвор". Побыстрее 6502 из-за второго аккумулятора, но в целом впечатление неоднозначное. Какой-то 6809 неуклюжий: обратный порядок байт тормозит арифметику, с памятью работает медленнее, чем 6502, индексные регистры медленные, пересылка одного аккумулятора в другой занимает 6 (!) тактов, ... Если бы MOSTEC не разогнали, то уверен, что там бы сделали что-то гораздо более качественное.
http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html

litwr

27.10.2016, 13:10

Есть очень необычный способ посчитать пи, использую клеточную колонию - http://pentadecathlon.com/lifeNews/2011/01/phi_and_pi_calculators.html. Примерно миллион клеток за примерно 280 миллиардов поколений смогли посчитать 3 знака на средненьком ПК. Картинка с сайта явно высчитана на сверхмощном суперкомпьютере. На обычном на три знака ушло почти два часа при минимуме требуемой памяти 8 ГБ. Хотя другая программа справилась минут за 40. Прикрепляю свою картинку. На картинке с сайта знаки пи в верху, но сильно размазаны из-за уменьшения. Размеры этого клеточного компьютера 163841х114689, в экран не влезет. Прикрепляемая картинка уменьшена в 128 раз, цифры отчетливо видны.
58588
При закачке на сайт картинка сменила размер и формат, поэтому прикрепляю её в zip-архиве.
58587

litwr

30.12.2016, 21:13

С сожалением вспоминаю, что возможно моя поспешно выбранная позиция, послужила демотиватором для уважаемого ivagor'a. Интересно было бы посмотреть на 8085 коды. Это же какая-то почти уникальнось. Сам сделал на днях код для короля 8-х процессоров 6309. С двумя 16-битными и быстрыми аккумуляторами, с аппаратным делением 32-разрядных чисел и полной совместимостью с 6809 такой чип наверное позволительно так называть. Народ до сих пор свои Коко и Драконы обновляет. Хотя все несуразности 6809 также унаследованы, но с 16 битным АЛУ они почти незаметны. На "затворе-шпиготе" 6309 показал себя в 3.62 раза быстрее, чем 6809. В 6502 бы четыре аккумулятора и аппаратные умножение с делением...

LeoN65816

31.12.2016, 09:07

В 6502 бы четыре аккумулятора и аппаратные умножение с делением...

Дык, у SuperCPU(65816) тоже потенциал приличный. Однако, кроме частоты этим не воспользовались...

litwr

06.01.2017, 23:06

65816 - в каком-то смысле позор. Такое можно было сделать и к 77-78. В 75-м 6502 рвал 8080, а 65816 рядом с 8086 выглядит бледно. Ни новых регистров, ни даже аппаратного умножения, новых команд практически нет. В режиме 16 бит всего-то процентов на 50% быстрее изначального 6502... Команды не разогнаны как на 4510. С 6309 сравнивать не совсем корректно. 65816 - 16-разрядный процессор с 8-битной шиной данных, а 6309 8-разрядный с 16-разрядным АЛУ. Можно сравнить с 65802, которым можно было заменять на плате 6502 (так и делали с Эплами). 6309 гораздо мощнее. На 1.7 МГц, на арифметике легко обгоняет 8086 на 5 МГц. 65816/02 на арифметике примерно как 8086. 65816 может с 16 МБ памяти работать, но неуклюже. R800 (который в раза 4 быстрее z80) также 6309 проигрывает на арифметике раза в два. Не давали японцам развернуться, хотя и не засудили как NEC или MOS Technology.

blackmirror

13.01.2017, 02:08

Из формул Мачина наиболее замечательная для i8080 будет:

32*atan(1/10)-4*atan(1/239)-16*atan(1/515)

если считать в 100-ой системе, по такому алгоритму:

a=32/10
b=4/239
c=16/515
for n=1 to len
pi=(a-b-c)/(2n-1) ;здесь было n, что есть злобный баг
a/=100
b/=239 b/=239
c/=103 c/=103 c/=25
end for
Деление на 25,103 и 239 делается по таблицам менее чем за 70 тактов на байт, а на 100 вообще делить не потребуется. Единственная сложная операция это деление на n, там получается примерно 400 тактов на байт, если делитель более 127. Но деление на n можно совместить для всех трёх слагаемых, при этом память будет требоваться для pi и трёх слагаемых. Результаты в EmuZWin для 3.5 МГц получились такие:

100 цифр - 0,2 ms (=1/5 s)
300 цифр - 2 s
1000 цифр - 25 s
4000 цифр - 418 s

В архиве текст программы и картинки, большие цифры это время в кадрах. Что касается вычислений, то там только команды i8080 используются, если нигде не зевнул. Комментариев пока нету, но если кто будет допиливать для реального i8080 могу добавить.
5940359405594045940659402

litwr

30.01.2017, 13:30

Peзультаты - супер! Но возможно вы выложили не ту версию программы. Та, что есть, под СР/М считает неправильно 314227... - не пи. :( По адресу $8fcd высчитывается $1f2a1b42... И почему без бинарника? Использован ассемблер с некоторыми неожиданными особенностями типа CP A,5 и ADC 0 - первую инструкцию по стандарту Zilog пишут CP 5, а вторую ADC A,0.
Интересно уважаемый ivagor в курсе? С хорошей оптимизацией Вектор может перехватить лидерство. А с версией для 8085 может стать и недосигаемым.
Кстати, так до сих пор и не разобрался, как работают задержки на Спектруме. :( Вроде их нет при обращении к памяти выше $8000. У вас программа и все данные именно там. Но интересно, что происходит, если процессор обращается к памяти ниже $8000 из программы, которая выше $8000? Заранее благодарен за ответ или ссылку.

SoftFelix

30.01.2017, 13:43

В архиве текст программы и картинки, большие цифры это время в кадрах.
Прикольно. Неужели из топика всё же родился хоть какой-то бенч для Спекка? Хотя нет - только .asm внутри. Запилите нормальный бенч для Спекка на самом быстром алгоритме Z80! Можно будет пиписками померяться. :)

litwr

30.01.2017, 14:42

А для заинтересовавшихся с другими процессорами хорошо бы и алгоритм на ЯВУ выложить...

blackmirror

30.01.2017, 16:55

Peзультаты - супер! Но возможно вы выложили не ту версию программы. Та, что есть, под СР/М считает неправильно 314227... - не пи. По адресу $8fcd высчитывается $1f2a1b42... И почему без бинарника? Использован ассемблер с некоторыми неожиданными особенностями типа CP A,5 и ADC 0 - первую инструкцию по стандарту Zilog пишут CP 5, а вторую ADC A,0.
Скачал код из архива, запустил в EmuZWin, вроде вычисляется Пи, в памяти тоже Пи лежит. Всё это безобразие было написано в эмуляторе (причём Z80) без всякой CP/M, выгрузить кусок памяти в двоичный файл там можно, а в другие форматы нет. На всякий случай положил картинку в архив и 4 дампа для 100, 300, 1000 и 4000 цифр, но как их преобразовать во что-то загружаемое я не знаю.
5958959587
Самое забавное, что для большого количества цифр данный алгоритм можно еще ускорить, если и оставшееся деление(на нечётные числа которые присутствуют в разложении арктангенса) делать по таблицам, в теории можно получить ускорение в 1,5-2 раза.

litwr

30.01.2017, 18:48

У вас в исходнике на ассемблере после DIV_15: стоит LD HL,$4300, а в дампе вместо $43 - $56. Кроме того,расхождение в константах после INIT103: и INIT239: . :(
EDIT. Подставил константы из дампов и заработало! :) На Амстраде 1000 знаков за 30.8 секунд с печатью через медленный БДОС. Затвор тут в 6 раз тормознее. Но можно быть добрее и прописать константы в исходник, например, PI_LEN = PI_DIGITS/2+1+X... Еще бы убрать лишние цифры, которые, как правило, неверные.
Но в целом получилась очень хорошая программа. Так и до формул Чудновских можно дойти. :)

blackmirror

30.01.2017, 22:16

litwr, после DIV15 там просто индикатор прогресса, в какой-то момент я решил что лучше его разместить между строками, чем затирать цифры. А вот с INIT могут быть и проблемы, или это просто массивы куда-то переехали.
Лишней цифрой обычно оказывалась только последняя, которая живёт в одном байте с правильной предпоследней, поэтому мне было лень из разделять.
От Чудновских никаких плюшек ждать не стоит, у них тоже квадратичная сложность, и хоть за один проход они дают по 14 цифр, но там факториалы и на каждом шаге они дают десяток множителей/делителей которые не засунешь в таблицы. Два деления на 239, два на 103 еще одно на 25 и вычитания в сумме занимают меньше тактов чем одно честное деление для n>256, поэтому прорыв теперь может быть только с удвоением числа правильных цифр на каждом шаге, но не факт что это случится для менее чем 10000 цифр.

По просьбам трудящихся версия программы на Си, максимально упрощённая, но с некоторыми намёками в какую сторону оптимизировать:
59590

litwr

30.01.2017, 23:17

Уважаемый blackmirror, благодарю вас за исходники на си и ещё раз за саму программку. Но вопрос остался, всегда ли X = 0? В ваших экранных картинках на 1000 знаков печатается 4 лишние знака. Немного раздражает, поэтому использовал счетчик по числу цифр, чтобы печатало точное число знаков - это всего 24 тактa на сдвоенную цифру, зато чисто. При расчете 3000 знаков время вывода на экран медленными средствами ОС - это всего около 3%. А средства ОС позволяют, например, записать результат в файл. Шрифт 5х4...
Хорошо бы приспособить затвор к 100-ичной системе, тогда получили бы более дружественный алгоритм и с такой же как и по Мачину скоростью. В затворе только одно деление...

blackmirror

31.01.2017, 00:26

litwr, что касается точности, то в начале мы имеем целые числа, когда мы их делим на 103 или 239 мы получаем почти точные числа, ошибка представления которых не превышает единицы последнего разряда. При последующих делениях эта ошибка уползает в более младшие разряды и дальше роли уже не играет, то есть можно считать что все слагаемые представлены с точностью до единицы последнего разряда. Когда из 32/10^n вычитается 40/239^n и 160/515^n здесь ошибка уже может быть от -2 до +1 единиц, но далее идёт деление на n, которое опять сделает ошибку не более единицы младшего разряда. В общем точность результата зависит от того, сколько слагаемых суммируется, для 100 цифр берётся 50 слагаемых, и при неудачном стечении обстоятельств в теории ошибка может достигать 50 единиц, но в среднем мне кажется из этой цифры нужно извлечь корень. А может еще и на два поделить, поскольку ряд знакопеременный.
А на затвор возлагать очень большие надежды не стоит, там во первых нужно обработать все байты числа, а во вторых сделать это столько раз, сколько в нём бит, тут даже с одним делением получается больше чем у Мачина.

blackmirror

05.02.2017, 00:35

Поскольку в теме про Быстрое умножение на 10000 (http://zx-pk.ru/threads/27352-bystroe-umnozhenie-na-10000.html) мой алгоритм раскритиковали:

Приведен пример красивого алгоритма. Если посмотреть на него в контексте расчета π, то мне кажется, что уважаемый blackmirror реализовал не самый быстрый расчёт
пришлось его допилить. Без потерь не обошлось, и для 100 цифр он стал считать медленнее, но для 300 цифр ускорился в полтора раза, а для 1000 и далее в ДВА (офигеть!). Если посмотреть любимую нашу табличку (http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html), то затвор на MSX показывает в 10 раз худшие результаты, а Мачин позволяет приблизиться к microPDP-11/83 и Commodore SuperCPU-64(кстати, есть ли у них аппаратное умножение?). Самый интересный результат может получиться, если запустить Мачина на MSX turbo R, хотя это будет совсем не спортивно.
В архиве программка на 4К цифр, и две картинки с результатами для 100,300,1K-10К цифр(более 4К цифр может считать другая версия), время вывода не учитывается, поскольку pi не влезает на экран.
59646

litwr

07.02.2017, 13:26

Потрясающе! А ещё если заоптимизировать, то ещё можно почти наверняка 10-30% выжать. На отстойном 65816 нет аппаратного умножения. Но если переписать вашу программку на другие платформы, то опять получится картинка как и по затвору. Подозреваю, что формула типа 48·arctan(1/49) + 128·arctan(1/57) − 20·arctan(1/239) + 48·arctan(1/110443) будет ещё быстрее. Немного истории http://www.ams.org/journals/mcom/1962-16-077/S0025-5718-1962-0136051-9/S0025-5718-1962-0136051-9.pdf Следующий шаг - 100000? Кстати, кое-кто научился делать арктангентсы без деления - https://www.msx.org/forum/msx-talk/development/8-bit-atan2?page=0

blackmirror

07.02.2017, 20:58

Самое неоптимальное там это прямое деление, но оно используется только для 19% множителей, а по количеству обрабатываемых байт это вообще 3.5%, но если его ускорить с 400 тактов до 300, то перейти на него можно будет раньше. Как по затвору точно не получится, поскольку по числу операций родственник затвора это формула atan(1/2)+atan(1/3), а в ней делить на N нужно в 3.22 раз больше. Сейчас по общим затратам времени:
формирование 32/10^n - 2% (в общем почти даром)
вычисление 40/239^n с инверсией - 18%
вычисление вычисление 160/515^n с вычитанием - 23% (хоть таких слагаемых и меньше, но дополнительное деление на 25 и честное вычитание дают о себе знать)
деление на N занимает - 43% (по прежнему самая затратная операция)
добавление к pi - 15% (нужно бы развернуть все вычитания, но лень)
Увеличение первого делителя до 49 позволит сократить количество последних двух операций на 40%, то есть выиграть 25% от общего времени, но если оставаться в 100-ой системе, то по прикидкам деление на 49 займёт 28% времени, а еще нужно делить на 110443 и в итоге мы полностью пролетаем. А искать арктангенсы без деления у нас не получится, поскольку числа существенно длиннее.

litwr

11.02.2017, 23:41

Писал о том, что если взять любой алгоритм по числу π и перенести его на разные платформы, то результат будет примерно такой же как и по затвору. Основательно с Мачином разобрались. Прямое деление за 300 тактов?! Это сколько разрядов в делителе и делимом? Неужели 16 и 32?

blackmirror

12.02.2017, 00:37

litwr, Ну для других алгоритмов такой обширной таблички пока еще нет, кроме того для разных машин могут быть удобны разные формулы Мачина.
Ну а для i8080 перед делением 16 разрядный остаток по таблице умножается на 100, получается 24 разряда, к нему добавляется очередная цифра, далее старшие 16 бит делятся при помощи 8 блоков ADD HL,HL/ADD HL,DE/JR C,XXX/ADC A, которые выполняются за 33/38 тактов, ну а в конце добавляется оставшийся байт и за примерно 400 тактов получается новый остаток.
Корректно деление работает только с остатками до 2^14, чего при выбранной формуле хватает для вычисления 16000+ десятичных цифр, но тогда для табличек места не остаётся. Основной упор алгоритм делает на табличное деление: числа 239 и 103 хороши тем, что они больше 100 и влезают в байт, поэтому после сложения сразу ясно нужна ли коррекция. Число 25 кратно 100, что тоже упрощает деление, а вот деление на 57 не настолько удобно, поскольку в некоторых случаях требует дополнительную проверку и коррекцию остатка и частного. За счёт использования 100-ой системы деление на 239^2=57121 выполняется примерно за 120 тактов на байт, а деление на 515^2=265225 выполняется примерно за 170 тактов на байт.

ivagor

12.09.2017, 11:31

Тему после перерыва практически не читал, только последнюю страницу. Похоже есть значительные успехи, но сложно с ходу сориентироваться, на сколько конкретно.
Обращу внимание, что в pi_4k.zip blackmirrora написано "использует только инструкции 8080". При беглом просмотре увидел несколько инструкций, уникальных для z80, т.е. просто откомпилировать и запустить на 8080 не получится.

zebest

21.02.2018, 01:25

Очередная и, надеюсь, последняя версия spigota - pirk20.zip
100 знаков - 19897238 тактов - 11.19 сек (это с расчетом таблицы!)
535 знаков - 551337754 тактов - 5 мин 10 сек

PVV по моей просьбе портировал этот код от уважаемого Ivagor-a на суперсовремённый югославский компьютер.:v2_dizzy_botan:
Хоть код и для 8080, но на Z80 работает аналогично, да и интересно было сравнить совершенно разные архитектуры на одном коде :-)
Как раз таки видно, насколько сильно тормозится более лучший Z80 с программной реализацией видео-контроллера( вернее отъедается производительности процессора на эту самую реализацию). Итак, результаты для 535 знаков:
1. PVV -
8.45 время выполнения теста на моем реале. кварц 6.144, тактовая Z80
6.144/2
2. на моем не-реале тот же тест - 8:35 в обычном режиме, и 4:18 - в Турбо х2 ( но и частота процессора немного выше - 3,125 МГц)
3. В эмуляторе от b2m - 8:44 - вполне сопоставимо.

Все познаеЦЦа в сравнении. Мой текущий компьютер считает миллион знаков Pi за 14.437 секунды. На одном ядре разумеется.
http://s2.micp.ru/XYdl3.jpg

Дополнение.
100 знаков - 20с стандартно, и 6с с отключенными прерываниями и соответственно экраном.
и да, 535 знаков с отключенным экраном считается за 3 минуты, все же сильно видеовывод тормозит проц.

zebest

04.03.2018, 02:04

PVV по моей просьбе портировал этот код от уважаемого Ivagor-a
на этот раз на совсем другой компьютер 1977 г.р. Tandy Radio Shack TRS-80 - Model 1, собранный на горячо любимом Z80 c тактовой частотой всего 1,77 МГц, (практически Радио-86РК :)
Итак, встречаем! PI80 с инструкциями only 8080 посчитал 535 знаков за , ВНИМАНИЕ! - за 5 мин 17 сек.
Но и это еще не все.
Тот же компутер, но с программой оптимизированной под Z80 те же 535 знаков посчитал за 2 мин 04 сек
И еще одна программа-рекордсмен посчитала те же и там же всего то за каких то 47 сек
ну и напоследок, авдруг.
Эти две программы, с эмулятором, (в нем я не пробовал, но думаю сопоставимо), а главное с исходниками и комментами не на нашем языке можно посмотреть тут в самом низу страницы.
http://ht.homeserver.hu/html/programprojekt.html

Lethargeek

04.03.2018, 04:02

на этот раз на совсем другой компьютер 1977 г.р. Tandy Radio Shack TRS-80 - Model 1, собранный на горячо любимом Z80 c тактовой частотой всего 1,77 МГц, (практически Радио-86РК
Итак, встречаем! PI80 с инструкциями only 8080 посчитал 535 знаков за , ВНИМАНИЕ! - за 5 мин 17 сек.
Но и это еще не все.
Тот же компутер, но с программой оптимизированной под Z80 те же 535 знаков посчитал за 2 мин 04 сек
И еще одна программа-рекордсмен посчитала те же и там же всего то за каких то 47 сек
Глянул код. Ну как тут не вспомнить бессмертное: :v2_dizzy_biggrin2:

Если уровнять эффективные такты Z80 и КР580, то выяснится, что большое превосходство Z80 сильно преувеличено. Программа Z80 не превзойдёт по скорости программу на КР580 более, чем на 10%. И это в идеальном случае. Но такого никогда нет, программы Z80 на 98% состоят из команд КР580. Альтернативные регистры ничего не дают, избавляя от лишних PUSH-POP и ускоряя тем самым на несколько процентов. JR команды тоже дают выигрыш всего на несколько процентов. IX IY вообще не дают никакого выигрыша по скорости. Из-за префиксов все Z80-команды тормозные. И польза от них только в облегчении программирования, а не в ускорении. Так, что если на КР580 подать такт на 10% выше, то он не уступит Z80.

Да и litwr здесь, получается, был неправ, говоря о бесполезности дополнительных 16-битных команд Z80.

ivagor

04.03.2018, 07:03

PI80 с инструкциями only 8080 посчитал 535 знаков за , ВНИМАНИЕ! - за 5 мин 17 сек.

Тот же компутер, но с программой оптимизированной под Z80 те же 535 знаков посчитал за 2 мин 04 сек

И еще одна программа-рекордсмен посчитала те же и там же всего то за каких то 47 сек
Самое интересное - исходник для 8080. Или с приведенными для z80 программами сравнивался spigot для 8080? Если так, то выигрыш может быть и побольше.

zebest

04.03.2018, 09:53

Самое интересное - исходник для 8080. Или с приведенными для z80 программами сравнивался spigot для 8080?
ну да, spigot и сравнивался. PVV нашел и совместил точки входа в процедуры клавы и печати символов на экран для TRS-80.
Остальное родное для кода Радио-86РК. Кстати команды Монитора в TRS-80 удивительным образом похожи на команды в РК86. Или наеборот. С чего бы? А нужно было все это для тестирования памяти и выравнивания скоростей этого монстра относительно эмулей. Две другие программы, сравнительные:), нашлись значительнее позже.

ivagor

04.03.2018, 10:02

ну да, spigot и сравнивался.
Сравнивая разные реализации разных алгоритмов можно много чего намерить. Если постараться и подобрать алгоритмы, то разница и на порядки получится, причем в любую сторону, в зависимости от предпочтений экспериментатора.

litwr

10.03.2018, 12:12

Да и litwr здесь, получается, был неправ, говоря о бесполезности дополнительных 16-битных команд Z80.
В таких доказательствах z80 ARM в раза в 3 обгонит. У Z80 для арифметики хороша ADC 16-битная и сокращенные тайминги (на 25%) на многие однобайтовые команды - всё остальное для производительности значит мало.
А, кстати, деление уважаемого ivagor упомянуто в недавней публикации - https://geektimes.ru/post/298735

Lethargeek

10.03.2018, 15:13

В таких доказательствах z80 ARM в раза в 3 обгонит. У Z80 для арифметики хороша ADC 16-битная и сокращенные тайминги (на 25%) на многие однобайтовые команды - всё остальное для производительности значит мало.
Дело не в обгоне совсем, а в том факте, что в оптимизированном коде их применяют. Значили бы мало - не применяли бы.

- - - Добавлено - - -

А, кстати, деление уважаемого ivagor упомянуто в недавней публикации - https://geektimes.ru/post/298735
Прочитал, смешная статья, будто лет 15-20 назад написана, до распространения интернетов.
Ну, и моменты вроде критики двух стеков "сам не знаю, почему" - это :v2_dizzy_facepalm:

litwr

11.03.2018, 14:02

Дело не в обгоне совсем, а в том факте, что в оптимизированном коде их применяют. Значили бы мало - не применяли бы.

3агадками говорите. Это какие коды, которые не ADC и не однобайтовые с сокращенными таймингами?

Lethargeek

11.03.2018, 15:45

3агадками говорите. Это какие коды, которые не ADC и не однобайтовые с сокращенными таймингами?
никаких загадок - вестимо, те, которые по ссылке (http://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=952787&viewfull=1#post952787) нашлись в исходниках

ivagor

11.03.2018, 17:55

деление уважаемого ivagor
Признаюсь, статья длинная, не осилил, может потом почитаю. Если речь про деление из последних версий spigot для 8080, то тут нужно отметить автора алгоритма - blackmirrora. Ну а я только реализовал его алгоритм для 8080.

И еще пару слов про оптимизацию для z80. Эта (http://ht.homeserver.hu/projekt/pi/pi.asm) реализация Мачина считает 535 цифр медленнее, чем Мачин blackmirrora (http://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=900199&viewfull=1#post900199) считает 1000 цифр. Но у венгерского товарища есть преимущество - с его исходником легче работать.

В завершение - это (http://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=840271&viewfull=1#post840271) отнюдь не самая быстрая версия spigot для 8080, просто потом я оптимизировал только для вектора, т.к. пообещал не трогать другие компы.

- - - Добавлено - - -

Самый быстрый spigot для 8080 здесь (http://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=849604&viewfull=1#post849604).

- - - Добавлено - - -

Нужно еще отметить, что у венгра "классический" Мачин с двумя слагаемыми, а у blackmirrora - с тремя, но венгра же никто не ограничивал.

Lethargeek

11.03.2018, 18:06

И еще пару слов про оптимизацию для z80. Эта реализация Мачина считает 535 цифр медленнее
так её-то автор оптимальной и не назвал

- - - Добавлено - - -

Нужно еще отметить, что у венгра "классический" Мачин с двумя слагаемыми, а у blackmirrora - с тремя, но венгра же никто не ограничивал.
то есть, по сути, замечание к оптимизации именно под конкретную модель процессора не относится :rolleyes:

ivagor

11.03.2018, 18:11

Тем более не стоит сравнивать эффективность систем команд 8080 и z80 на примере разных алгоритмов (даже не модификаций одного алгоритма).

Lethargeek

11.03.2018, 23:39

Тем более не стоит сравнивать эффективность систем команд 8080 и z80 на примере разных алгоритмов (даже не модификаций одного алгоритма).
зато вполне можно сделать вывод об эффективности по востребованности новых команд z80
если их при оптимизации применяют - значит, с ними эффективнее, чем без них
несогласные могут попытаться переписать исходники z80 в более быстрый код 8080 (удачи им)))

ivagor

12.03.2018, 06:44

зато вполне можно сделать вывод об эффективности по востребованности новых команд z80
если их при оптимизации применяют - значит, с ними эффективнее, чем без них
Сделать вывод об эффективности команд можно при сравнении процедур, реализующих один алгоритм и оптимизированных соответственно для 8080 и z80. В сравнении (http://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=952787&viewfull=1#post952787) разные алгоритмы + и там и там далеко не самые оптимизированные процедуры. Т.е. то сравнение нельзя использовать для формулирования конкретных выводов об эффективности (какие команды и на сколько эффективнее). А общие слова "некоторые новые команды z80 эффективнее 8080" стоят мало, с ними никто и не спорил (в конверсиях z80->8080 постоянно возникала проблема переделки критичных мест, если там используются уникальные возможности z80).

Lethargeek

12.03.2018, 09:32

в конверсиях z80->8080 постоянно возникала проблема переделки критичных мест, если там используются уникальные возможности z80
то есть новые возможности хороши как раз для критичных мест, читд :D

NEO SPECTRUMAN

31.05.2019, 16:49

Если учесть, что тест в принципе один и тот же, только отличается в выводе символов на экран, то вышеприведеннайя Галаксия по сравнению с Юпитером - уж очень сильно тормознутая.
хоть генерацию видео на момент расчета выключали? :)

HardWareMan

31.05.2019, 20:48

ps - откуда лишний спролер - не знайю :(
Знаешь, но не придаёшь значения. Ты пофигительски относишься к тэгам, я вижу у тебя перехлёст нескольких, которые нельзя так использовать.

HardWareMan

01.06.2019, 08:28

zebest, а ты не нервничай, аппетит пропадёт. Вчера я просто нажал "цитата" и увидел, что тэг COLOR у тебя закрывался следом за открытием SPOILER. Сам SPOILER в цитате был один, но предпросмотр порождал два, как в твоём сообщении. Я перенёс закрытие тэга COLOR до открытия тэга SPOILER и всё починилось. А вот правильная расстановка тэга это ответственность пользователя. Например, для чего ты поставил тэг COLOR#000000? Это чёрный цвет и он по умолчанию.

HardWareMan

01.06.2019, 18:10

Да успокойся ты. Все уже поняли, что ты ничего не делал (https://lurkmore.to/%D0%AF_%D0%BD%D0%B8%D1%87%D0%B5%D0%B3%D0%BE_%D0%BD %D0%B5_%D0%B4%D0%B5%D0%BB%D0%B0%D0%BB), оно само.
https://jpegshare.net/images/28/3b/283b0e24792c7b1e54441dd0e6f0d6e9.jpg

PS Поменьше пользуйся этими кнопочками и будет всё ОК. Лучше вводить те немного полезных тэгов руками.
https://jpegshare.net/images/09/a7/09a78464caf4f3ceafe9a4d495c6ad01.png

ivagor

25.01.2024, 17:02

В дополнение к spigotам (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=849604&viewfull=1#post849604) 100 и 1000 для вектора
3000 цифр - 2661.12 секунд = 44 минуты 21.12 секунды

ivagor

31.01.2024, 18:20

Новая версия для вектора. Она в основном ориентирована на 3000 цифр, но заодно посчитал 100 и 1000 (их расчет можно оптимизировать):
802598026080261
100 цифр - 2.84 секунды
1000 цифр - 251.78 секунды = 4 минуты 11.78 секунды
3000 цифр - 2250.82 секунды = 37 минут 30.82 секунды
Чей код, алгоритмы или идеи использованы в программе:
b2m - первый (по крайней мере на форуме) перевел spigota с С на ассемблер 8080 и сделал версию для РК86. Элементы каркаса его программы до сих пор присутствуют в коде для вектора.
blackmirror - предложил оптимизацию алгоритма деления.
litwr - идея замены умножения из его коллекции spigot (автора идеи не знаю) позволила заметно ускорить текущий вариант.
svofski - совместная процедура вывода символов в режиме 512.

ivagor

10.02.2024, 14:16

ПК-6128Ц позволил поставить рекорд по количеству цифр Пи для 8-битных ретрокомпьютеров - 8928! Ну и скорость по сравнению с 06Ц повыше за счет ВМ85.
803408034180342
803438034480345
100 цифр - 2.34 секунды
1000 цифр - 207.18 секунды = 3 минуты 27.18 секунды
3000 цифр - 1855.32 секунды = 30 минут 55.32 секунды
8928 цифр - 17150.96 секунды = 4 часа 45 минут 50.96 секунды
Для 8928 цифр пришлось увеличить число экранов до 3 (по окончанию расчета переключаются клавишами '1'-'3'). Зато раз уж 3 экрана, то цифры можно сильно не ужимать, 6 и 9 здесь "широкие".

ivagor

12.02.2024, 17:12

litwr

12.06.2024, 16:56

Немного дополню. Ранееприведенный spigot для 6128 ставит рекорд по количеству цифр среди известных мне программ. Однако существуют могучие 8-битные ретромашинки, которые способны посчитать в разы больше цифр, но таких программ для них (пока?) не написали. Более того, можно посчитать больше цифр и на 6128, но скорость уменьшится.
После версии для 6128 сообразил, как резко увеличить число цифр для 06Ц (без квазидиска или других расширений памяти) при сохранении возможности проверки всех цифр. 8192 цифры - рекорд для 8080 среди известных мне программ, хотя есть компы с 8080 у которых больше памяти и они в принципе могут превзойти. Эта версия еще и чуть быстрее, поэтому две предыдущие (57 и 59) удалил.
Особенности отображения цифр - до трех экранов (по окончанию расчета переключаются кнопками '1'-'3'), причем на первом цифры занимают только правую половину. При расчете 8192 цифр в левую часть экрана залезает конец буфера, но потом эта половина очищается от "мусора".
Привожу скриншоты только для 8192 цифр, в архиве бинарники (и исходник) для расчета всех вариантов.
803668036780368
100 цифр - 2.78 секунды
1000 цифр - 238.94 секунды = 3 минуты 58.94 секунды
3000 цифр - 2134.18 секунды = 35 минут 34.18 секунды
8192 цифры - 16947.38 секунды = 4 часа 42 минуты 27.38 секунды

Впечатляющий результат! 10-летний распил затворного алгоритма привел к созданию чего-то почти шедеврального. Одноко слово "почти" совсем не лишнее. Автор похоже как всегда не смог избежать соблазна использовать сомнительные трюки, похожие на мелкое шулерство, в частности:
1) трюк издевательства над пользователем путём показа ему мелкомелких цыфирок. Нормальные цифры замедлили бы расчет совершенно незначительно и особенно для большого числа знаков;
2) использование какого-то ненастоящего алгоритма-затвора, в настоящем алгоритме Вагона-Рабиновича на цифру числа π должно выделяться ровно 7 байт;
3) в отсутствие алгоритма на ЯВУ, в отличие, например, от blackmirror, который выложил сначала свой супербыстрый алгоритм (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=897435&viewfull=1#post897435) в общем виде.
А тем временем британцы начали проект (https://www.stardot.org.uk/forums/viewtopic.php?t=29301) других затворов. Мачина они явно с этим догнать не смогут, а вот перегнать код для Вектора скорее должны.

ДОПОЛНЕНИЕ. Поспешил с претензиями 2 и 3 - это похоже тот самый затвор, извиняюсь. Но такое большое количество цифр сбивает с толку. Респект Вам ivagor, но цифирки можно и побольше.

litwr

06.07.2024, 20:00

ПК-6128Ц позволил поставить рекорд по количеству цифр Пи для 8-битных ретрокомпьютеров - 8928!

Англичане на своей бибисишке с 32 КБ ОЗУ смогли высчитать 16200 цифр за примерно 7.4 часов. Но Мачин уважаемого blackmirror'a пока в 4 раза быстрее на 1000 знаков. Однако Вектор они обогнали во всём как абсолютно, так и относительно. Особенно хорошо они всё оформили, прямо хоть в энциклопедию!
Коды уважаемого ivagor'a спровоцировали моё желание улучшить свой порт для компьютеров на базе 8080. В результате получился код более чем на целый процент быстрее, чем у уважаемого ivagor'a, - сам этому удивился, так как часть его кодотрюков до сих пор не понял. Не понял, в частности, что он cделал с делением уважаемого blackmirror'a - сам его просто закопипастил.
Итак, на 3000 цифр версия 61 кода уважаемого ivagor'a требует 2278 секунд, а версия 6 кода litwr'a - 2254. Запускал не исходную программу уважаемого ivagor'a, а её модификацию под СР/М или Монитор. Этот модифицированный код прикрепляется. Из-за плохого знания клинописи на 8080 перевел также её на более привычный язык Z80.
Таким образом, исходный код для bare metal от уважаемого ivagor'a по прежнему абсолютный Вектор-чемпион по затвору Вагона-Рабиновича, но это не из-за превосходного качества кодов, а из-за выбранной системы, точнее отказа от любой операционной системы. За bare metal процедуру печати мелких циферок ускорение всего-то менее полпроцента на 3000 знаков, а вот кастомный мини-обработчик прерываний даёт заметный прирост в более 6%.
Сам хотел сделать такой обработчик, но монитор не делает скроллинга без стандартного тормозного обработчика. А делать bare metal с нормальным шрифтом пока не готов, не считаю себя ещё истинным вектористом. Но если делать, то цифр должно бы получиться чуть больше (на несколько десятков), чем у уважаемого ivagor'a.
К сожалению, так и не понял, как использовать деление уважаемого blackmirror'a для отрицательных делителей, поэтому использовал код, который возможно хуже, чем у уважаемого ivagor'a, но этот код задействуется только при числе цифр большем 4680, что не входит в таблицу результатов. Однако, буду признателен за подсказки. Стараюсь собирать в проекте только лучшие коды.
80969

ivagor

18.07.2024, 20:03

Еще немного ускорил и сократил версию для вектора. Уменьшение размера программы позволило увеличить ширину цифр 6 и 9 при сохранении возможности расчета 8192 цифр пи, что резко повысило удобство чтения результатов. 8192 цифры теперь на 4 экрана (после окончания расчета переключать кнопками 1-4) вместо 3. Версия 65 по всем показателям уступает, убрал.
100 цифр - 2.72 секунды
1000 цифр - 233.62 секунды
3000 цифр - 2087.26 секунды
8192 цифры - 16620.02 секунды

ivagor

25.07.2024, 17:07

CodeMaster

25.07.2024, 17:09

то можно еще немного ускорить.
Я всё жду, что в результате исследования тёмной энергии удастся преодолеть скорость света :-)

ivagor

25.07.2024, 17:12

ivagor

26.07.2024, 10:06

Сишный Мэчин blackmirrora, откомпилированный для вектора с использованием z88dk, правильно считает 3001 цифру за примерно 3780 секунд, что медленнее ассемблерного супероптимизированного spigota менее чем в 2 раза. Понятно, что ассемблерный Мэчин в разы опередит spigot на большом количестве цифр.

litwr

27.07.2024, 08:14

Если согласиться на уменьшение максимального числа цифр, то можно еще немного ускорить.
100 цифр - 2.70 секунды
1000 цифр - 231.90 секунды
3000 цифр - 2071.46 секунды
7172 цифры - 12256.14 секунды
В 67 максимум 3 экрана (кнопки 1-3), не 4.
В версии 66 можно ускорить расчет 8192 цифр, но результаты 100-3000 не изменятся, мне интереснее было подтянуть "базовые" цифры.

Да, опять обогнали мой код на целых 2%, нашел уважаемый ivagor возможность сократить 10-20 тактов. Надеюсь, что не раскруткой циклов.
Похоже, что благодаря усилиям ivagor'a тема может дать ещё много интересного. Как-то думал, что мой код для БК близок к оптимальному, но замечание ivagor'a заставили внимательнее с кодом поработать и получить ускорение в более 15%. Аналогичным образом удалось ускорить и код для z80, но только на чуть более 10%. А для 8085 почти на 32%.
Вместо самого быстрого алгоритма расчёта числа π фактически в этой теме были созданы наискорейшие алгоритмы деления для многих архитектур. Жаль, что алгоритм уважаемого blackmirror'a невозможно использовать на 6502. Для меня было неожиданно, что код для 8080 на Z80 лишь чуть-чуть на π-затворе медленнее, кода на всех инструкциях z80. Разница в смешных 3%. Хотя по размеру код для Z80 заметно меньше.
А скорее неприятным сюрпризом оказалось, что код деления для 8085, медленнее кода для 8080! Не понятно, почему уважаемый ivagor использовал для Вектора 128 код, где использует много EX DE,HL/ RL DE/ EX DE,HL - что намного медленнее ADD HL,DE. Может только для экономии памяти? Или для ускорения расчётов с отрицательным делителем? У меня в коде π-затворa для Tandy 100 удалось найти место только одной инструкции 8085. :( Там памяти всего менее 32 КБ, поэтому отрицательные делители не нужны.

ivagor

30.07.2024, 17:02

litwr

04.08.2024, 10:32

Перетащил в версию для 6128 (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=1194362&viewfull=1#post1194362) основные оптимизации из 66 (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=1201334&viewfull=1#post1201334). Тестировал в Emu и VV - результаты совпали.
100 цифр - 2.28 секунды
1000 цифр - 202.08 секунды
3000 цифр - 1810.82 секунды
8928 цифр - 16773.56 секунды
Ускорили на 2%, но если бы заменили тормозное деление с RL DE на то, что используете для 8080, то ускорилось бы процентов на 10.
Удивительно, как мало новые команды Z80 влияют на производительность: код затвора на Z80 менее 5% быстрее кода на 8080, исполняемого на Z80. Секретные команды 8085 получше, но они какие-то более узкоспециализированные.
А у британцев фантастический прорыв, более 50 тысяч знаков на машинке с 32 КБ! Они даже сделали визуализацию расчётов - https://www.youtube.com/watch?v=3iMsS2bpdeM

ivagor

08.08.2024, 17:02

Формула ББП позволила обновить рекорды по скорости и количеству цифр для вектора (и не только для вектора).
81090810918109281093
100 цифр - 2.28 секунды
1000 цифр - 191.86 секунды
3000 цифр - 1787.22 секунды
12527 цифр - 44704.10 секунды
Можно посчитать намного больше цифр, но надо или отказаться от сохранения всех результатов или поменять организацию их вывода.
В процессе оптимизации ББП заметил, как немного ускорить 66 и обогнать 67 без уменьшения максимального количества цифр, но с учетом результатов ББП в этом уже нет смысла.

ivagor

09.08.2024, 21:01

Формула Беллара еще быстрее
81099811008110181102
100 цифр - 1.48 секунды
1000 цифр - 177.62 секунды
3001 цифра - 1752.04 секунды
12526 цифр - 34041.22 секунды
Плавание величины выигрыша над ББП связано с разными порогами переключения процедур деления.

CodeMaster

10.08.2024, 10:53

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

Формула ББП позволила обновить рекорды по скорости и количеству цифр для вектора (и не только для вектора).

Ну, вот же, нет пределу совершенства. Или есть? А вдруг ты найдёшь последнюю цифру числа Пи и откроются основы мироздания ;-)

ivagor

17.08.2024, 18:25

Доработал вариант с формулой Беллара. Теперь считает и показывает больше цифр и делает это быстрее.
100 цифр - 1.48 секунды
1000 цифр - 171.18 секунды
3001 цифра - 1670.70 секунды
21001 цифра - 94543.72 секунды
81136
После расчета автоматом переключает на первый экран и можно выбрать клавишами
1 - цифры 1-3001
2 - цифры 3002-6001
3 - цифры 6002-9001
4 - цифры 9002-12001
5 - цифры 12002-15001
6 - цифры 15002-18001
7 - цифры 18002-21001
Время расчета, которое печатается на каждом экране - общее.
Можно посчитать больше цифр, но слишком долго, решил ограничиться пятизначным числом секунд.

litwr

18.08.2024, 19:35

ВВС Мiсrо и Beктop - чемпионы по числу знаков, наверное потому что названия начинаются с одинаковой буквы. :)
Но нежели суперзнаток Вектора не может сделать вывод с нормальным скроллингом, что позводило ли бы обогнать машинку с 32 КБ машине с 64 КБ? А так какой-то диссонанс, 21К знаков на 64 КБ и 50К знаков на 32 КБ... И по скорости есть вопросы. Хороший π-код для Вектора должен быть процентов на 50 медленнее, чем хороший код для Бибисишки, а он реально медленнее более чем на 100%...

ivagor

30.08.2024, 17:04

В итоге получилось преодолеть символичный рубеж - 25000 цифр быстрее 100000 секунд, предыдущую версию убрал.
100 цифр - 1.30 секунды
1000 цифр - 133.78 секунды
3001 цифра - 1240.98 секунды
25000 цифр - 96785.46 секунды
81182
Клавиши 1-7 как и были (https://zx-pk.ru/threads/25783-vychislenie-chisla-pi-na-assemblere.html?p=1202614&viewfull=1#post1202614), дополнительно 8 и 9:
8 - цифры 21002-24001
9 - цифры 24002-25000

ivagor

06.08.2025, 10:30

Отчасти оффтоп, т.к. программа на C, не на асме и по скорости очень далеко до рекордов, но там (https://www.youtube.com/watch?v=bVeXO_HuYEI) впервые вижу использование алгоритма Чудновского на 8080, потенциально интересно.

b2m

06.08.2025, 14:11

ivagor

06.08.2025, 15:04

Spigot ладно, он (8080 3 МГц) Чудновским считает 1000 цифр за 640 секунд и 10000 за 16 часов 35 минут, для С довольно неплохо.