infoarena

Cum folosesc random() in devc ?

Asa faci un numar aleator in orice compilator compatibil cu standardele (sper). stdlib.h il folosesti pt. srand si rand, time.h pentru a seta generatorul intr-un punct. Or fi si alte metode, eu asta am folosit-o si ar trebui sa mearga cam peste tot.

cum masor timpul care s-a scurs de la inceputul rularii ? am observat ca la djgpp nu exista in time.h functia CLK_TCK.

acum se cheama CLOCKS_PER_SEC

multumesc.

CLK_TCK nu e funcite, e un #define :)

bine ca esti tu destept.

 8)

imi spune si mie cineva ce trebuie sa includ ca sa folosesc memset pe compilatorul de c++ de pe info arena ?

cstring probabil

string.h

decat sa folosesti  memset  mai  bine faci cu un " for "   sau mai bine  declari un nou sir   pt ca e   mult mai rapid  :)

nu. mai bine folosesti memset sau memcpy

de ce sa setezi un sir  de 100 000 de elemente pe 0   cu  memset ??
cand poti sa declari unul nou,     e o operatie care costa mult timp

fiindca declarand un sir nou de 100 000 de car pe stiva, aloci 97KB care nu sunt neaparat initializati cu 0. Doar variabilele globale is initializate cu 0(NULL). Si daca trebe sa faci de 1000 de ori setarea pe 0 a unui sir, nu are rost sa faci o variabila globala de 1000x100.000

daca ai de gand sa setezi de 1000 de ori un sir de 100 000 elemente,  atunci mai bine te  gandesti la alta  rezolvare

fiindca deja m-am plictisit, incearca asta:

si

si o sa vezi ca obtii un raport 1 : 5 al timpilor. Si uite ca intra intr-o secunda cu 10.000 de setari!

bullshit

Am incercat codul de mai sus cu limite ceva mai mari (repeta de 1e+5 ori si buffer de 1e+4 bytes). Varianta cu memset merge intr-adevar mult mai repede. Codul care face initializarea buffer-ului in cazul variantei cu for este:



Sincer nu inteleg de ce tot reseteaza valoarea lui ecx (e compilat cu optimizari). Codul corespunzator in varianta memset este:



Si, ca sa citez din manualul intel (ftp://download.intel.com/design/pentium/manuals/24143004.pdf): A REP STOS instruction is the fastest way to initialize a large block of memory. In plus pentru codul cu memset compilatorul s-a prins ca trebuie sa faca initializarea o singura data (desi nu s-a prins ca nu trebuie sa initializeze contorul buclei exterioare!). Asa incat benchmark-ul timpilor nu prea e corect asa cum apare in codul din mesajul de mai sus. In orice caz, daca Intel zice ca asta e cea mai rapida varianta n-are rost si nici n-am timp :) sa nu-i cred.

Pana una alta eu personal nu prea sunt fan memset din simplul motiv ca e doar un factor constant de diferenta de viteza. In plus nici n-am nevoie prea des de initializari din astea. De obicei zic:

memset() e o functie definita din punctul meu de vedere [DevCpp & g++] in <string.h>. Nu are statut special, adica nu e keyword.
Acum, sa recapitulam ce spui: compilatorul ruleaza o data functia la inceput si apoi face doar incrementari/comparari de index. NU. Daca nu ma crezi incearca codul de mai jos:

Si numara de cate ori vezi "foo". Apoi ai putea zice ca memset are statut special si ca exista optimizarea exact pt chestia asta: un for in care tot ce faci e sa setezi un sir. Dar nu e cazul, nu din momentul in care a luat 1 sec (1078 ticks)* pentru un for de la 10.000 la 1. Daca rulai codul realizai asta. Dar se pare ca ai un fel de compilator mintal care face optimizari inexistente.

[edit pt Matrix:] * - timpul de la programul cu memset; la programul cu foo nu calculez timpi.

afisarea pe ecran e foarte costisitoare din punct de vedere al timpului, incearca sa afisezi mai bine intr-un fisier, si ar mai fi si apelul de functie, care de asemenea dureaza timp, putin , dar suficient ..

M-am uitat un pic mai atent la rezultatul compilarii: intr-adevar cele doua bucle raman, compilatorul nu-si da seama ca poate scapa de cea exteriara. Se vad amandoua in codul pe care l-am postat mai sus.

Cat despre memset functie normala... Eu am spus ce face gcc 3.3.5 nu ce spune standardul. Si gcc face inline pentru memset chiar si la -O2, cand majoritatea functiilor, de exemplu printf, nu beneficiaza de acest tratament. Dupa ce face inline ajunge la codul de mai sus in care nu mi se pare deloc SF sa-si dea seama ca nu e nevoie de bucla exterioara.

Rulasem programul, doar ca pe calculatorul meu a durat sub 0.01s asa incat putea fi si zgomot de masurare (am masurat cu "time" nu cu clock() -- in felul asta codul in asamblor a ramas mai simplu).

Asa, sa revenim. Mai sunt inca cel putin doua motive (strans legate) pentru care varianta cu memset merge mai repede. Codul generat seteaza cuvinte, nu octeti. Ca urmare (1) sunt de patru ori mai putine scrieri in memorie si (2) toate adresarile sunt aliniate. Pe de alta parte, din cauza penuriei de registre de uz general pe x86 si pentru ca rep/stos iau parametrii in vreo 3 registre compilatorul nu mai are unde sa inghesuie si contorul buclei exterioare asa incat il lasa pe stiva. Accesele fiind f. localizate se foloseste practic sigur cache-ul intern.

o implementare pentru memset (http://www.koders.com/c/fid38DB7BE2F38DE324253072AFB059F5AC6A01EC21.aspx)

bottom line:
e mai simplu sa folosesti memset
fara for-uri, variabile in plus bla bla

e cel putin la fel de rapid ca e inline. studiati codul sursa sa vedeti daca o simpla bucla e la fel de eficienta.

PS: am vazut si implementari mult mai simple (o bucla) pentru memset. nu stiu ce compilator era dar mi se pare stupid sa mai insiste cineva pe ideea ca e mai bine sa faci tu de mana ta o bucla.
avand in vedere ca merge cel putin la fel de repede, putem spera ca pe anumite compilatoare / SO va merge mai repede.

Lucrez cu coduri de grafica avansata sub dos adik ceva in genul direct 3d si nu pot sa folosesc numai borlandc. As dori sa folosesc Djgpp dar nu pot HELLP!!!!!!!!!

Nu prea am inteles exact ce vrei sa zici!
Deci tu acum folosesti BorlandC?! Si din ce motive nu poti sa folosesti DJGPP?
Si ce "coduri de grafica avansata sub dos" folosesti?!

Sa explic:
Windows foloseste adaptorul grafic pentru a initializa un mod grafic mai avansat (800x600x16 1024x768x24 ... etc). Am reusit sa fac asa ceva in Borlandc adik sa folosesc adaptorul rentru chestii mai avansate. Problema este ca in Borlandc se pot forma doar aplicatii pe 16 bits ( maximum de variabile globale este de 640 de kilo).Djgpp foloseste GCC si poate sa faca aplicatii de 32 bits (maxim de 4 GB de variabile globale) dar codurile pe care le folosesc la Borlandc nu fuctioneaza si in Djgpp.
Merge sa initializez orice mod grafic fara erori dar orice metoda de a desena pe ecran nu merge.

Astept sugestii si pe   [email protected]

In BorlanC, poti sa tii mai multe variabile globale folosind huge:
int huge test[100000];

Apoi tu, ai rulat programul compilat cu gcc din rhide? Ai incercat sa executabilul?
Daca adaptorul tau este pentru dos, ai incercat sa il rulezi din DOS (compilat cu gcc)? s-ar putea sa nu-i placa Windowsului ceva la programul compilat cu gcc...

Nu inteleg daca ai probleme cu compilatorul sau cu codul tau, dar poti sa incerci si cu Dev-C++:
www.bloodshed.net/devcpp.html

:-k Cred k singura solutie este pana la urma dev C++ cu care am mai incercat .Problema este k acolo totul trebuie rescris in limbaj de asamblare si dupa ce scriu mai mult de 100 de randuri de asa ceva ma ia cu dureri de cap si imi vine sa ](*,)  oricum 10x

Eu tot n-am inteles de ce in dev C++ trebuie sa scrii in assembler!?
Sigur nu folosesti niste functii care tin doar de BorlandC?

Se pot face multe chestii chiar si in DOS.
Pentru Borland Pascal spre ex. exista o librarie (OBJGFX) capabila sa faca lucruri extraordinare in materie de grafica 2D - incepand cu bitblt-uri + canal de transparenta, operatii pe imagini raster si terminand cu import din PCX, GIF etc. Aplicatiile trebuiau compilate in real-mode.
Din cate stiu existau si variante pentru BorlandC.

Exista si librarii de neworking (Netbios, IPX mostly).

Insa e o mare lab* trista sa pierzi vremea cu antichitati din astea in timp ce in jurul tau lumea foloseste Avalon, SVG, DirectX si OpenGL.
Succes in continuare in folosirea adaptorului grafic rentru chestii mai avansate!

O alta biblioteca foarte buna pentru grafica in DOS este Grafx2. Este pentru Borland Pascal 7.0 (Protected Mode). Stie grafica pe 15/16/24/32 biti + multe efecte + formate imagini & animatii (BMP, PCX, PNG, GIF, FLC, JPEG) + cod optimizat (stie si MMX ;)) + suport si pentru ecran virtual (tratarea memoriei ca si ecran - chestie tare daca nu vrei sa-ti palpie ecranul cand faci animatii) + driver mouse/tastatura, etc.
Foloseste o biblioteca NewFrontier cu care poti aloca teoretic 4Gb (practic esti limitat la 64 Mb). (o gasesti la : www.crossfire-designs.de , sectiunea coding).

10x pentru informatzie.

in general am progresat dde unu singur dar cand vine vorba de cate o teorema sau algorim mai nou sau mai necunoscut chiar nu stiu ce sa fac .chiar vreau sa lucrez da nu stiu unde sa caut (si din cate stiu multa lume se afla in postura mea)  ati putea sa-mi dati asa o lista cu link-uri sau ceva culegeri sau ce credeti ca sa mai aflu shi io cate ceva.

pls  :)

Intra pe info.devnet.ro si vei gasi o groaza de link-uri utile la "Resurse".

am o nelamurire: De ce contul meu stilgar pe infoarena nu-mi mai merge.... nu are parola gresita sau ca nu exista ci pur si simplu se intoarce din nou la pagina de start.... am facut ceva ce nu trebuia si ma-ti izgonit? :-s

si eu am patit aceasi kestie...daca instalam windowsu mergea...sau...daca asteptam cateva zile...mergea din nou...apoi iar se oprea...si tot asa...

incearca cu mai multe browsere sa vezi daca face la fel

Încercaţi să daţi Clear Cookies (IE:  Tools > Internet Options > Delete Cookies). Spuneţi-mi dacă merge aşa.

am o problema:m-am chinuit destul de mult sa inteleg si sa implementez un articol din ginfo am observat ca nu merge....
ii vorba de "cuplaj maxim de valoare minima intr-un graf bipatit" de ilie vieru, martie 2005(se poate downloada de pe ginfo.ro vol 15/3). zice ca algoritmu ii citez:"algoritm original, rapid si foarte usor de implementat" da r l-am implementat pentru problema adapost din arhiva si chiar pentru exemplul de acolo se observa (si pe hartie pas cu pas)ca ajunge la un rezultat gresit.
  Intrebarea mea este: nu am inteles eu algoritmul sau chiar nu ii un algoritm eficient?

E busit

http://greco.lx.ro/Asupra%20unui%20articol%20din%20Ginfo.pdf

vreau sa stiu daca algoritmu din ginfo depre cuplaj maxim de cost minim(martie 2005 vol15/3) ii defapt corect. l-am aplicat pentru pr adapost din arhiva si pt exemplu nu da rez. corect.....

E busit / gresit / prost :P