Dalsi zahada v C -> Prevod long int na string

[Milan B.]

On 25.7.2011 10:47, Jan Waclawek wrote:
>>
>> Aha, takze riesenim je asi vyplakavat po roznych forach.
>
> Svojim sposobom ano. Napriklad v tomto pripade to podla vsetkeho aspon ciastocne zabralo... ;-)
>
>
> To je sice pravda, ale v mojom oblubenom SDCC na mojej oblubenej platforme '51 je k dispozicii poltucet optimalizovanych verzii printf(), cim sa bud riesi povodny problem, alebo to itoa sa z nich da pomerne jednoducho vyoperovat.
> http://sdcc.sourceforge.net/doc/sdccman.html/node94.html
>
viz dalej
>
> Uprimne povedane si povodnu otazku nepamatam a odpovedal som na Vas posledny prispevok, kde to uz nebolo. Je mozne, ze som to odmazal ja sam kedysi pred tyzdnami. Moja strednodoba pamat je momentalne v takom stave, ze obcas ked chcem odpovedat na nejaku otazku, tak najprv guglim, ci sa neda odpovedat nejakym brisknym linkom a s hrozou zistujem, ze som na podobnu otazku pred nejakym casom pisal pomerne rozsiahle pojednanie, a vobec si to nepamatam... :-(
>
Tu som vas obvinil trochu nepravom (a tymto sa ospravedlnujem).... ono 
sa to vlakno rozpadlo na dve. Z pamate mi vyplavalo (vzhladom k nocnej 
hodine trochu nepresne), ze diskuzia zacala nejakymi problemami s printf 
a rychlostou ... ale vyvoj dskuzie bol neskor trochu klukatejsi.

Tiez som v podstate reagoval na posledny prispevok. Hlavne ako reakciu 
na tu bezradnost z toho, ze v podstate primitivna funkcie nie je v 
kniznici a co dalej ... a implementacia, ktoru som ponukol, nie je 
nepodobna beznym implementaciam....

> Takze ano, mate pravdu, treba si najprv overit, ze ci printf z kniznice nie je nahodou uz dostatocne vyoptimalizovane.
>
printf ma jeden vazny problem - a to formatovanie. Samotnym procesom 
formatovania sa mozno spotrebuje viac casu, ako prevodmi cisiel.

> Len to, ze to nesplnalo povodnu predstavu, t.j. implementaciu bez 
> delenia. Naviac nemam rad C, t.j. podla mna maju byt kniznicne funkcie 
> pre 8-bity (a aj pre 16-bity typu MCS430 :-) ) optimalizovane na 
> urovni asembleru.

Vola sa to MSP430 :) Ale v podstate suhlasim. Minimalne to chce 
zamysliet sa nad vygenerovanyym kodom a pripadne algoritmus upravit.

Kazdopadne, ak mam fungujuci a otestovany algoritmus v C, tak prepisat 
ho do lubovolneho assembleru je len technicky problem (robota pre ludi z 
udrzby).


>> Neviem, ktore riesenie bude na danej platforme najrychlejsie, zavisi to
>> hlavne od rychlosti implementacie delenia. Ale to sa da zistit velmi
>> jednoducho - vyskusat.
> Ano, ale to uz nemusi byt par minut...
>

Zistenie, ze itoa a spol  nie je v kniznici trvalo viac ako mesiac ... 
myslim ze hodina naviac stravena testovanim nenasobi a nedeli.

>> Len pre zaujimavost, na mojej testovacej x86_64 virtualke (ktora ma,
>> samozrejme, HW delenie) trvalo 1000 prevodov celeho rozsahu -32767 az
>> 32767 (t.j. 65534000 prevodov):
>>
>> verzia s delenim (a HW delenim): ~2.6 sekundy
>> verzia s odpocitavanim po radoch s tabulkou: ~4 sekundy
>> verzia s odpocitavanim po radoch 4 cykly po sebe: ~2.1 sekundy --->  VITAZ
> To je vskutku necakane.
>

Nerobte si srandu. Tym som len chcel ukazat, ako dokaze zmena pristupu a 
algoritmu zmenit dobu spracovania. Mne a vam je to jasne ... ale mate 
pocit ze je to jasne dnesnej generacii tzv. programatorov? Ja nie.

> wek
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list