sa ma cac cu bulbuci pe threadu vostru. pm, alta treaba n-aveti decat sa va dati aiurea cu parerea despre cum se scrie mai bine un soft ? lasati aplicatia omului in pace. nu va place, nu folositi.
Serghei Amelian wrote: >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. > > > --- Detalii despre listele noastre de mail: http://www.lug.ro/
