HELP!

[•LtRaven]

Cum folosesc random() in devc ?

[•greco]

Cod:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int
main ()
{
  srand ((unsigned) time (0));
  printf ("%d\n", rand () % 10000);
  return 0;
}

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.

[•teplesnescdenutevezi]

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

[•wickedman]

acum se cheama CLOCKS_PER_SEC

[•teplesnescdenutevezi]

multumesc.

[•druid]

CLK_TCK nu e funcite, e un #define

[•teplesnescdenutevezi]

bine ca esti tu destept.

[•druid]

bine ca esti tu destept.

 

[•teplesnescdenutevezi]

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

[•greco]

cstring probabil

[•svalentin]

string.h

[•Matrix]

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

[•cavendish]

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

[•Matrix]

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

[•cavendish]

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

[•Matrix]

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

[•cavendish]

fiindca deja m-am plictisit, incearca asta:

Cod:

  long i,t1,t2;
  t1 = clock();
  for(i=10000; i>0; --i)
    memset(buffer,0,sizeof(buffer));
  t2 = clock();
  printf("memset: %ld -> %ld = %ld\n",t1,t2,t2-t1);

si

Cod:

  long i,j,t1,t2;
  t1 = clock();
  for(i=10000; i>0; --i)
    for(j=sizeof(buffer)-1; j>=0; --j)
      buffer[j]=0;
  t2 = clock();
  printf("for: %ld -> %ld = %ld\n",t1,t2,t2-t1);

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

[•Matrix]

bullshit

[•rgrig]

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:

Cod:

.L10:
	xorl	%ecx, %ecx
	movb	%cl, -10008(%eax,%ebp)
	decl	%eax
	jns	.L10

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

Cod:

.L6:
	movl	%ebx, %edi
	movl	%edx, %ecx
	movl	%esi, %eax
	rep
	stosl
	decl	-10028(%ebp)
	jns	.L6

Si, ca sa citez din manualul intel (http://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:

Cod:

vector<int> v(10000);

[•cavendish]

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.

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:

Cod:

#include <stdio.h>
void foo() { printf("foo\n"); }
int main(void) {
  for(long i=10000; i>0; --i)  foo(); 
  return 0;
}

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.

[•Matrix]

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 ..

[•rgrig]

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.

[•wickedman]

o implementare pentru memset

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.

[•Dark_Raxvan]

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!!!!!!!!!

[•svalentin]

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?!