[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The fastest 68k Amiga ever.... ??? Noooo :)



Teda Trodas, timhle mailem si me zcela vykolejil.

> > :-))))))))))))))))) Tak tohle me uzemnilo. Nejses to nahodou
> > zrovna Ty, kdo lpi jen na testech a ignoruje realitu ?
> Jenze moje testy jsou o necem jiym a na rozdil od tebe taky vim jak
> je interpretovat... :)
 Ano, ano....dokazujes to tu kazdou chvili.... Obzvlaste ty tvoje
interpretace,
ktery stavi 060 s ZII prez PIII s AGP jsou toho nejlepsim dukazem.

> >> do precompiled bufferu, a pak to vypada fast...
>
> > Promin, ale tohle je snad princip kazdeho JIT kompileru !
> > A to jestli se ti tam natahne test, nebo aplikace snad vyjde
> > nastejno ne ? Testy DoomAttacku to jasne dokazuji...
>
> ...me se to spis zda jako ze maj doblbany timer :))))
 Tobe se zda ???? No, tak to je dalsi dukaz presnosti tvych interpretaci...
btw nejak jsi neodpovedel na muj argument o JIT. Zda se ze
vubec nevis o cem se tu mluvi.

> > Jediny problem muze byt self-modify kod, ktery se ale nastesti dneska
> > uz nedela a i kdyz ho nekde pouzijou, staci pri flush-cache
> > rekompilovat cely kod. Jsou samozrejme i varianty relokacni tabulky
> > puvodni-novy kod, a pak muze modifikovat i kod. V 99.999% se
> > totiz modifikuje jen primy operand u instrukce...
>
> Jediny problem jsou jen realny aplikace. :)
 Hmpf ? O cem to tocis  ? Schvalne se pochlub, jakl je na tom 060 s
realnyma aplikacema ! treba s Lightwavem, nebo s Imaginem, kde se diky
absenci 32 bitovyho nasobeni plazi na 1/2 rychlosti P90 (pamatuju si
srovnavaci testy, kdyz se ta crappy 060 objevila na amize...)

> Odpovedel jsem tak pozde, protoze jsem si tu novou verzi s JIT compilerem
> overil sam ;))))  Tesny pekne (600Mhz PII), ale jinak sucks.
>
> Priklad? Jeden za vsechny.
 jeden priklad za vsechny ? Teda promin, ale TAKOVYHLE testy
si strc nekam. To je naprosto ubohy...

[blablabla...]
> Takze - KDE je ta rychlost???  Sorry, zadna neni...
 Ehrm. Porovnavas rychlost nacist/zapsat do vramky. Takze
nevim proc tu mluvis o rychlosti emulace CPU. Je to jen dukaz toho,
ze nemaj optimalizovanej framebuffer na linuxu. (opakuji na LINUXU !
protoze WinUAE s JIT neexistuje... zacinam mit pocit, ze cely ty tvoje
"testy" jsou normalni mlzeni)

> >> Az pridaji podporu fpu/mmu a 060 kodu, a Ride pojede svizneji
> >> tak to bude stat za to. Jinak je to spise k nicemu nez pouzitelne
> >> rychly...
>
> > :-)))))))))))))))) K cemu potrebujes na Amize MMU ???????
>
> Pokud to nevis, tak nestojis za psi stek.
> Neidvim se, ze Elforce je tak padavy a tvoje Amca byla taky...
> A optimalizace bufferu ti taky asi nic nerika, takze MMU jsi zrejmne
> nepochopil... :(
 Btw muzes mi vysvetlit, proc me v kazdym druhym tvym mailu
napadas za enforce a za padavost amigy ? Docela me s tim uz zacinas
srat a jak tu Snappy poznamenal, moc to nekoresponduje s tim, co
tu blejes o slusnym chovani. Rekl bych naopak, ze ses docela dobrej
priklad bezcharakterni stracky.

Jinak s tou optimalizaci bufferu - necachovany framebuffer neprinesl
VUBEC zadny zrychleni (ani na 060) a dokonce i clovek co s tim prisel myslim
v ADoomu to tam sam pise, ze jde spis o teoreticke zrychleni. Takze
promin, ale mam realny zkusenosti - se svyma predstavama bez do haje.

A co se tyce tech MMU hacku na ochranu pameti - promin, ale jak
jsi sam rekl, nejsi programator, takze tezko mi tu budes vypravet o
pohodlnosti vyvoje na systemu, ktery nema standartne ochranu pameti
a propojeni treba na debugger. Takze to ze mi behem spusteni zacne
posilat miliardy hitu do CONu a tim zablokuje amigu mi ve vyvoji
opravdu nepomuze. Mozna by ses mel priste tomuto tematu vyhnout,
jinak te rozmazu jak hovno.

> > FPU je no problem (ostatne tam nikde neni zminka o tom, ze by to
> > FPU neumelo)
> Hmmm, jen aby... ;)
 Jen aby ? Dojmy dojmy dojmy.... Opet dalsi dukaz jak jsou tvoje
testy "podlozeny".

>
> > A co je nejvetsi bomba - CO TO PROSIMTE JE 060 KOD ???????
>
> Jednoduche na vysvetleni. Je to vlastne kod, napsany optimalne pro
> obe dve instrukcni a jednu FPU pipelinu 060, a je dobry myslet na
> branch cache... ;)  Vlastne HODNE predrbany 040 kod... ;)
>
> > Jakmile mas instrukcni sadu 020, tak ses na tom lip nez 060,
> > ktery chybi 30% integer aritmetickych instrukci
>
> Predpokladam ze nejsi v poradku.
> 060 opravdu CHYBI JEDNA JEDINA instrukce, a to je CMP2...!!!
> Je fakt, ze jsem ji tusim JEDNOU videl pouzivat... Na starfield - pekne
> lame... :)
 Ja snad spatne vidim ???? JEDNA instrukce ?
A co treba
    muls.l    d0,d1
    mulu.l    d0,d1
    muls.l    d0,d1:d2
    mulu.l    d0,d1:d2
    divs.l    d0,d1
    divu.l    d0,d1
    divs.l    d0,d1:d2
    divu.l    d0,d1:d2
Teda promin, ale "procesor" ktery neumi vynasobit 100000 x 100000 nema
v pocitaci co delat. Docela me prekvapuje, ze tady takhle otevrene LZES,
presto
ze jsme o tomhle uz mluvili nekolikrat.

na FPU chybi i oproti uz tak orezany 040 FPU jeste

    FDBcc (fdbne,fdbeq,fdbra,fdblt,fdbgt,fdble,fdbge)
    FScc (fsne,fseq,fslt,fsgt,fsle,fsge)

Jestli povazujes operace pro cyklus a porovnani za zbytecny, pak sorry...

> Tech 30% je vyblitek tvyho vysumnenyho mozku, nebo co...
 Opet me bezduvodne napadas. Jses proste bezcharakterni sracka a muzes si
povidat o moralce co chces. Ostatne nejsem sam, kdo to takhle vidi.

> Jiste, zretezeni registru neumi (nebo jinak, umi, ale pomalu) - coz je
> pochopitelne - kdyz chces 64bitu preciznost, laskave pouzij FPU.
> Od toho tu je. Navic bezi paralelne... ze...
 neumi ani 32 bitu ! umi akorat 16bit x 16bit = 32 bit. A promin, ale 060
trva 7 taktu !!!! nez prevede integer do floatu. Mam vyplacat 14 taktu
pro kazdy nasobeni ? Nebo pocitat adresovy pointery v FPU ? :-) A
nejses to nahodou ty, kdo pouzivani FPU tak desne kritizujes ?
 Navic jen kvuli 060 ?

> > a 70% FPU instrukci !
>
> Proti cemu? 881/882? Jiste. Ale dovolim si pripomenout, ze 040 je na tom
> UPLNE stejne, ty...  Seber se, a nepis naprosty nesmysly, dik.
 Jiste ze proti 68881, protoze to byl standart 68k kodu. NIKDE jsem
nepsal nic o 040. Takze prosim, nepis tu naprosty nesmysly.
Jinak tedy to same co jsem rekl k impotenci v integer operacich
muzu zopakovat k FPU - takovy ktery neumi ani sin/cos neni
zadny FPU a vyrobce si ho muze vrazit mezi pulky...

    regardz, Fido