OldComp.cz

K době běhu programu - v emulátoru mi to ukazuje čas výpočtu 3 hodiny 30 minut.

Na Sharpovi s ALU to zkusim az se k nemu dostanu. Zatim jsem cely tyden na sluzebce v matrixu, tak je pro me veskery realny hw mimo dosah
Jeste bude nejaky rozdil mezi skutecnou ALU pres realne obvody AM9511 nebo i8231, a nebo ALU kterou emuluje unikarta. Protoze tam Sharp vubec nemusi cekat nez ALU zacne vracet data. Rychlost vypoctu na ARMu pro Z80 znamena, ze ma vysledky temer okamzite.
Ale srovnani bude urcite zajimave.

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

O kolik by to urychlil přepis do ASM ? 3,5h je dost.

Tak jsem se pokusil ten BASICový prográmek trošku poladit ...

10000 míst za 5 sekund ?

https://www.youtube.com/watch?v=S_d7ULRyQVs

Aneb připojíme k 386 Teslu a poklepeme se po rameni jak je ta 386 najednou rychlá . Těším se na výsledky té Am9511 jaký rozdíl v čase u toho reálného HW bude . Je vidět že koprocesory mají smysl když se počítá floating matematika.

Ted by to jeste chtelo zrychlit to vypisovani, ktere zabere vetsinu casu

_________________
http://www.8bity.cz

Udivuje me, ze to jde tak rychle. Asi jsou tu mezi nami opravdu kouzelnici.

A az ted jsem si vsimnul, ze jsem ve svém prispevku popsal pouzitou rovnici spatne, spravne ma byt:

16 * arctg(1/5) - 4 * arctg(1/239)

To Pí je jen na 10 000 míst a když ho počítá koprocesor virtualizovaný na moderním hardwaru... Z80 by to počítalo hodiny a hodiny. Čas lehce pod či kolem 7 sekund zvládají "velká" dnešní CPU na milion míst, tedy 70x rychleji . Ale moc se mi líbí ta možnost ten koprocesor k výpočtu vůbec využít.

Ja si dovolim to jeste trochu zamotat. On to je a neni koprocesor. Cele je to projekt od nobomiho, tak nevim kolik toho chce, kdy a jak 'odtajnit'. Predpokladam, ze to bude jedno velke tema na setkani v Talskem mlynu (viz jine tema). Cela tahle vecicka je mnohem chytrejsi a s Teslou nebo PC to nema nic spolecneho, ale to bych uz prozrazoval moc. Mel jsem tu cest si s tim uz pohrat a na rovinu - moc genialni napad a jeste k tomu prakticky realizovany.
Dalsi priklad pouziti je pri vypoctu fraktalu. Treba se nobomi taky pochlubi

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

Tak to jsem zvědavý co z toho nakonec vyleze . Ale už jen funkční emulace staršího HW na velmi slušné úrovni a běhající komunikace s 8bitem je velký úspěch pokud si to člověk stvoří celé sám. Škda že tam nebudu ale třeba něco prosákne i sem.

Tak jsem si také zkusil pí. Tentokrát v C na PC. Dřív jsem používal metodu Isaac Newton (pi = 6*arcsin(1/2), pi = 3 + 1/(2^3) + 3*3/(2^5*4*5)...), ale tahle Machinova formule vypadá také docela dobře.

Nejdříve jsem si zkusil řadu přes integer aritmetiku, modulo 1M (inspirace od lukz). Potom jsem naportoval program od lukze do C s double matematikou. Úplně jsem ho nepochopil , takže skončil jen u otrockého přepisu. Kupodivu funguje správně, i když nechápu jak, takže klobouk dolů před autorem. A nakonec jsem program přepsal do ATpadu - 8-bitový procesor ATmega328 s 2 KB RAM a krystalem 24 MHz. Kvůli málo RAM počítám jen 500 míst a výsledek v porovnávací tabulce přepočítávám (doba je úměrná kvadrátu počtu míst).

Přikládám programy ve 4 variantách - původní konverze od lukze, double aritmetika, int aritmetika a ATpad zdroják. Jsou tam připravené poveláky, které změří čas a zkontrolují výstup (pro kontrolu jsem si stáhnul z netu tabulku pí s 1M místy, se kterou to kontroluji).

download: https://www.uschovna.cz/zasilka/QB56ICRPAWIL5S2S-2KM/

Na PC (3.2 GHz) vypočítá 1M míst za půl hodiny až hodinu. Zajímavé, že s double matikou je rychlejší 32-bitová verze, ale s int matikou je rychlejší 64-bitová verze. ATpad (24 MHz) vypočítá pí na 1500 míst (resp. 9x 500 míst) za 25 sekund. (ten malý mikročip je tedy 5000x rychlejší než ten obrovský ENIAC ) Používá int aritmetiku s 8-bitovými registry. Hw podporu má jen 8-bitové násobení, ostatní se počítá softwarově. Časy v sekundách (na PC jsou časy 10 a 100 míst příliš krátké na měření):

A na kterém místě se liší výpočet podle jednotlivých formulí ?

Liší se v rychlosti iterace (přesnost je stejná = nekonečná), jak rychle klesají členy řady. Vzorec s arcsin má sice jednodušší výpočet (méně operací), ale iteruje pomaleji, tak by měl být výpočet trochu pomalejší (neměřil jsem).

Tak jsem rád, že se na ten program někdo další kouknul. Byla to trochu moje idea, že když to bude ve vysokoúrovňovém BASICu, tak to půjde snad snadno přepsat na jiné systémy.

Možná struktura programu není úplně jasná, tak přidám ještě vysvětlení.

Podobně jako na Eniacu, nejdříve vypočteme prvních pár desetinných míst od všech členů 16 arctg (1/5) i od všech členů -4 arctg (1/239). Tato desetinná místa se posčítají a uloží do pole R(). Pak se posuneme dál a počítáme desetinná čísla menšího řádu. A tak dále, dokud není všech 1506 míst spočteno. To se řeší v cyklu
FOR K=0TON, ukládání pomocí R(K)=S.

Nakonec musíme ještě provést jednu úpravu. V každém R(K) je jedna šestice desetinných čísel. Ale protože jsme sčítali hodně členů, tak i když každý z nich měl šest desetinných míst, výsledek součtu může mít i víc číslic. Musíme pak přenést nejvyšší číslice z nižšího řádu do nejnižších míst vyššího řádu, abychom dostali správný výsledek. To řesí ten další cyklus
FOR K=NTO0STEP-1, ve kterém se ukládá opravená hodnota R(K).

Například:
Číslice na konci už nejsou přesné, protože v tomto příkladu není zahrnuta hodnota z R(4).

To jsi sepsal jen podle toho všeobecného popisu, nebo jsi někde našel nějakou konkrétnější ukázku? Na netu jsem našel jen obecné vzorce k metodě, tohle bych z toho nevypotil. Dávkovat výpočty je zajímavé, i když stejně mi není jasné jaktože to funguje a neztratí přesnost.

Ty délky polí 316 a 1075 jsi nějak odvodil nebo to vzniklo zkusmo? Zkoušel jsem měnit a vypadají správně (zmenšení začne dělat chyby), jen teda nevím proč zrovna takové hodnoty.