Potřebuji nakopnout. Rozepsal jsem si v Pythonu emulátor procesoru i8080A a řeším problém s časováním. Jde mi o to, že potřebuji aby mi emulované instrukce trvaly stejnou dobu jako na originál procesoru. Vím, kolik procesorových "ticků" každá instrukce trvá, ale jak mám počkat s vykonáváním další instrukce až v určitý čas?
(Rychlost i8080A je 2MHz, nejkratší instrukce má 4 ticky, Python překvapivě zvládá na interpretr velmi dobře, potřebuju ho brzdit :)
Fórum › Python
Timing
Tak Myshaaku ještě jednou: tohle forum je více méně pro začátečníky, v urovni kurzu zde na Programujte. Jestli chceš mít alespon nějakou naději, že dostanes odpověd, zkusil bych to na http://www.py.cz/KonferenceDiskuze.
To geon: Ale já jsem taky začátečník! Programuju v Pythonu jen pár měsíců, jenom mě to chytlo a baví mě to, tak zkouším trochu zábavnější úlohy... Ale dobrá, už se tu ptát nebudu...
Napadá mě tahle prasárna:
import time
def pomalu(prikaz, ticku):
time.sleep((5.0 * (10.0**(-7))) * ticku)
exec(prikaz)
while(1):
pomalu("print \"jedu pomalu\"", 9**5)
Má to tu nevýhodu, že se to volá ve fci a zpomalení bude nepřesné, protože nevím jak změřit dělku trvání příkazu a samotných měřících procedur. Tato odchylka bude čím dál tím menší, čím bude stroj silnější(většinou to bude záležet na procesoru). Dále si nejsem stoprocentně jist jestli jsem správně spočítal periodu T(použil jsem google kalkulačku).
Takže otázka na Geona jak měřit čas trvání příkazu? U php to je jednoduché, ale u Pythona jsem zaboha nic nemohl najít. Sice bych si dokázal napsat vlastní, ale lepší asi bude hotové řešení, nejlépe v C.
To geon:timeit používám běžně, ovšem na porovnání, která cesta je rychlejší v případě, že existuje více možností jak daný problém řešit. Ale nějak nevím, jak ho použít v mém případě. Jsem rád geone, že lidi odkazuješ na dokumentaci a google, ale taková odpověď je mi s prominutím k prdu. Na google i v dokumentaci hledat umím, ale snažím se najít optimální cestu k vyřešení mého problému.
Děkuji tedy hlavně D1ce za konstruktivní příspěvek...
To Geon: promiň, nějak mi to uletělo, nemám dneska dobrý den :/
Mrkněte se prosím na následující kód:
import sys
import time
if sys.platform == "win32":
default_timer = time.clock
else:
default_timer = time.time
tt = default_timer()
tt = default_timer() - tt
print tt
#tam je zahrnuto pocet minimalnich ticku
print (5.0 * (10.0**(-7)))*4
print default_timer() - default_timer()
import timeit
t = timeit.Timer("default_timer() - default_timer()")
print t.timeit(1)
Myslel jsem si, že všechno v pohodě stihnu a změřím, ale vono prd! Můj procesor Intel Cleron 1.8Ghz. Možná je to tím, že mi na kompu běží minimálně 20 nesystémových služeb. Avšak co mě zaráží je že 1.8Ghz >> 2Mhz, že by Python sežral tolik výkonu? V php je výkon o jeden řád nizší, v céčku potažmo C++ je výkon přibližně totožný s Pythonem, díky implementaci měření založené na tatáž principu(měření v c sežralo 6 ticků).
To D1ce:zkusil jsem
ts = default_timer()
for i in xrange(2000000):
xx=i
te = default_timer()
print "rozdil", te - ts
s výsledkem: 0.667001532318
tzn., že v Python v pohodě zvládá smyčku o 2 milionech průbězích s jednoduchou operací sčítání za 0,7 vteřiny, což je slušné, v emulaci mi stačí čtvrtinový výkon, vzhledem k trvání instrukcí... A to je v čase započteno i samotné generování pole xrange
Jestli se se 1tick rovná 1Hz, pořád mi tam něco nehraje. Ani nevím kolik ticků sežere jeden průchod polem, ale vypadá to na slušné číslo. Už rozumíš co mi nehraje?
To D1ce: Abych pravdu řekl, netuším, kde co nehraje. Stačí si před instrukcí pčečíst čas a spočítat si, kdy má proběhnouit další a pak si prostě na ten pravý okamžik počkat. Nepotřebuju tudíž znát vůbec žádné časy, co mi která procedura sežere...
Asi nejlepší bude emulovat ten stroj přímo, tedy i hw né jen instrukce. Tak jako to dělá např. vmware, virtual PC, Dos bos apod.
To D1ce:
To je samozřejmě pravda a počítám s tím, jde o obsluhu portů a řešení přerušení 50Hz, jenže i to je lepší řešit počítáním délky instrukcí. Díky tomu totiž nemůže dojít k rozhození synchronizace v případě, že PC nebude z nějakého důvodu stíhat.
Myshaak píše:#
# To D1ce:#
#T jenže i to je lepší řešit počítáním délky instrukcí.
Když myslíš, ale jak dlouho tedy trvá instrukce, která sežere 4 ticky? Ať už se někam pohneme. Jestli je to tak, jak jsem spočítal já, výkonné PC má přibližně stejný čas! Možná i delší!
Díky tomu totiž nemůže dojít k rozhození synchronizace v případě, že PC nebude z nějakého důvodu stíhat.
Když PC nebude stíhat, tak se tomu nevyhneš ani kdybys dělal nevím co. Samozřejmě je plná emulace asi náročnější na výkon, ale to bude IMHO jen pár procent.
Jinak pokud máš know-how jak to dokonale naemulovat, tak proč se do toho nepustit?
Když PC nebude stíhat, tak se tomu nevyhneš ani kdybys dělal nevím co.
To je přece jasné :) Já jsem mluvil o synchronizaci procesor vs. přerušení (zde konkrétně 50Hz.) Pokud totiž vím, která instrukce jak dlouho trvá, vím přesně kdy vyvolat přerušení nazávisle na tom, jak dlouho bude emulace trvat.
V tuto chvíli mám hotovo cca 70% emulace procesoru. Jde to pomalu, protože za a) nemám na to tolik času a za b) občas je problém zjistit přesné chování té které instrukce (teď jsem k tomu účelu sehnal simulátor procesoru 8080 na úrovni jednotlivých mikroinstrukcí a stavů hradel, takže mi to práci trochu ulehčilo)... Až budu mít hotovou první kompletní verzi, určitě se s ní pochlubím :)
Přidej příspěvek
Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku
×Vložení zdrojáku
×Vložení obrázku
×Vložení videa
Uživatelé prohlížející si toto vlákno
Moderátoři diskuze