C++ vraagje

[Osiris]

Hoe verander je in C++ in een string (bijvoorbeeld 'char msg[] = "Blablabla";') alle a's met c's zodat je 'char msg[] = "BlcBlcBlc";' krijgt?
Ik programeer in Borland C++ 5.0, mocht dat nog iets uitmaken (met de includes of zo).
Weet iemand het?

[ACM]

code:

for(int i = 0; i < msg.lenght; i++)
{
    if(msg[i] == 'a')
    {
      msg[i] = 'c';
    }
}

en dat dan slimmer maken.

[Osiris]

Hmm,

Ziet er cool en doordacht uit.

Ga ik es ff proberen...

Thanx

[D2k]

btw

length() is het in C++

acm doet meer java

[Orphix]

of de STL gebruiken:

code:

#include <algorithm>
...
char bla[] = "Test met t erin";
std::replace(bla, bla+strlen(bla), 't', 'a');
...

[Verwijderd]

Wanneer je geen String class gebruikt zou het als volgt moeten werken:

code:

char msg[] = "Blablabla";
for (int i = 0; i < (sizeof(msg)/sizeof(char)); i++) {
  if (msg[i] == 'a') {
    msg[i] = 'c';
  }// if
}// for

Je hebt geen extra include's nodig.

Daniel.

[Osiris]

Wowowow,

Niet zo ingewikkeld...

De eerste en tweede tip waren voldoende. Hij doet het al...
(al heb ik strlen(msg) gebruikt )

Thanx

[curry684]

Jongens jongens we gaan toch niet de met strlen de stringlengte opmeten als we er ook tijdens de operatie achter kunnen komen? Over het weggooien van performance gesproken... en sizeof is ook niet handig als ie dit dadelijk met user-input strings wil gaan doen. We hebben trailing zeroes bij dit soort strings weten we nog.

code:

for(char *Pointer = Msg; *Pointer; Pointer++)
  if(*Pointer == 'a')
    *Pointer = 'c';

(en nu hopen dat ik geen typfoutjes in de sterretjes heb gemaakt... oh en hij gebruikt duidelijk geen string-class als ik die vraag lees)

[Verwijderd]

Op maandag 27 augustus 2001 00:43 schreef curry684 het volgende:
Jongens jongens we gaan toch niet de met strlen de stringlengte opmeten als we er ook tijdens de operatie achter kunnen komen? Over het weggooien van performance gesproken... en sizeof is ook niet handig als ie dit dadelijk met user-input strings wil gaan doen. We hebben trailing zeroes bij dit soort strings weten we nog.

code:

for(char *Pointer = Msg; *Pointer; Pointer++)
  if(*Pointer == 'a')
    *Pointer = 'c';

(en nu hopen dat ik geen typfoutjes in de sterretjes heb gemaakt... oh en hij gebruikt duidelijk geen string-class als ik die vraag lees)

Dit is niet helemaal waar, de loop stopt omdat *Pointer gelijk is aan het 'end-of-string' char '\0' (en toevallig ook (int)'\0' == 0).
Trailing zero's zijn compiler afhankelijk en dus niet zeker om er vanuit te gaan. Neem bijvoorbeeld Visual C++ 6.0 en het volgende stukje code:

code:

#include <iostream.h>

int main() {
  char Msg[120];  
  cin >> Msg; // Voer in 'Blablabla'

  char *Pointer;

  for(Pointer = Msg; *Pointer; Pointer++)
    if(*Pointer == 'a')
    *Pointer = 'c';
    
  cout << Msg << endl;

  if (*Pointer == '\0') {
    cout << "*Pointer == '\\0' is waar" << endl;
  }// if

  Pointer++;// als trailing zero's zouden volgen dan...
  cout << "*(Pointer + 1) = " << *Pointer << endl;//... moet deze output '\0' opleveren
  cout << "(int) *(Pointer + 1) = " << (int) *Pointer << endl;

  return 0;
}// main

De output is dan:
Blcblcblc
*Pointer == '\0' is waar
*(Pointer + 1) = Ŝ
(int) *(Pointer + 1)= -52

Moraal: ga er niet vanuit dat er trailing zero's zijn, en hoop dat al je strings '\0'-terminated zijn!

Daniel.

[curry684]

Op maandag 27 augustus 2001 07:30 schreef DPalomo het volgende:
Moraal: ga er niet vanuit dat er trailing zero's zijn, en hoop dat al je strings '\0'-terminated zijn!

Hallooooo... OF je gebruikt een struct/class-based string-encapsulatie die weet hoe lang je string is, OF je gebruikt zero-terminated strings. Als je in het 2e geval moet hopen dat je strings zero-terminated zijn moet je een verbod krijgen om ooit nog een compiler aan te raken... dan knalt je programma namelijk ook op de eerste API-functie die je aanroept.

En je schrijft een leuk programmaatje hoor, MAAR je verkracht mijn oplossing wel. Ik declareerde Pointer echt niet voor niets als variabele met local scope voor die for-loop. En dus kun je naderhand niet express het ding met 1 ophogen om de werking te verkrachten. Zo kan ik ACM's versie ook verkrachten:

code:

int i = 0;
for( i = 0; i < msg.length; i++)
    if(msg[i] == 'a')
      msg[i] = 'c';

// Nu gaan we knallen!
msg[i + 3] = 'y';

Oh feest.... een access violation (of segmentation fault, wat jij wil)!!! Ik snap echt niet wat je met die code van jou nu wil bewijzen...

Heb je wel door uberhaupt dat een '\0'-terminated string exact EEN trailing zero bevat? Namelijk die '\0'?

[Verwijderd]

Op maandag 27 augustus 2001 17:18 schreef curry684 het volgende:

[..]

Hallooooo... OF je gebruikt een struct/class-based string-encapsulatie die weet hoe lang je string is, OF je gebruikt zero-terminated strings. Als je in het 2e geval moet hopen dat je strings zero-terminated zijn moet je een verbod krijgen om ooit nog een compiler aan te raken... dan knalt je programma namelijk ook op de eerste API-functie die je aanroept.

En je schrijft een leuk programmaatje hoor, MAAR je verkracht mijn oplossing wel. Ik declareerde Pointer echt niet voor niets als variabele met local scope voor die for-loop. En dus kun je naderhand niet express het ding met 1 ophogen om de werking te verkrachten. Zo kan ik ACM's versie ook verkrachten:

code:

int i = 0;
for( i = 0; i < msg.length; i++)
    if(msg[i] == 'a')
      msg[i] = 'c';

// Nu gaan we knallen!
msg[i + 3] = 'y';

Oh feest.... een access violation (of segmentation fault, wat jij wil)!!! Ik snap echt niet wat je met die code van jou nu wil bewijzen...

Heb je wel door uberhaupt dat een '\0'-terminated string exact EEN trailing zero bevat? Namelijk die '\0'?

Ik probeer slechts aan te tonen dat er geen sprake is van trailing zero'S, zoals je in je vorige post melde. Inderdaad een end-of-string zero (enkelvoud) is een vast onderdeel van een string. Sorry dat ik je op je teentjes heb getrapt...

Daniel.

[ACM]

Op maandag 27 augustus 2001 20:43 schreef DPalomo het volgende:
Daniel.

Mag ik ook jou even op de FAQ wijzen?

Wij tweakers doen elkaar permanent de groeten. Het is dus niet nodig om steeds ruimteverspillende "greetz [user]" of iets dergelijks onder je post te plakken. Als je perse zoiets wilt kun je daar je signature voor gebruiken (zie latere uitleg).

Please continue on topic now...

[whoami]

Strings (als het geen string class ofzo is), maar gewone char* of char[] eindigen toch altijd met een NULL value ('\0')?

dit is ook een mogelijke oplossing, misschien iets duidelijker dan die van Curry684

code:

char* str = "blablabal";

i = 0;
while (str)
{
  if (str[i] == 'a') str[i++] = 'c';
}

[Verwijderd]

Is dit geen 'maak mijn huiswerk'-topic?

Waarom zit ie nog niet spijkerdicht?

[Sponz]

Op maandag 27 augustus 2001 21:48 schreef whoami het volgende:
Strings (als het geen string class ofzo is), maar gewone char* of char[] eindigen toch altijd met een NULL value ('\0')?

dit is ook een mogelijke oplossing, misschien iets duidelijker dan die van Curry684

code:

char* str = "blablabal";

i = 0;
while (str)
{
  if (str[i] == 'a') str[i++] = 'c';
}

Hartstikke fout joh. char* str = "blablabal"; is een constante, die mag je niet wijzigen. En je loopje gaat hangen, ohohoh

[whoami]

Op maandag 27 augustus 2001 22:06 schreef Sponz het volgende:

[..]

Hartstikke fout joh. char* str = "blablabal"; is een constante, die mag je niet wijzigen. En je loopje gaat hangen, ohohoh

Hartstikke fout? Niets van, (toch niet hetgeen jij bedoelt).

code:

char* str = "blablabla";

is verrevan een constante. Zie jij ergens het reserved word "const" staan? Ik anders niet hoor.
Dat mijn loopje blijft hangen is juist. Het moet zijn

code:

while (str[i])
{
  if (str[i] == 'a') str[i] = 'c';
  i++;
}

Note: de 'i++' staat nu buiten de if. Was dom van me.

[marcusk]

code:

char* str = "blablabla";

gaat ook niet echt werken.

code:

char str[] = "blablabla";

moet het zijn.

[Verwijderd]

Op maandag 27 augustus 2001 22:56 schreef marcusk het volgende:

code:

char* str = "blablabla";

gaat ook niet echt werken.

code:

char str[] = "blablabla";

moet het zijn.

heb jij ooit C geprogged?

Die twee doen namelijk exact hetzelfde

[marcusk]

heb jij ooit C geprogged?

nee, nooit

Die twee doen namelijk exact hetzelfde

hmmm, ik zou verwachten dat er dan geen geheugen reserveerd wordt voor de string, maar wel dus? ik vind str[] iig netter

[.oisyn]

het verschil is dat bij

code:

char * str = "bla"

een pointer wordt gemaakt die wijst naar het (wijzigbare) stuk geheugen waar "bla" in staat.

Bij

code:

char str[] = "bla"

wordt er geen pointer aangemaakt, maar is str simpelweg een array (van 4 chars) dus dat scheelt weer 4 bytes voor die pointer (en wat performance)

[ACM]

Op maandag 27 augustus 2001 23:10 schreef OiSyN het volgende:
het verschil is dat bij

code:

char * str = "bla"

een pointer wordt gemaakt die wijst naar het (wijzigbare) stuk geheugen waar "bla" in staat.

Bij

code:

char str[] = "bla"

wordt er geen pointer aangemaakt, maar is str simpelweg een array (van 4 chars) dus dat scheelt weer 4 bytes voor die pointer (en wat performance)

*kuch*
Das niet helemaal correct bij mijn weten...

Een array is, voor zover ik weet, niks anders dan een pointer naar een zwikje geheugen.

[Verwijderd]

Marcusk heeft gelijk. Ik ben nu C/C++ aan het leren en in dat boek staat ook inderdaad dat de volgende code niet wil werken:

code:

char* p = "Tekst";
p[4] = 'r';

dit moet het zijn:

code:

char p[] = "Tekst";
p[4] = 'r';

[ACM]

Op maandag 27 augustus 2001 23:13 schreef tokkie het volgende:
Marcusk heeft gelijk. Ik ben nu C/C++ aan het leren en in dat boek staat ook inderdaad dat de volgende code niet wil werken:

Wat flauw zeg.
De 2e printf wordt idd niet afgedrukt...

code:

int main()
{
    char *p = "Tekst";
    char p2[] = "Tekst";

    printf("%s : %s\n", p, p2);

    p[1] = 'a';
    printf("%s : %s\n", p, p2);
    p2[1] = 'a';
    printf("%s : %s\n", p, p2);
}

[acm@vulcanus acm]$ ./string
Tekst : Tekst
Segmentation fault (core dumped)

[curry684]

Op maandag 27 augustus 2001 20:43 schreef DPalomo het volgende:
Ik probeer slechts aan te tonen dat er geen sprake is van trailing zero'S, zoals je in je vorige post melde. Inderdaad een end-of-string zero (enkelvoud) is een vast onderdeel van een string.

En dus bevatten stringS inderdaad trailing zeroES... Zou lullig zijn als al je strings dezelfde trailing zero moeten delen... Your point?

Sorry dat ik je op je teentjes heb getrapt...

Niet zozeer op de teentjes getrapt: je zat een volledig legitieme, zelfs de snelst mogelijke oplossing af te kraken met onzinargumenten.

Dan krijg je van mij wel even op je flikker ja dat je je stof beter moet kennen voordat je commentaar gaat geven. Verder weer goede vrienden hoor

[.oisyn]

Op maandag 27 augustus 2001 23:11 schreef ACM het volgende:

[..]

*kuch*
Das niet helemaal correct bij mijn weten...

Een array is, voor zover ik weet, niks anders dan een pointer naar een zwikje geheugen.

Dan is jouw weten niet helemaal correct

Als je doet

code:

char charArray[100];

dan is charArray een array van 100 chars. sizeof (charArray) wordt dan ook 100 * sizeof (char). charArray is geen pointer naar een array van chars, anders kon je dit ook wel doen:

code:

char charArray[100];
char nogEenArray[16];
charArray = nogEenArray;

Maar dat gaat niet werken, omdat charArray geen pointer is.
Hetzelfde geldt natuurlijk voor

code:

char charArray[] = "dit is een string";

ook hiervoor geldt: sizeof (charArray) = 18 (17 tekens in de string + nog een '/0')


Maar bij een pointer:

code:

char *charArray = "dit is een string";

sizeof (charArray) is in dit geval hetzelfde als sizeof (char * ), wat dus meestal 4 is. Ook gaat deze assignment:

code:

charArray = "nu is het een andere string";

prima werken, want de variabele charArray is tenslotte niets meer dan een pointer


Dat je de array (dus niet de pointer) als pointer door kan geven naar functies enzo is simpelweg omdat je compiler 'm automatisch cast naar een pointer. Maar het IS geen pointer, daarom werkt de assignment ook niet

[curry684]

Op dinsdag 28 augustus 2001 01:17 schreef OiSyN het volgende:
...

Bijna perfecte uitleg, maar...

Dat je de array (dus niet de pointer) als pointer door kan geven naar functies enzo is simpelweg omdat je compiler 'm automatisch cast naar een pointer. Maar het IS geen pointer, daarom werkt de assignment ook niet

Niks geen impliciete cast... in allebei de gevallen alloceer je een object op de stack, in het ene geval een pointer naar interne data en in het andere geval een array van interne data.

Sizeof geeft het formaat van het gealloceerde object terug, en zal hier dus inderdaad 2 verschillende resultaten geven. De naam van een array is echter voor de compiler niets anders dan een pointer naar het begin van die array. Het is dus geen cast maar gewoon een simpele copy.

Dit puntje is gerelateerd aan het beroemde volgende geval:

code:

char*   Text = new char[50];
delete Text;

Dit is een gevaarlijke operatie die niet door alle compilers goed uitgevoerd wordt!!!

De correcte versie is:

code:

char*   Text = new char[50];
delete [] Text;

Sommige compilers zullen de eerste versie letterlijk interpreteren en alleen het eerste object deleten. Dit betekent in dit geval een memoryleak van 49 chars. De 2e versie geeft (correct) de gealloceerde array vrij.

Borland's CodeGuard en andere code-checkers geven bij het op deze manier fout vrijgeven van arrays een flinke error.

* curry684 moest even mierenneuken, voor de rest perfecte uitleg

[addendum]
Ik zei: De naam van een array is echter voor de compiler niets anders dan een pointer naar het begin van die array. Hier moet je natuurlijk wel bij bedenken dat deze pointer nergens wordt aangemaakt en alleen binnen de onderliggende assembler bestaat. Vandaar dat je er geen assignments op mag doen: hij bestaat in de C++ code niet fysiek.
[/addendum]

[edit2]Stommiteit gefixed

[.oisyn]

Op dinsdag 28 augustus 2001 01:48 schreef curry684 een verhaaltje (en ze leefden nog lang en gelukkig)

als je char *str = "bla" doet, dan wordt er op de stack idd een pointer gealloceerd, maar merk wel op dat dat "bla" niet op de stack gealloceerd wordt (het wordt in principe niet eens gealloceerd; het wordt in het datasegment van de executable gezet)

Overigens zie ik niet in hoe je met delete iets kunt vrijgeven wat je op de stack gealloceerd hebt
Als je het aanroept zoals je zei (dus zonder []), dan krijg je in principe een een of andere error, omdat je een stuk geheugen probeert vrij te geven wat je helemaal niet gealloceerd hebt. Overigens werkt delete zonder [] meestal wel altijd, omdat ie gewoon een stuk geheugen vrijgeeft wat ie eerder heeft gealloceerd. Het gaat fout als je een array van een bepaalde klasse delete, omdat dan niet alle destructors worden aangeroepen (alleen die van het eerste element, omdat de compiler niet weet dat het om een array gaat)

[.oisyn]

Op dinsdag 28 augustus 2001 01:48 schreef curry684 het volgende:

[..]

[addendum]
Ik zei: De naam van een array is echter voor de compiler niets anders dan een pointer naar het begin van die array. Hier moet je natuurlijk wel bij bedenken dat deze pointer nergens wordt aangemaakt en alleen binnen de onderliggende assembler bestaat. Vandaar dat je er geen assignments op mag doen: hij bestaat in de C++ code niet fysiek.
[/addendum]

dat is ook wat ik bedoelde te zeggen, maar ik wist even niet hoe ik het onder woorden moest brengen. Mooi gezegd

[Orphix]

hmm toch nog interessant hoe je over zoiets simpels (waarvan je denkt dat je het doorhebt ) nog iets kan leren.....het blijft een mooi taal he
(gelukkig programmeer ik in C++ )

[curry684]

Op dinsdag 28 augustus 2001 02:05 schreef OiSyN het volgende:
Overigens zie ik niet in hoe je met delete iets kunt vrijgeven wat je op de stack gealloceerd hebt

Dat is dat stommiteitje dat ik bij [Edit2] had gefixed terwijl jij dit antwoord type Het was 2 uur 's nachts okee?

[curry684]

Op dinsdag 28 augustus 2001 03:23 schreef Orphix het volgende:
hmm toch nog interessant hoe je over zoiets simpels (waarvan je denkt dat je het doorhebt ) nog iets kan leren.....het blijft een mooi taal he
(gelukkig programmeer ik in C++ )

Uh het gaat hier over C++ hoor, de new en delete operators bestaan niet in gewoon C...

[Verwijderd]

Ga ik nog ff lekker addendum-mierenneuken

Op maandag 27 augustus 2001 22:29 schreef whoami het volgende:

code:

while (str[i])
{
  if (str[i] == 'a') str[i] = 'c';
  i++;
}

Is dit niet veel korter?

code:

for(i=0;str[i];i++) if(str[i]=='a') str[i]='c';

Beetje het perfecte voorbeeld van wanneer je geen while moet gebruiken, lijkt me.

[Sponz]

Op dinsdag 28 augustus 2001 11:33 schreef beelzebubu het volgende:
Is dit niet veel korter?

code:

for(i=0;str[i];i++) if(str[i]=='a') str[i]='c';

Beetje het perfecte voorbeeld van wanneer je geen while moet gebruiken, lijkt me.

moaw, while kan best wel

code:

 char *p = str;  
 while ( p = strchr(p,'a') ) *p='c';

Het leest alleen wat lastiger, je for loop is duidelijker

[Orphix]

Op dinsdag 28 augustus 2001 10:06 schreef curry684 het volgende:

[..]

Uh het gaat hier over C++ hoor, de new en delete operators bestaan niet in gewoon C...

eh ja, ik doelde eigenlijk op dat ik tegenwoordig bijna altijd std::string gebruik ipv char-arrays. Toen ik het typte leek het me idd logischer dan nu ik m'n reactie teruglees

[curry684]

Op dinsdag 28 augustus 2001 11:33 schreef beelzebubu het volgende:
Is dit niet veel korter?

code:

for(i=0;str[i];i++)
  if(str[i]=='a')
    str[i]='c';

Nou nee, het is nog steeds net zoals de meeste versies hiervoor 3 regels code (ik ben zo vriendelijk geweest de returns voor je te zetten ) En wat uitvoersnelheid betreft is ie nog steeds langzamer dan mijn versie met het dereferencen van de pointer, omdat je hier een index gebruikt en de compiler geen link mag leggen tussen de pointer en de oplopende index: iedere iteratie wordt het te testen adres dus opnieuw berekend, terwijl als je gewoon over de pointer 'wandelt' er minder ASM uit komt rollen (niet praktijkproven theorie moet ik toegeven).

Beetje het perfecte voorbeeld van wanneer je geen while moet gebruiken, lijkt me.

Tja je hebt nodig:
- Een init-statement
- Een eindconditie
- Een end-of-iteration statement

En dan mag Sponz wel met leuke spectaculaire voorbeeldjes komen maar volgens de schoolboekjes heb je dan een for nodig...

[whoami]

Op maandag 27 augustus 2001 23:13 schreef tokkie het volgende:
Marcusk heeft gelijk. Ik ben nu C/C++ aan het leren en in dat boek staat ook inderdaad dat de volgende code niet wil werken:

code:

char* p = "Tekst";
p[4] = 'r';

dit moet het zijn:

code:

char p[] = "Tekst";
p[4] = 'r';

Haal het maar eens door een compiler. Borland of MS, maakt niet uit.

[marcusk]

Op dinsdag 28 augustus 2001 23:15 schreef whoami het volgende:

[..]

Haal het maar eens door een compiler. Borland of MS, maakt niet uit.

Bij ACM werkte het lekker niet

[whoami]

Op dinsdag 28 augustus 2001 23:21 schreef marcusk het volgende:

[..]

Bij ACM werkte het lekker niet

Heb het door Borland gehaald en geen probleem. (heb de string wel niet naar het scherm getoond, maar heel het spel gedebugged). De a's veranderden in c's.

[curry684]

Okee ik werd nu toch benieuwd en heb de vier geboden oplossing door Visual C++ 6 gehaald... het volgende stukje code ging erin, in debugbuild dus geen optimalisaties:

code:

  char  Msg[] = "Blablablah";
  int    i     = 0;

  // Osiris (?)
  for(i = 0; i != strlen(Msg); i++)
    if(Msg[i] == 'a')
    Msg[i] = 'c';

  // Curry684
  for(char *Pointer = Msg; *Pointer; Pointer++)
    if(*Pointer == 'a')
    *Pointer = 'c';

  // Beelzebubu
  for(i=0;Msg[i];i++) 
    if(Msg[i]=='a') 
    Msg[i]='c';

  // Sponz
  char *p = Msg;  
  while(p = strchr(p,'a'))
    *p='c';

Het volledige resultaat aan assemblercode volgt onderaan met de sourceregels op de goede plek ingevoegd, maar hier is alvast het scorelijstje wat bytes betreft...

Osiris : 56 bytes (+ een call to strlen)
Curry684 : 46 bytes
Beelzebubu : 53 bytes
Sponz : 39 bytes (+ veul calls to strchr)

De externe functies zijn aan bytes:
strlen : 123 bytes
strchr : 179 bytes

De scores zeggen bij lange niet alles (iemand zin om met een profiler te gaan spelen? ) maar je kunt er wel de effectiviteit uit afleiden. De oplossing van Sponz is de kleinste in ruimte, maar zal het langzaamste zijn omdat iedere iteratie een stevige functie wordt aangeroepen.

Misschien ga ik dadelijk wel wat QueryPerformanceCounter troep in dit programmaatje bakken, ik verveel me wel een beetje (hadden jullie zeker al door )

De assemblercode zelf:

code:

49:     char    Msg[] = "Blablablah";
00401878   mov     eax,[string "Blablablah" (0045c120)]
0040187D   mov     dword ptr [Msg],eax
00401880   mov     ecx,dword ptr [string "Blablablah"+4 (0045c124)]
00401886   mov     dword ptr [ebp-18h],ecx
00401889   mov     dx,word ptr [string "Blablablah"+8 (0045c128)]
00401890   mov     word ptr [ebp-14h],dx
00401894   mov     al,[string "Blablablah"+0Ah (0045c12a)]
00401899   mov     byte ptr [ebp-12h],al
50:     int  i     = 0;
0040189C   mov     dword ptr [i],0
51:
52:     // Osiris (?)
53:     for(i = 0; i != strlen(Msg); i++)
004018A3   mov     dword ptr [i],0
004018AA   jmp     main+85h (004018b5)
004018AC   mov     ecx,dword ptr [i]
004018AF   add     ecx,1
004018B2   mov     dword ptr [i],ecx
004018B5   lea     edx,[Msg]
004018B8   push   edx
004018B9   call   strlen (00422270)
004018BE   add     esp,4
004018C1   cmp     dword ptr [i],eax
004018C4   je       main+0ADh (004018dd)
54:  if(Msg[i] == 'a')
004018C6   mov     eax,dword ptr [i]
004018C9   movsx     ecx,byte ptr Msg[eax]
004018CE   cmp     ecx,61h
004018D1   jne     main+0ABh (004018db)
55:    Msg[i] = 'c';
004018D3   mov     edx,dword ptr [i]
004018D6   mov     byte ptr Msg[edx],63h
56:
57:     // Curry684
58:     for(char *Pointer = Msg; *Pointer; Pointer++)
004018DB   jmp     main+7Ch (004018ac)
004018DD   lea     eax,[Msg]
004018E0   mov     dword ptr [Pointer],eax
004018E3   jmp     main+0BEh (004018ee)
004018E5   mov     ecx,dword ptr [Pointer]
004018E8   add     ecx,1
004018EB   mov     dword ptr [Pointer],ecx
004018EE   mov     edx,dword ptr [Pointer]
004018F1   movsx     eax,byte ptr [edx]
004018F4   test   eax,eax
004018F6   je       main+0DBh (0040190b)
59:  if(*Pointer == 'a')
004018F8   mov     ecx,dword ptr [Pointer]
004018FB   movsx     edx,byte ptr [ecx]
004018FE   cmp     edx,61h
00401901   jne     main+0D9h (00401909)
60:    *Pointer = 'c';
00401903   mov     eax,dword ptr [Pointer]
00401906   mov     byte ptr [eax],63h
61:
62:     // Beelzebubu
63:     for(i=0;Msg[i];i++)
00401909   jmp     main+0B5h (004018e5)
0040190B   mov     dword ptr [i],0
00401912   jmp     main+0EDh (0040191d)
00401914   mov     ecx,dword ptr [i]
00401917   add     ecx,1
0040191A   mov     dword ptr [i],ecx
0040191D   mov     edx,dword ptr [i]
00401920   movsx     eax,byte ptr Msg[edx]
00401925   test   eax,eax
00401927   je       main+110h (00401940)
64:  if(Msg[i]=='a')
00401929   mov     ecx,dword ptr [i]
0040192C   movsx     edx,byte ptr Msg[ecx]
00401931   cmp     edx,61h
00401934   jne     main+10Eh (0040193e)
65:    Msg[i]='c';
00401936   mov     eax,dword ptr [i]
00401939   mov     byte ptr Msg[eax],63h
66:
67:     // Sponz
68:     char *p = Msg;
0040193E   jmp     main+0E4h (00401914)
00401940   lea     ecx,[Msg]
00401943   mov     dword ptr [p],ecx
69:  while ( p = strchr(p,'a') ) *p='c';
00401946   push   61h
00401948   mov     edx,dword ptr [p]
0040194B   push   edx
0040194C   call   strchr (004221b0)
00401951   add     esp,8
00401954   mov     dword ptr [p],eax
00401957   cmp     dword ptr [p],0
0040195B   je       main+135h (00401965)
0040195D   mov     eax,dword ptr [p]
00401960   mov     byte ptr [eax],63h
00401963   jmp     main+116h (00401946)

edit:

Zie net dat VC++ de laatste assemblerregel van de de ene sourceline bij de volgende indeelt, waardoor ik dus consequent 1 regel fout las Dit maakt weinig verschil omdat het een consequente rekenfout is (gok ik uit de blote pols )

[.oisyn]

jaaahaaaa maar dit is zonder optimalizatie

moet je eens kijken wat er overblijft als je gaat optimizen

[curry684]

Op woensdag 29 augustus 2001 00:54 schreef OiSyN het volgende:
jaaahaaaa maar dit is zonder optimalizatie

moet je eens kijken wat er overblijft als je gaat optimizen

Ik heb expres niet geoptimaliseerd omdat de verschillende methodes dan op mekaar zouden optimizen. Overigens blijft een indexed methode ook met full optimalization langzamer en groter dan een dereferencing methode (variabele minder te managen).

Ik geef grif toe overigens dat de verschillen miereneukerig klein zijn, maar stop 5 miljard miereneukerige performanceleaks per seconde bij mekaar en voordat je het weet heb je Windows geschreven

[.oisyn]

Op woensdag 29 augustus 2001 01:11 schreef curry684 het volgende:

[..]

Ik heb expres niet geoptimaliseerd omdat de verschillende methodes dan op mekaar zouden optimizen. Overigens blijft een indexed methode ook met full optimalization langzamer en groter dan een dereferencing methode (variabele minder te managen).

een (goede) optimizer gooit die hele index variabele weg, dus dat is niet zo

[curry684]

Op woensdag 29 augustus 2001 02:27 schreef OiSyN het volgende:
een (goede) optimizer gooit die hele index variabele weg, dus dat is niet zo

In de versie van Beelzebubu, waar de eindconditie eigenlijk een dereferencing van de array+index is, kan ik me voorstellen dat ie die conclusie trekt, maar bij de eerste van de 4 waarbij gelijkheid van de index aan de stringlengte als eindconditie wordt gebruikt lijkt me dit heel sterk.

Theoretisch gezien met multithreaded applicaties zou deze optimalisatie sowieso alleen mogen gebeuren als de index binnen for-scope staat gedefinieerd, en/of met het keyword register is gedeclareerd .

[Grum]

ik ben een redelijk c newbie

maar dit kan toch ook ?

code:

char Str[] = "blablabla", *Strptr = Str;
 
while(*Strptr++)
   if(*Strptr == 'a') 
    *Strptr = 'c';

[Verwijderd]

kun je allevier de methodes eens miljoen keer achter elkaar runnen en de tijd opnemen?

Benieuwd wie wint. Ik denk die van jou, curry

[curry684]

Op woensdag 29 augustus 2001 10:42 schreef Grum_ het volgende:
ik ben een redelijk c newbie

maar dit kan toch ook ?

code:

char Str[] = "blablabla", *Strptr = Str;
 
while(*Strptr++)
   if(*Strptr == 'a') 
    *Strptr = 'c';

En dit nu proberen met als string 'aap': wordt 'acp'.

Die post-increment wordt aan het einde van de while-evaluatie uitgevoerd... daarom heb je een for nodig, daar kun je een statement opgeven die pas na de eerste iteratie uitgevoerd wordt. Je versie zou trouwens wel werken met een do-while constructie met dezelfde parameters, maar dan zou je extra overhead hebben omdat je de trailing zero met 'a' vergelijkt.

[Grum]

ik weet dat ik n00b ben beelzebubu maar dan hoef je me nog niet te vergete

[Grum]

Op woensdag 29 augustus 2001 10:54 schreef curry684 het volgende:

En dit nu proberen met als string 'aap': wordt 'acp'.

Die post-increment wordt aan het einde van de while-evaluatie uitgevoerd... daarom heb je een for nodig, daar kun je een statement opgeven die pas na de eerste iteratie uitgevoerd wordt. Je versie zou trouwens wel werken met een do-while constructie met dezelfde parameters, maar dan zou je extra overhead hebben omdat je de trailing zero met 'a' vergelijkt.

code

code:

#include <stdio.h>
main() {
      char Str[] = "blablabla", *Strptr = Str;
      while(*Strptr++)
            if(*Strptr == 'a') *Strptr = 'c';
      printf("%s\n", Str);
}

output:

code:

erik@fork:~$ ./test
blcblcblc

nu jij weer

edit:

het is toch JUIST goed dat de increment aan het einde gebeurt ? je wil toch niet het eerste char overslaan (bv met *++Strptr)

[curry684]

Op woensdag 29 augustus 2001 10:46 schreef beelzebubu het volgende:
kun je allevier de methodes eens miljoen keer achter elkaar runnen en de tijd opnemen?

Benieuwd wie wint. Ik denk die van jou, curry

Okee, ik zal vandaag zodra ik een keer wat tijd over heb een keer in full-optimized build de versies timen

[curry684]

Op woensdag 29 augustus 2001 10:59 schreef Grum_ het volgende:
blcblcblc[/code]
nu jij weer

Jaaaaaaaa.... daarom zei ook dat je met aap moest proberen, jouw versie slaat de eerste char over

[Grum]

Op woensdag 29 augustus 2001 11:02 schreef curry684 het volgende:

[..]

Jaaaaaaaa.... daarom zei ook dat je met aap moest proberen, jouw versie slaat de eerste char over

ik zei toch dat ik n00b was :ppp

[herkansing]
dit werkt wel!

code:

char Str[] = "aablaablaaa", *Strptr = Str;
 
while(*Strptr)
{
   if(*Strptr == 'a')
    *Strptr = 'c';
   Strptr++;
}

maar dit is natuurlijk in weze de forloop (vraag me af offet precies dezelfde code geeft)
[/herkansing]

[curry684]

Op woensdag 29 augustus 2001 10:59 schreef Grum_ het volgende:
het is toch JUIST goed dat de increment aan het einde gebeurt ? je wil toch niet het eerste char overslaan (bv met *++Strptr)

De post-increment wordt na de evaluatie waar ie in staat uitgevoerd, niet na de hele while-loop

[Verwijderd]

Op woensdag 29 augustus 2001 10:54 schreef Grum_ het volgende:
ik weet dat ik n00b ben beelzebubu maar dan hoef je me nog niet te vergete

Je was een seconde voor mij met je post - ik miste die van jou net

Ik ben benieuwd naar je resultaten. Als mijn internet op mijn kamer nou eens wat deed zou ik ook wat doen maarja, internet doet het niet en hier heb ik geen compiler

[Olaf van der Spek]

Op maandag 27 augustus 2001 22:06 schreef Sponz het volgende:

[..]

Hartstikke fout joh. char* str = "blablabal"; is een constante, die mag je niet wijzigen. En je loopje gaat hangen, ohohoh

Ooit wordt die pointer wel NULL hoor. Maar daarvoor heb je het hele geheugen al vernaggeld.

[.oisyn]

Op woensdag 29 augustus 2001 11:02 schreef Grum_ het volgende:

[..]

ik zei toch dat ik n00b was :ppp

[herkansing]
dit werkt wel!

code:

char Str[] = "aablaablaaa", *Strptr = Str;
 
while(*Strptr)
{
   if(*Strptr == 'a')
    *Strptr = 'c';
   Strptr++;
}

maar dit is natuurlijk in weze de forloop (vraag me af offet precies dezelfde code geeft)
[/herkansing]

doe het zo

code:

do
{
   if(*Strptr == 'a')
    *Strptr = 'c';
} while (*Strptr++);

[curry684]

Op woensdag 29 augustus 2001 14:28 schreef OiSyN het volgende:

[..]

doe het zo

code:

do
{
   if(*Strptr == 'a')
    *Strptr = 'c';
} while (*Strptr++);

* curry684 citeert uit eigen werk: "Je versie zou trouwens wel werken met een do-while constructie met dezelfde parameters, maar dan zou je extra overhead hebben omdat je de trailing zero met 'a' vergelijkt."

[Olaf van der Spek]

Waarom? Die eerste stopt sneller met een lege string en is verder even snel.

[curry684]

Op woensdag 29 augustus 2001 10:46 schreef beelzebubu het volgende:
kun je allevier de methodes eens miljoen keer achter elkaar runnen en de tijd opnemen?

Benieuwd wie wint. Ik denk die van jou, curry

Nou, het zou je verbazen! Ik heb het maar meteen 5 miljoen keer gedaan, en de versie van Grum/Oisyn erbij genomen. Dit alles uitgevoerd op een Celeron 466@480 onder Windows XP. Ziehier de resultaten in debug build:

code:

    Osiris : 4146ms
     Curry : 1842ms
Beelzebubu : 1943ms
     Sponz : 2484ms
     Oisyn : 2123ms

Dus hierbij is mijn methode inderdaad de snelste. Maarruh.... de release-build fully optimized resultaten verbaasden mij ook:

code:

    Osiris : 9063ms
     Curry : 842ms
Beelzebubu : 591ms
     Sponz : 1492ms
     Oisyn : 831ms

Waar de code van Beelzebubu zich bijna 4 keer sneller laat maken, wat het de SNELSTE maakt, hebben we hier het verrassende resultaat dat de methode die in de for met strlen werkt ruim 2 keer langzamer is... knap werk van Microsoft Tevens haalt de Oisyn/Grum methode die van mij net in... wazig! Wellicht kan iemand kijken of de resultaten op Linux met GCC vergelijkbaar zijn, lijkt me leuk.

In ieder geval hulde aan Beelzebubu

De testcase:

code:

// Speed tester
#include <windows.h>
#include <stdio.h>
#include <conio.h>

// Aantal testiteraties (5 miljoen)
const int    c_Iterations   = 5000 * 1000;

// Hulpmacro
#define Test(p_Method)    Timer = GetTickCount();                \
                  for(i = 0; i != c_Iterations; i++) p_Method();  \
                  Timer = GetTickCount() - Timer;            \
                  printf("%10s : %dms\n", #p_Method, Timer);    \

// De methodes

// Osiris
void Osiris()
{
char    Msg[] = "Blablabla";
for(unsigned int i = 0; i != strlen(Msg); i++)
  if(Msg[i] == 'a')
    Msg[i] = 'c';
}

// Curry684
void Curry()
{
char    Msg[] = "Blablabla";
for(char *Pointer = Msg; *Pointer; Pointer++)
  if(*Pointer == 'a')
    *Pointer = 'c';
}

// Beelzebubu
void Beelzebubu()
{
char    Msg[] = "Blablabla";
for(int i=0;Msg[i];i++) 
  if(Msg[i]=='a') 
    Msg[i]='c';
}

// Sponz
void Sponz()
{
char    Msg[] = "Blablabla";
char *p = Msg;  
while(p = strchr(p,'a'))
  *p='c'; 
}

// Oisyn/Grum
void Oisyn()
{
char    Msg[] = "Blablabla";
char*     Strptr = Msg;
do
  {
  if(*Strptr == 'a')
    *Strptr = 'c';
  } while (*Strptr++);
}

// De main functie
int main()
{
int  Timer, i;

// Process executie naar realtime schuppen voor betrouwbaarheid
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);

// Doe de tests
Test(Osiris);
Test(Curry);
Test(Beelzebubu);
Test(Sponz);
Test(Oisyn);

// En terug....
SetPriorityClass(GetCurrentProcess(), NORMAL_PRIORITY_CLASS);

// Exit
printf("\nPress any key to exit...");
while(!getch());
return 0;
}

Alle resultaten zijn overigens consequent reproduceerbaar, meerdere malen achter elkaar in willekeurige volgorde.

[.oisyn]

.edit: ho wacht ik ben de snelste niet , ik keek verkeerd

anyway, zie je, ik zei toch dat die index werdt verneukt bij optimizen . Compilers 'begrijpen' simpele for lussen nou eenmaal... doe ook eens een asm uitdraai van die van mij en die van beelzebubu? (overigens, misschien is er 1 sneller omdat die msg precies op een cacheboundary ligt (32 bytes geloof ik)

.edit2: misschien moet je voor de grap eens proberen die char Msg[] globaal te maken (en natuurlijk wel weer steeds terug zetten na een test)

[Sponz]

Nette source..

Had je niet eerder kunnen zeggen dat het een wedstrijd was

[Sponz]

Op woensdag 29 augustus 2001 22:52 schreef curry684 het volgende:

[..]
Wellicht kan iemand kijken of de resultaten op Linux met GCC vergelijkbaar zijn, lijkt me leuk.

Moet je wel window.h eruit slopen, conio ook denk ik


borland 5.5

code:

D:\ff>dd
    Osiris : 2630ms
     Curry : 870ms
Beelzebubu : 880ms
     Sponz : 1318ms
     Oisyn : 770ms

Press any key to exit...

[.oisyn]

[.oisyn]

toch vind ik die van osiris roeleren

[.oisyn]

en nu deze nog

code:

asm
{
    mov edx, Msg
ALIGN
loopstart:
    mov al, [edx]
    or al, al
    jz end
    inc edx
    cmp al, 'a'
    jne loopstart
    mov byte ptr [edx - 1], 'c'
    jmp loopstart
ALIGN
end:
}

.edit: ALIGN bij end gezet. Het boeit niet zoveel, maar het is toch wat

[curry684]

Op woensdag 29 augustus 2001 23:28 schreef OiSyN het volgende:
anyway, zie je, ik zei toch dat die index werdt verneukt bij optimizen . Compilers 'begrijpen' simpele for lussen nou eenmaal...

Daar zei ik ook bij dat ik die optimalisatie zelf alleen verantwoord zou vinden als de index pure for-scope had... en dat heb ik 'm hier ook gegeven

(overigens, misschien is er 1 sneller omdat die msg precies op een cacheboundary ligt (32 bytes geloof ik)

Ik heb ze in verschillende source-volgordes gecompileerd en geen verschillen gezien van groter dan 10ms.

.edit2: misschien moet je voor de grap eens proberen die char Msg[] globaal te maken (en natuurlijk wel weer steeds terug zetten na een test)

Zou niet uit moeten maken omdat ik Msg in iedere functie opnieuw definieer, ze hebben daarvoor dus allemaal dezelfde overhead.

[curry684]

Op woensdag 29 augustus 2001 23:28 schreef Sponz het volgende:
Nette source..

Hee ik zit in die business man... En vergeleken bij m'n normale werk is dit nog troep trouwens... ik ben nogal een 'spurious commenter' gewoonlijk, en 'i' als variabele is eigenlijk zwaar uit den boze

Had je niet eerder kunnen zeggen dat het een wedstrijd was

Wist ik ook niet vantevoren!

[Olaf van der Spek]

Met all optimizations aan krijg ik dit resultaat:
Osiris : 8347ms
Curry : 565ms
Beelzebubu : 770ms
Sponz : 1379ms
Oisyn : 1165ms

Terwijl ik nu met de maximize speed presetting en any suitable inline function expansion krijg:
Osiris : 8347ms
Curry : 510ms
Beelzebubu : 555ms
Sponz : 1344ms
Oisyn : 725ms

En met only __inline function expansion:
Osiris : 8427ms
Curry : 780ms
Beelzebubu : 545ms
Sponz : 1385ms
Oisyn : 770ms

Weer met any suitable inline function expansion, maar met asm versie:
Osiris : 8420ms
Curry : 710ms
Beelzebubu : 730ms
Sponz : 1375ms
Oisyn : 690ms
OisynAsm : 504ms

Zelfde settings, andere volgorde:
OisynAsm : 544ms
Osiris : 8400ms
Curry : 570ms
Beelzebubu : 561ms
Sponz : 1350ms
Oisyn : 730ms

[Verwijderd]

Op woensdag 29 augustus 2001 22:52 schreef curry684 het volgende:

code:

    Osiris : 9063ms
     Curry : 842ms
Beelzebubu : 591ms
     Sponz : 1492ms
     Oisyn : 831ms

[...]
In ieder geval hulde aan Beelzebubu

Toch vebazend, ik zou verwachten dat die van jou in elk geval niet langzamer zou zijn dan die van mij - met optimizations en alles.

/me gaat feestje vieren

[Verwijderd]

Hier nog wat gcc-resultaten. Alles ecompilet met "g++ snelheid.c -o snelheid (-Ox)", x=2,4,6 (of die optie helemaal niet).

code:

(geen optimalisatie)
[30 Aug - rbultje@tux rbultje]# ./snelheid
    Osiris : 5105431us (millisec)
     Curry : 2322768us (millisec)
Beelzebubu : 2273753us (millisec)
     Sponz : 3199339us (millisec)
     Oisyn : 2135567us (millisec)
[30 Aug - rbultje@tux rbultje]# 

(optimalisatie 2)
[30 Aug - rbultje@tux rbultje]# ./snelheid
    Osiris : 11827587us (millisec)
     Curry : 1288543us (millisec)
Beelzebubu : 1550008us (millisec)
     Sponz : 2677270us (millisec)
     Oisyn : 1809922us (millisec)
[30 Aug - rbultje@tux rbultje]#

(optimalisatie 4)
[30 Aug - rbultje@tux rbultje]# ./snelheid
    Osiris : 11768760us (millisec)
     Curry : 1104272us (millisec)
Beelzebubu : 1129384us (millisec)
     Sponz : 2616586us (millisec)
     Oisyn : 1307495us (millisec)
[30 Aug - rbultje@tux rbultje]# 

(optimalisatie 6)
[30 Aug - rbultje@tux rbultje]# ./snelheid
    Osiris : 11790217us (millisec)
     Curry : 1104193us (millisec)
Beelzebubu : 1129888us (millisec)
     Sponz : 2617687us (millisec)
     Oisyn : 1307571us (millisec)
[30 Aug - rbultje@tux rbultje]#

Oftewel, de optimaliatie doet de code van curry meer goeds dan die van mij. Zie -O2. Bij -O4/-O6 zie je ze allemaal (die van curry, mij en oisyn) naar elkaar toekruipen, verschil wordt verwaarloosbaar (die van oisyn blijft overigens steeds 2 tiende slomer).
Zonder optimalisatie is die can mij echter nu het snelst

Die van Osiris is overigens extreem sloom....

Hierbij nog even de code:

code:

// Speed tester
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <sys/time.h>

// Aantal testiteraties (5 miljoen)
const int c_Iterations = 5000 * 1000;

// Hulpmacro
#define Test(p_Method) \
   gettimeofday(&now1, 0); \
   for(i = 0; i != c_Iterations; i++) \
    p_Method(); \
   gettimeofday(&now2, 0); \
   printf("%10s : %dus (millisec)\n", #p_Method, \
    (now2.tv_sec - now1.tv_sec) * 1000000 + now2.tv_usec - now1.tv_usec)

// De methodes

// Osiris
void Osiris() {
   char Msg[] = "Blablabla";
   for(unsigned int i = 0; i != strlen(Msg); i++)
    if(Msg[i] == 'a')
       Msg[i] = 'c';
}

// Curry684
void Curry() {
   char Msg[] = "Blablabla";
   for(char *Pointer = Msg; *Pointer; Pointer++)
    if(*Pointer == 'a')
       *Pointer = 'c';
}

// Beelzebubu
void Beelzebubu() {
   char Msg[] = "Blablabla";
   for(int i=0;Msg[i];i++)
    if(Msg[i]=='a')
       Msg[i]='c';
}

// Sponz
void Sponz() {
   char Msg[] = "Blablabla";
   char *p = Msg;
   while(p = strchr(p,'a'))
    *p='c';
}

// Oisyn/Grum
void Oisyn() {
   char Msg[] = "Blablabla";
   char* Strptr = Msg;
   do
{
    if(*Strptr == 'a')
    *Strptr = 'c';
   } while (*Strptr++);
}

// De main functie
int main() {
   int i;
   struct timeval now1, now2;

   // Process executie naar realtime schuppen voor betrouwbaarheid
   setpriority(PRIO_PROCESS, 0, -1 );

   // Doe de tests
   Test(Osiris);
   Test(Curry);
   Test(Beelzebubu);
   Test(Sponz);
   Test(Oisyn);

   return 0;
}

Conclusie, belzebubu en curry winnen samen, onderlinge strijd nog niet beslist

[.oisyn]

doe mijn asm functie er nou even bij

.edit: oh wacht die had OlafvdSpek gepost... en wel het snelste he

[.oisyn]

Op donderdag 30 augustus 2001 09:10 schreef curry684 het volgende:

[..]

Zou niet uit moeten maken omdat ik Msg in iedere functie opnieuw definieer, ze hebben daarvoor dus allemaal dezelfde overhead.

ik bedoelde dat ze dan allemaal naar dezelfde Msg refereren, ivm cache boundaries. Overigens bedacht ik me later dat ze toch overal wel op hetzelfde stukje geheugen komen, want ze worden op hetzelfde stukje gealloceerd op de stack, aangezien het overal de eerste locale variabele is.

[Verwijderd]

Op donderdag 30 augustus 2001 14:05 schreef OiSyN het volgende:
doe mijn asm functie er nou even bij

.edit: oh wacht die had OlafvdSpek gepost... en wel het snelste he

die van jou zal bij mij ook wel de snelste zijn. Als je wilt kan ik het er nog wel bijgooien voor de fun

[.oisyn]

doe maar, is goed voor mijn ego

[curry684]

Op donderdag 30 augustus 2001 13:58 schreef beelzebubu het volgende:
Oftewel, de optimaliatie doet de code van curry meer goeds dan die van mij.

Daarom wou ik het graag bij andere mensen overgedaan zien. VC++ staat niet bekend als ultiem goed in optimalisatie, en mijn oude Celeron heeft een stuk minder en langzamer cache dan een recente Pentium/Athlon. Allebei kunnen ze feitelijk verschil maken in de resultaten.

Lees Osiris_NL deze topic eigenlijk nog, ik denk dat ie nu toch ondertussen wel voldoende antwoord heeft op z'n originele vraag En al 80 replies on-topic, da's ook best knap

[.oisyn]

Kun je het wisselen van threads in linux ook uitschakelen in een programma (voor superkritieke code ofzo)? Dan moet je dat eens doen, dan heb je minder andere factoren die de tijd omhoog halen

[Sponz]

Nou nog een mainframe (dual risc bak 10 jaar oud):

code:

    Osiris : 35.630  seconden
     Curry : 8.155
Beelzebubu : 8.912
     Sponz : 10.291
     Oisyn : 8.879

volgende keer graag in ansi C of C++ schrijven btw

[PieterJ]

Op donderdag 30 augustus 2001 14:32 schreef curry684 het volgende:

[..]

Daarom wou ik het graag bij andere mensen overgedaan zien. VC++ staat niet bekend als ultiem goed in optimalisatie, en mijn oude Celeron heeft een stuk minder en langzamer cache dan een recente Pentium/Athlon. Allebei kunnen ze feitelijk verschil maken in de resultaten.

code:

    Osiris : 2363ms
    Curry : 501ms
 Beelzebubu : 531ms
    Sponz : 681ms
Oisyn/Grum_ : 470ms

CBuilder 5
Snelheid
proc: AMD 800
OS: W2000

ASM kan ik niet meelinken. Geen tijd om uit te zoeken waarom het niet werkt.

[EDIT] De Oisyn routine aan gepast in Oisyn/Grum_

[Grum]

snif .. ik mis me naam

[.oisyn]

Op donderdag 30 augustus 2001 15:05 schreef Grum_ het volgende:
snif .. ik mis me naam

ow laat ik er nou net patent op hebben aangevraagd.... mag ik effe vangen?

[Grum]

Mja vond et wel funny was iig een leuke oefening

moeten we vaker doen

toch raar dat een forloop soms sneller is dan een while ...

ow!
[/ot]
* Grum gooit een bal

[Verwijderd]

Op donderdag 30 augustus 2001 15:09 schreef Grum_ het volgende:
toch raar dat een forloop soms sneller is dan een while ...

Als je de while met conditie, begin-statement en step-statement maakt dan is for() sneller. Daar is for() namelijk ook ooit voor bedacht


[off-topic]
Hoe compile ik die ASM code in C mee, oisyn? Heb zelf geen ASM-ervaring en snap er dus maar weinig van... Kun je een door C-compilers compilebare functie maken van die ASM code van je?

[Olaf van der Spek]

Volgens mij zijn for/while echt even snel hoor. Ze zijn namelijk functioneel equivalent. Je kunt iedere for als while schrijven en omgekeerd.

Asm met Visual C++:

code:

__asm
{
  xor eax, eax
}

[Verwijderd]

VC deed een bietje vaag met offset, dus dan maar fijn hardcoded naar de stack wijzen Gebruikte code:

code:

void OiSyN_Asm()
{
    char    msg[] = "Blablabla";
    __asm
    {
            lea edx,[esp-0Ch]
    loopstart:
            mov al, [edx]
            or al, al
            jz end
            inc edx
            cmp al, 'a'
            jne loopstart
            mov byte ptr [edx - 1], 'c'
            jmp loopstart
end:
    }
}

Results:

code:

    Osiris : 5532ms
     Curry : 500ms
Beelzebubu : 343ms
     Sponz : 907ms
     Oisyn : 500ms
 OiSyN_Asm : 93ms

Getest op P3/800 VC6, ik zal de intel compiler zo ook even aanzwengelen kijken wat die er van bakt.. als ik align er tussen knikkerde werd ie gek genoeg alleen maar trager...

[Olaf van der Spek]

Align is niet belangrijk, omdat de code/data toch al in de L1 cache zit.

Dit is misschien sneller (afhankelijk van de pipelining).

code:

void OiSyN_Asm()
{
    char    msg[] = "Blablabla";
    __asm
    {
            lea edx,[esp-0Ch]
    loopstart:
            mov al, [edx]
            or al, al
            [b]inc edx[/b]
            jz end
            cmp al, 'a'
            jne loopstart
            mov byte ptr [edx - 1], 'c'
            jmp loopstart
end:
    }
}

[Verwijderd]

inc fucked je zero flag dus dat gaat niet werken..

ik heb 'm inmiddels ook door de intel compiler gesleurd, intresante resultaten...

code:

         Intel   MicroSoft
    Osiris : 3609ms  5532ms
     Curry : 453ms   500ms  
Beelzebubu : 422ms   343ms
     Sponz : 937ms   907ms 
     Oisyn : 579ms   500ms 
 OiSyN_Asm : 156ms   93ms

[.oisyn]

Op donderdag 30 augustus 2001 17:23 schreef OlafvdSpek het volgende:
Align is niet belangrijk, omdat de code/data toch al in de L1 cache zit.

align is WEL belangrijk, zelfs met cache
en idd, zoals Yarvieh al zei, die dec heb ik daar gezet omdat die jz anders niet werkte

[.oisyn]

Op donderdag 30 augustus 2001 17:14 schreef Yarvieh het volgende:
als ik align er tussen knikkerde werd ie gek genoeg alleen maar trager...

hmmm wazig... terwijl die nops maar 1x per functie wordt aangeroepen. 'k Vind trouwens wel dat er een supergroot verschil zit tussen mijn asm functie en de andere c-functies

Maar die functie van osiris schopt nog steeds kont

[Verwijderd]

Wehehe om je ego nog eens extra strelen heb ik 'm ook nog es door vectorC heen getrokken, of ik heb ergens een compiler optie verschrikkelijk verkeerd staan of 't is gewoon een *CRAP* compiler..

code:

         Intel   MicroSoft  VectorC
    Osiris : 3609ms  5532ms     6625ms
     Curry : 453ms   500ms  2109ms
Beelzebubu : 422ms   343ms  1953ms
     Sponz : 937ms   907ms  2922ms 
     Oisyn : 579ms   500ms  2172ms
 OiSyN_Asm : 156ms   93ms    *

*Compileerde niet

[.oisyn]

vectorC ?!?!?!
nog NOOIT van gehoord

.edit: maar aan die tijden te zien is het idd een CRAP-compiler

[Verwijderd]

Op donderdag 30 augustus 2001 18:48 schreef OiSyN het volgende:
vectorC ?!?!?!nog NOOIT van gehoord

http://www.codeplay.com zou een of ander optimizing wonder moeten zijn maar de 1e test (deze) die ik er tegen aan gooi stelt me al behoorlijk teleur..

edit:
Ik had aantal iteraties nog *VEEL* te hoog staan, hij's minder crappy dan ik dacht,sterker nog hij's met Osiris z'n implementatie nog het snelst van de 3

code:

         Intel   MicroSoft  VectorC
    Osiris : 3609ms  5532ms     2016ms
     Curry : 453ms   500ms  609ms
Beelzebubu : 422ms   343ms  578ms
     Sponz : 937ms   907ms  1047ms
     Oisyn : 579ms   500ms  625ms
 OiSyN_Asm : 156ms   93ms    *

[.oisyn]

wie wil m in gcc testen? Hier mijn asm functie in AT&T syntax

code:

void oisyn_asm ()
{
    char Msg[] = "blablabla";

    __asm__ __volatile__ ("
      loopstart: \n
        movb (%%edx), %%al \n
        orb %%al, %%al \n
        jnz endb \n
        incl %%edx \n
        cmpb $97, %%al \n
        jne loopstartb \n
        movb $99, -1(%%edx) \n
        jmp loopstartb \n
      end:"
    :
    : "d" (Msg)
    );
}

[.oisyn]

t ziet er al beter uit ja... maar een compiler die geen inline asm kan is nog steeds een CRAP-compiler

[Verwijderd]

Paar typos joh!

code:

    Osiris : 3624811us (millisec)
     Curry : 799488us (millisec)
Beelzebubu : 820976us (millisec)
     Sponz : 1587067us (millisec)
     Oisyn : 911884us (millisec)
 oisyn_asm : 107143us (millisec)

P3/800 wederom..

[.oisyn]

ah kijk eens aan
maar ik blijf me nog steeds verbazen over het feit dat zo'n simpel asm functietje 7x zo snel is als de op-een-na-snelste

na ja met deze compiler dan , maar met die van microsoft was het nog altijd 3.5x zo snel

[Verwijderd]

Op donderdag 30 augustus 2001 19:06 schreef OiSyN het volgende:
t ziet er al beter uit ja... maar een compiler die geen inline asm kan is nog steeds een CRAP-compiler

Mja hij kan wel inline asm maar gaat over z'n nek van die lea instructie.

[im_ik]

MMmm ik denk dat naar aanleiding van dit draadje toch maar X86 asm ga leren..
Ik dacht dat het voor snelheid niet zoveel meer uitmaakte.
Maar blijkbaar nog ruimschoots genoeg om je tijd eruit te halen..

[Verwijderd]

Op donderdag 30 augustus 2001 18:49 schreef Yarvieh het volgende:

code:

         Intel   MicroSoft  VectorC
    Osiris : 3609ms  5532ms     2016ms
     Curry : 453ms   500ms  609ms
Beelzebubu : 422ms   343ms  578ms
     Sponz : 937ms   907ms  1047ms
     Oisyn : 579ms   500ms  625ms
 OiSyN_Asm : 156ms   93ms    *

/me is trots dat hij nog steeds de snelste C-methode is

ik zal zometeen die AT&T implementatie dinges van jou eens proberen, ik kreeg de normale met __asm__ niet gecompilet... Zal wel aan mij liggen, ik ben een ramp met asm . (ohja: [klein] gezocht - asm-howto [/klein])

[im_ik]

asm tot

[Olaf van der Spek]

Op donderdag 30 augustus 2001 18:32 schreef OiSyN het volgende:

[..]

align is WEL belangrijk, zelfs met cache
en idd, zoals Yarvieh al zei, die dec heb ik daar gezet omdat die jz anders niet werkte

Wat voor voordeel heeft die dan als alles al in de cache zit?
En wat als je die inc (was toch geen dec) nog eentje naar boven zet?

[Verwijderd]

Op donderdag 30 augustus 2001 21:17 schreef OlafvdSpek het volgende:
En wat als je die inc (was toch geen dec) nog eentje naar boven zet?

Inc reset je Zeroflag dus het resultaat van je cmp gaat verloren dan.

edit:
ow wacht kwartje valt nu pas , ff proberen