On Monday 19 July 2004 17:14, Vali Dragnuta wrote: > On Mon, 2004-07-19 at 17:01, Serghei Amelian wrote: > > On Monday 19 July 2004 16:50, Dorin Lazar wrote: > > > On Monday 19 July 2004 16:39, Serghei Amelian wrote: > > > > PS De asta nu-mi place sa programez in C, trebuie sa fii tot > > > > timpul atent la prostiilea astea. O clasa C++ pentru string-uri > > > > (chiar si STL) e o minune la casa omului. > > > > > > Doar ca iti mananca procesor, mai ales daca lucrezi cu > > > string-urile intr-un loc sensibil. Depinde intr-adevar ce faci - > > > si acolo, asa cum spui si tu, ar fi mers un string STL, sau ceva > > > de genul asta. > > > > Supraincarcarea procesorului e minima, ca pana la urma tot de > > alocare de memorie e vorba. Ori ca aloci un string static (care de > > fapt e alocat in stiva), ori folosesti new ori malloc, ori > > instantiezi o clasa de pentru prelucrarea stringurilor, tot aia e. > > Poate mici diferente din cauza ca se mai apeleaza o functie, doua. > > Dar pentru masinile din ziua de azi e o nimica toata. > > --- asta e o mare timpenie. > Ia incearca tu sa faci o bucla de 10k iteratii in care aloci/dealoci
10000 de iteratii? asta e test pentru HC-ul meu prafuit din pod. Poate nu ai observat ca pe masinile din ziua de azi se pot rula filme. Asta inseamna milioane si milioane de iteratii pe secunda. Ai observat poate cat de repede se scaleaza (chiar si cu smooth) o imagine truecolor de 1024x768 pixeli. Ai calculat cate iteratii trebuie sa faci sa scalezi asa ceva? Fii rezonabil.. Aici vorbim de STRING-uri, din cauza carora sunt cele mai multe probleme de securitate. > chestii si vezi cit ia in fiecare caz. Desigur ceea ce zic eu este un > pic dus la extrem, insa ideea de baza este ca nu este exact ACELASI > lucru, si in functie de specificul aplicatiei este posibil sa aiba un > impact major asupra performantei. Iar atitudunea asta cu "nu mai > conteaza pe masinile de azi" este tipica programatorilor de 2 lei > care asteapta ca hardwareul sa faca totul pentru ei, in vreme ce OK, de maine o sa ma apuc sa programez in assembler sa economisesc fiecare tact de procesor. De fapt, am si incercat sa fac asta (la o chestie mai speciala) dar am fost asa de dezamagit de rezultat.. Am obtinut o crestere de viteza de vreo 10ms la versiunea in assembler fata de cea scrisa in C++. > codul produs de ei este o mizerie. Da' ce conteaza, atita vreme cit > ne respectam termenul de predare al proiectului, nu conteaza ca > inauntru codul nostru este o mizerie. Eventual ii spunem > beneficiarului ca o sa trebuiasca sa mai cumpere un procesor mai bun, > sau sa isi mai ia si niste ram, ca este prea greu pentru noi sa > scriem cod cu altceva decit cu c*rul, cod care este si lent, si colac > peste pupaza mai este pe alocuri si exploatabil. Un cod secure este intotdeauna mai lent decat unul insecure. Cred ca ti-ai dat seama, e din cauza mai multor teste de verificare a validitatii datelor. Si pentru informarea ta: un bloc de memorie alocat nu este alocat cu adevarat decat in momentul in care e folosit. Asa ca pot sa aloc si sa dealoc 1G de memorie de 100k pe secunda. Si alta chestie: cele mai mari pierderi de viteza sunt din cauza conditiilor (if, while, for, etc) din cauza ca mecanismele de executie speculativa a procesoarelor sunt pacalite sa incarce in cache cod care de fapt nu va fi executat. Si ultima chestie: scrierile si citire din/in memorie a blocurilor foarte mari e groaznic de lenta. Concluzie: nu mai da vina pe chestii nevinovate. -- Serghei. --- Detalii despre listele noastre de mail: http://www.lug.ro/
