Assembly: Hvordan begynne i Assembly?

[GeirGrusom]

Ta f.eks eksperimentet vårt ovenfor hvor kompilatoren var like rask som assembly-programmet.

 

Betrakter du det som en vitenskapelig test eller mer som et ad hoc eksperiment (der jeg er svært usikker på hvor mye assembly LonlyMan egenglig kan) ?

 

Hvor god var egentlig problemstillingen?

Ser ikke noe galt med LonelyMans assembly-kode. Om du tror du slår LonelyMan og Visual studios optimaliserer er det bare å slå seg løs, vis oss din assembly.

 

Du leser med andre ord ikke det jeg skriver grundig nok?

 

PS, merk at hverken jeg eller noen andre her hevder at en kompilator alltid vil lage bedre kode enn en assembler-programmerer.

 

Det jeg sier er at en kompilator med en god optimaliserer kommer såppas nært opptil optimal bruk at det er godt nok, de fleste steder, ....

 

Hva bygger du det utsagnet på?

 

Skannet du artiklein i PDF domumentet: http://www.dinitside...astFractals.pdf

 

Det ser jeg på som en grundigere test enn den spytt på blyanten testen jeg har sett i denne tråden.

 

Hvilke krav stiller du til en vitenskapelig test? Hva vet du om tilsynelatende sammenheng, spuriøs korrelasjon, korrelasjon og kausalitet?

 

Er korrelasjon en nødvendig betingelse for årsakssammenheng? Hvor mange muligheter og mulige mønstre er der med et 64 bits assembly instruksjonssett?

Du vil implementere Mandelbrot i C og i Assembly for å sammenligne ytelsen?

 

Assembly kan være raskere, spesielt i dag med Vector Extensions, SSE 3/4 og alt mulig annet som finnes av godsaker på prosessoren. Men helt normale programmer har man sjeldent stort å tjene på å skrive i Assembly. Det er viktigere å finne en optimal algoritme enn å drive med assembly-optimalisering.

 

Jeg kan ikke fatte helt hvorfor det skal være et poeng å lage noen vitenskapelig undersøkelse på dette. Ved siden av en relativt neglisjerbar ytelsesfordel, så ligger det ulemper å bruke assembly, som det at utviklingsverktøyet ikke får noen som helst overblikk over koden, og kan følgelig hjelper deg svært lite. Det er ekstremt tidkrevende å skrive gode unit-tester, og alle disipliner som objektorientering eller funksjonell programmering er ekstremt tidkrevende å gjennomføre. koden vil nødvendigvis være ekstremt dyr å vedlikeholde, og å få en annen utvikler til å sette seg inn i hva som foregår vil være ekstremt dyrt.

Ved siden av det så er koden på grunn av disse tingene vanskelig å debugge. Dersom programmet skal porteres, så må hele forbanna driten skrives på nytt.

[Gjest Slettet+9871234]

Jeg kan ikke fatte helt hvorfor det skal være et poeng å lage noen vitenskapelig undersøkelse på dette. Ved siden av en relativt neglisjerbar ytelsesfordel,

 

Ser du motsetningen mellom det som er skrevet med rødt og det som er skrevet med uthevet skrift? Den artiklen skriver om en ytelsesforbedring på 100.

 

... så ligger det ulemper å bruke assembly, som det at utviklingsverktøyet ikke får noen som helst overblikk over koden, og kan følgelig hjelper deg svært lite.

 

Slik har det alltid vært. Lettere blir det kanskje heller ikke med 64 bits assembly, fler kjerne prosessorer etc. Noe antar jeg er lettere med 64 bits assembly, segmentering er muligens historie?

 

Det er ekstremt tidkrevende å skrive gode unit-tester, og alle disipliner som objektorientering eller funksjonell programmering er ekstremt tidkrevende å gjennomføre. koden vil nødvendigvis være ekstremt dyr å vedlikeholde, og å få en annen utvikler til å sette seg inn i hva som foregår vil være ekstremt dyrt.

Ved siden av det så er koden på grunn av disse tingene vanskelig å debugge. Dersom programmet skal porteres, så må hele forbanna driten skrives på nytt.

 

Her var det mye ekstremt.

 

Hundre ganger raskere er også ekstrem ytelsesforbedring.

 

Assembly programmering enhetstesting og ekstrem programmering hører vel heller ikke så naturlig sammen som i C og C++.

 

På tilsvarende måte som Sibelius, Bethoven, Barch, Grieg, ... komponerte svært ulik musikk er assembly programmering svært individuell.

Endret 10. september 2012 av Slettet+9871234

[GeirGrusom]

Jeg kan ikke fatte helt hvorfor det skal være et poeng å lage noen vitenskapelig undersøkelse på dette. Ved siden av en relativt neglisjerbar ytelsesfordel,

 

Ser du motsetningen mellom det som er skrevet med rødt og det som er skrevet med uthevet skrift? Den artiklen skriver om en ytelsesforbedring på 100.

 

Den artikkelen snakker om ytelsesforskjell mellom 16-bit og 32-bit (fra 286 til 386) på en tid da det knap fantes kompilatorer som støttet sistnevnte. Den er ikke relevant for moderne kompilatorer, og poenget er forskjellen mellom 16-bit og 32-bit, ikke mellom Assembly og C.

[Gjest Slettet+9871234]

Den artikkelen snakker om ytelsesforskjell mellom 16-bit og 32-bit (fra 286 til 386) på en tid da det knap fantes kompilatorer som støttet sistnevnte. Den er ikke relevant for moderne kompilatorer, og poenget er forskjellen mellom 16-bit og 32-bit, ikke mellom Assembly og C.

 

Leste du mer enn ingressen?

 

After all, how many of you would read an article about speeding up 386 software by a factor of 100?

 

Artiklen gjør også et stort poeng ut av 64 bits fast punkt (fixed point) matte som den gang ble lettere og mer effektivt implementert i assembly enn av en kompilator i C.

 

Fra side 24.

 

The problem disappears in assembly language, since most 32-bit processors have no problem multiplying 32-bit numbers to form a 64-bit product.

 

I dag har vi ikke samme problem i C, men vi kan ha tilsvarende problemer da 64 bit assembly skulle ha langt flere muligheter til fast punkt matte på store heltall ved å kombinere flere registre. Mener du at kompilert C / C++ kode opererer like presist på og utnytter registrene like effektivt som håndkodet 64 bit assembly?

Endret 10. september 2012 av Slettet+9871234

[GeirGrusom]

The problem disappears in assembly language, since most 32-bit processors have no problem multiplying 32-bit numbers to form a 64-bit product.

I dag har vi ikke samme problem i C, men vi kan ha tilsvarende problemer da 64 bit assembly skulle ha langt flere muligheter til fast punkt matte på store heltall ved å kombinere flere registre. Mener du at kompilert C / C++ kode opererer like presist på og utnytter registrene like effektivt som håndkodet 64 bit assembly?

Artikkelen er alt for gammel til å være relevant. Det er lenge siden C kompilatorer har benyttet 16-bit som word størrelse, og problematikken som skildres er vanskelig å forstå med moderne kompilatorer.

 

Men tja: moderne kompilatorer vil i de fleste tilfeller gjøre en vel så god jobb som håndskrevet assembly, men det kommer fullstendig an på hva det er man ønsker å få til.

Det finnes instruksjoner som enten er vanskelig å kryssimplementere, slik som AVX og iterasjonene av SSE.

Endret 10. september 2012 av GeirGrusom

[Gjest Slettet+9871234]

Artikkelen er alt for gammel til å være relevant. Det er lenge siden C kompilatorer har benyttet 16-bit som word størrelse, og problematikken som skildres er vanskelig å forstå med moderne kompilatorer.

 

Men ad hoc koden du prøvde å kompilere i Visual Studio C++

 

Punkt 1: Du kjører 64 bits kode.

Punkt 2: 14,7 bytes per nanosekund er umulig for dagens datamaskiner. he-he

Det er en alvorlig feil en plass her ja. Det er garantert.

Ah jeg som hadde gjort feil men beregningen. Det var ikke i nærheten engang, 0.06 bytes per nanosekund :/

Men jeg kan vel med fordel bruke en lookup tabell slik som du gjør også.

Kilde: http://www.diskusjon...post&p=19642643

 

var egnet til å dra de konklusjonene noen av dere trekker?

 

Da anbefaler jeg deg at du lærer deg C++ før du uttaler deg så bastant og kategorisk som du gjør om assembly.

 

Og Drogin er online og gir deg lettjente poeng og støtte. Det styrker heller ikke hans innspill.

Endret 10. september 2012 av Slettet+9871234

[Drogin]

Kan du prøve å omformulere deg? Jeg skjønner ikke hva du prøver å si

[Gjest Slettet+9871234]

Kan du prøve å omformulere deg? Jeg skjønner ikke hva du prøver å si

 

Det kan jeg formulere som en hypotese som du eller andre kan teste med vitenskapelige data:

 

H0: Assembly programmering er overlegent høynivåspråk for dem som behersker det.

 

Så er spørsmålet. Er det noen her i landet som behersker assembly? Denne tråden har ikke overbevist meg.

Endret 10. september 2012 av Slettet+9871234

[GeirGrusom]

Artikkelen er alt for gammel til å være relevant. Det er lenge siden C kompilatorer har benyttet 16-bit som word størrelse, og problematikken som skildres er vanskelig å forstå med moderne kompilatorer.

 

Men ad hoc koden du prøvde å kompilere i Visual Studio C++

 

Punkt 1: Du kjører 64 bits kode.

Punkt 2: 14,7 bytes per nanosekund er umulig for dagens datamaskiner. he-he

Det er en alvorlig feil en plass her ja. Det er garantert.

Ah jeg som hadde gjort feil men beregningen. Det var ikke i nærheten engang, 0.06 bytes per nanosekund :/

Men jeg kan vel med fordel bruke en lookup tabell slik som du gjør også.

Kilde: http://www.diskusjon...post&p=19642643

 

var egnet til å dra de konklusjonene noen av dere trekker?

 

Da anbefaler jeg deg at du lærer deg C++ før du uttaler deg så bastant og kategorisk som du gjør om assembly.

 

Og Drogin er online og gir deg lettjente poeng og støtte. Det styrker heller ikke hans innspill.

Hvorfor blir du såpass usaklig?

[Gjest Slettet+9871234]

Hvorfor blir du såpass usaklig?

 

Hva er det som er usakelig?

[Drogin]

Hvorfor blir du såpass usaklig?

 

Hva er det som er usakelig?

Drogins poeng-stemming, Drillo som fotballtrener, XP som utviklingsmetode, og forvaltning av naturresursene på jorda....kan jeg spørre - hva har dette med assembler å gjøre?

 

Pluss din nedrakking av andres kompetanse, uten at du er villig til å demonstrere at du kan noe mer.

Endret 11. september 2012 av Drogin

[Gjest Slettet+9871234]

Drogins poeng-stemming, ...

 

Jeg er mye i politikkforumet. Der gir man ofte (som regel) poeng ut fra person i stedet for argument. Jeg har en mistanke om at du gjorde (gjør) det samme. Mener du at det som ble sagt var så glimrende, så virker det motsatt på meg, ettersom jeg ikke synes det GeirGrusom sa var så glimrende i den sammenheng. Jeg mente tvert i mot at det han skrev var tvilsomt eller direkte galt. Det han skriver i andre sammenhenger kan være glimrende. Alle kan ta feil sa pinnsvinet og klatret ned fra klesbørsten. Les omi igjen og begrunn hvorfor det han skrev var så bra.

 

Drillo som fotballtrener, XP som utviklingsmetode, og forvaltning av naturresursene på jorda....kan jeg spørre - hva har dette med assembler å gjøre?

 

Ok, men jeg hadde ventet meg off topic. Det var ment som en analogi.

 

Pluss din nedrakking av andres kompetanse,

 

Nedrakking eller påvisning av at i en tråd som handler om assembly, greier han ikke å få til riktig C++ kode. Er du og han personer som trenger skryt selv når dere gjør feil, i så fall lurer jeg på deres profesjonalitet. Hårsårhet kaller jeg det.

 

... uten at du er villig til å demonstrere at du kan noe mer.

 

Hva er det du vil? At jeg skal produsere en bedre løsning i assembly? Da har du ikke lest tråden. Det ville nok tatt måneder og år og sette seg inn i 64 bits assembly og blitt en brukbar assembly programmerer. Mitt liv er som jeg gjentatte ganger skriver for kort til å programmere i assembly, så en assembly løsning får du ikke fra meg. Det kunne jo vært interessant å sammenlignet assembly output fra Visual C++ og Rad Studio XE III sin C++ Builder kompilator. Men den har jeg ikke og jeg har heller ikke tid til det.

 

Nå er jeg svært usikker på dine og GeirGrusom sine assembly kunnskaper. Har du noen gang skrevet et manuelt program i assembly? Hvor lenge har du drevet med assembly? Jeg har inntrykk av at du og han aldri har skrevet en linje i assembly. Unnskyld meg om jeg tar feil. Jeg har skrevet noen tusen linjer i assembly selv om det er lenge siden. Noe husker jeg. Om man bruker registrene effektivt kunne de på eldre maskiner operere lettere på større heltall enn den tids C / C++ kompilatorer som benyttet minnet i stedet. Dette er (var) et marginalt argument for assembly.

 

Oppsummert kan jeg si:

 

Den ad hoc testen som er benyttet i denne tråden er ikke egnet til å devaluere assembly.

 

Det er nettopp det jeg mener dere gjør.

Endret 12. september 2012 av Slettet+9871234

[GeirGrusom]

Nå er jeg svært usikker på dine og GeirGrusom sine assembly kunnskaper. Har du noen gang skrevet et manuelt program i assembly? Hvor lenge har du drevet med assembly? Jeg har inntrykk av at du og han aldri har skrevet en linje i assembly. Unnskyld meg om jeg tar feil. Jeg har skrevet noen tusen linjer i assembly selv om det er lenge siden. Noe husker jeg. Om man bruker registrene effektivt kunne de på eldre maskiner operere lettere på større heltall enn den tids C / C++ kompilatorer som benyttet minnet i stedet. Dette er (var) et marginalt argument for assembly.

 

Oppsummert kan jeg si:

 

Den ad hoc testen som er benyttet i denne tråden er ikke egnet til å devaluere assembly.

 

Det er nettopp det jeg mener dere gjør.

 

Tidligere drev jeg med x86 assembly på fritiden, blant annet til å skrive bootloaderen til et operativsystemprosjekt det var interesse for en kort periode på forumet her (dvorient). Dette var x86-32 assembly. Før det har jeg brukt det til å få til memcpy for en 16-bit C compiler til å gå raskere for bitblit av en framebuffer til VGA.

 

På min forrige arbeidsplass skrev jeg mikrokontrollerkode for servomotorer. I dette tilfellet benyttet vi ARM prosessorer, og innimellom var det behov for å skrive ARM assembly for det. Stort sett brukte vi C (En GCC ARM toolchain som jeg ikke husker navnet på akkurat i farta) fordi det var lite å hente på å skrive assembly. Det åpnet også for å bytte prosessor uten alt for mye arbeid.

 

Til daglig jobber jeg som IT konsulent i OKB AS, og akkurat nå jobber jeg med et betalingsprosjekt for et ganske stort firma som driver med betalingsløsninger. Der går det nesten utelukkende i C# da det er dette som benyttes av bedriften.

 

På fritiden skriver jeg et spill i C++11 med OpenGL. Akkurat nå benyttes OpenGL 3.1 fordi det er det laptoppen min støtter. I det spillet har jeg skrevet en marching tetrahedons implementasjon, og jeg er ganske fornøyd med hastigheten på den.

 

Men kvalifikasjonene til Drogin, LonelyMan og meg burde egentlig strengt tatt være irrelevant, ettersom vi skal diskutere sak, ikke person.

LonelyMan er dyktig i x86 assembly, ingen tvil om det, men det var heller ikke diskusjonen. Saken her er om C kompilatorer kan være vel så bra som håndskrevet assembly. Konklusjonen min, og Drogin var ikke at C alltid er raskere enn håndskrevet assembly, og ingen har hevdet det heller. Assembly har bruksområder, og jeg nevnte noen, men for det meste er ytelsesøkningen neglisjerbar i forhold til tidsinvesteringen som kreves, og hvor fort Assembly generelt vil gi fra seg code smell.

 

Det jeg hevdet angående dokumentet var at konklusjonen der var at 386 var vesentlig raskere enn x86, og ettersom kompilatorer fra 1988 generelt bruke 16-bit word, så kunne de ikke alltid ta for seg overflow for 64-bit operasjoner. Der kom x86 assembly inn, fordi 386 har add with carry og lignende funksjoner for å kunne benytte seg av 64-bit heltall på en realtivt effektiv måte.

 

Deretter skled du ut i persondiskusjoner når saklige argumenter for bruken av dokumentet ikke vant frem.

[Gjest Slettet+9871234]

Deretter skled du ut i persondiskusjoner når saklige argumenter for bruken av dokumentet ikke vant frem.

 

Du fikk støtte av en som startet diskusjoen med LonelyMann. Dette er sikkert ikke hemmelig. Jeg spiller noen ganger på hest og bruker da Radsoft http://www.radsoft.no sine produkter. Jeg anbefalte noen forbedringe for dem på ePost og fikk dette svaret ved å vise til denne tråden som jeg antar kan publiseres da det bidrar til diskusjonen her:

 

Hei Kjell

 

Leste litt på tråden, er selvsagt interesant. TotoPro er utviklet i Delphi, vi laget en simuleringsmodell i C# tidligere, men den var ikke vesentlig raskere så vi valgte å oppgradere på eksisterende versjon.

 

C++ ville nok økt hastigheten, og garantert også Assembly også, men dessverre har vi ikke ressurser og neppe nok kunnskap heller til å komme opp på det nivået. Tror det ville blitt for dyrt å utvikle også i dette miljøet.

 

Jeg opererer selv med litt store stammer noen ganger, noen ganger litt for store, men generelt har jeg lite problem med hastighet. Men uten bankere er det klart at det blir mye kombinasjoner å gå i gjennom, spesielt på V75.

 

Det var svært interessante opplysninger, siden RAD studio inneholder Delphi og Radsoft valgte å bruke Delphi fremfor C#. Nok et argument for meg personlig at jeg har valgt riktig plattform. Nå tilbys jeg rabatt på RAD Studio XE III oppgradering på ovennevnte seminar i morgen. Bestiller jeg den oppgraderingen, kan jeg jo se om jeg får tid til å teste C++ ASM output fra den siste C++ kompilatoren til Embarcadero.

 

Men noe argument for at dagens C++ kompilatorer gir en så optimal kode at assembly ikke er aktuelt er det ikke.

 

Det er i høyden et argument for den ene eller andre C++ kompilatoren så høy prioritet har det ikke. Jeg bruker altfor mye tid her inne som det er.

 

C++ ville nok økt hastigheten, og garantert også Assembly også, men dessverre har vi ikke ressurser og neppe nok kunnskap heller til å komme opp på det nivået.

 

Min utheving.

 

Det antar jeg gjelder mange norske firmaer.

 

Du fikk altså støtte av en som startet diskusjonen med LoenlyMan, jeg indirekte støtte av en utvikler via ePost.

 

:

Endret 12. september 2012 av Slettet+9871234

[GeirGrusom]

C++ ville nok økt hastigheten, og garantert også Assembly også, men dessverre har vi ikke ressurser og neppe nok kunnskap heller til å komme opp på det nivået. Tror det ville blitt for dyrt å utvikle også i dette miljøet.

Dette er et ganske viktig poeng med diskusjonen. Korrekthet, vedlikeholdbarhet og RAD trumfer hastighet i de aller fleste tilfeller. C og C++ gjør dette bedre enn Assembly, men Delphi gjør dette bedre enn både C og C++, og vil ifra en forretningsmessig synsvinkel være et mer fornuftig valg. Det igjen kommer selvsagt også litt an på applikasjonen.

[LonelyMan]

Lurer på om ikke jeg blingsa da jeg skrev den koden ovenfor. Den var vel 2.27 GB/s, ikke 2.72GB/s.

Men det var jo fortsatt noe raskere enn assembler-programmet.

 

 

Når jeg kompilerer for 32bit, blir programmet mitt omtrent like raskt som ditt:

100MB tar 45-46ms.

 

Det vil si et sted mellom 2.17 og 2.22GB/s.

 

Nå har jeg begynt å kode i flat assembler, jeg har gitt opp masm delvis primært fordi den fungerer dårlig på 64 bits kode. Jeg har skrevet rot13 algoritmen på nytt men denne gang i fasm, det er ingen forskjell på fasm og masm speed-wise, ingen av assemblerne har noen form for optimalisering innebygd så resultatet er akkurat det samme. Men nå har jeg forbedret rot13 funksjonen min og har oppnådd 3,225 GB per sekund (3,2 bytes per nanosekund) og dette med 32 bit kode, ingen 64 bit kode. Dvs jeg mener jeg nå har slått både din 32 bit kode og din 64 bit kode. Min kode kjører ca 45% raskere og den fungerer denne gangen

 

 

proc Rot13 Buf,Antall
  mov ecx,[Antall]
  push esi
  push edi
  push ebx
  mov esi,[buf]
  mov edi,Rot13Buf
  push ebp
  mov ebp,ecx
align 16
.x:mov eax,[esi]
  mov edx,eax
  movzx ebx,ah
  bswap edx
  and eax,0FFh
  movzx ecx,dh
  and edx,0FFh
  prefetchnta [esi+32]
  mov dl,[edi+edx]
  mov dh,[edi+ecx]
  bswap edx
  mov dh,[edi+ebx]
  mov dl,[edi+eax]
  mov [esi],edx
  lea esi,[esi+4]
  sub ebp,1
  jnz .x
  pop ebp
  pop ebx
  pop edi
  pop esi
  ret
endp

 

Om jeg skriver rot13 i 64 bit kode regner jeg med å kjøre koden 3 ganger raskere estimert. Jeg har en anelse hvordan jeg vil gå frem der.

Endret 28. september 2012 av LonelyMan

[LonelyMan]

6,25 GB per sekund (6,25 bytes per nanosekund) og fremdeles 32 bit kode her. 281% raskere enn konkurrenten min.

 

proc Rot13 Buf,Antall
  mov ecx,[Antall]
  push esi
  push edi
  push ebx
  mov esi,[buf]
  mov edi,Rot13Buf
  push ebp
  mov ebp,ecx
align 16
.x:prefetchnta [esi+64]
  mov eax,[esi]
  mov edx,eax
  movzx ebx,ah
  bswap edx
  and eax,0FFh
  movzx ecx,dh
  and edx,0FFh
  mov dl,[edi+edx]
  mov dh,[edi+ecx]
  bswap edx
  mov dh,[edi+ebx]
  mov dl,[edi+eax]
  mov [esi],edx
  mov eax,[esi+4]
  mov edx,eax
  movzx ebx,ah
  bswap edx
  and eax,0FFh
  movzx ecx,dh
  and edx,0FFh
  mov dl,[edi+edx]
  mov dh,[edi+ecx]
  bswap edx
  mov dh,[edi+ebx]
  mov dl,[edi+eax]
  mov [esi+4],edx
  lea esi,[esi+8]
  sub ebp,2
  jnz .x
  G = $-.x
  IF G&--#60;65
  display "kode er i cacheline ",13,10
  END IF
  pop ebp
  pop ebx
  pop edi
  pop esi
  ret
endp

Endret 28. september 2012 av LonelyMan

[Antoweif]

Hva bruker man slik kode til egentlig?

[LonelyMan]

Antoweif, i dette tilfellet er det bare en konkurranse om hvem som klarer å lage den raskeste rot13 funksjonen og rotere 100 MB med data raskest.

 

Utover dette, det eneste jeg kan tenke meg er at dette kan brukes til en rot13 server, som vil klare uhorvelig mye throughput fra flere klienter samtidig. Og om du tar koden min og kjører over flere kjerner samtidig vil det bli enda mer throughput ( jeg kjører denne fra en kjerne )

Endret 28. september 2012 av LonelyMan

[LonelyMan]

Jeg har tatt en nøyaktig måling av koden med høypresisjons målere og kommer på 15 ms for 100 MB med data. Så den roterer 6,66 GB per sekund eller 6,66 bytes per nanosekund. Den forrige målingen var gjort med medium presisjon.

 

For å sette det i perspektiv, om du skal rotere en helt vanlig streng, la oss si denne strengen her:

 

"Jeg heter Bob Kåre og jeg liker vafler og cola",0 som er 46 bytes uten null terminatoren. Så vil det ta 6,9 nanosekunder å ciphre den. Det er 1000 nanosekunder i et mikrosekund og 1000 mikrosekunder i 1 millisekund og 1000 millisekund i et sekund for å sette det i perspektiv. En spyflue rekker ikke registrere bevegelser på den korte tiden engang, det er som om ingenting hadde skjedd i det hele tatt. Min konkurrent sin c++ kode så vil det ta 20,7 nanosekunder å gjøre den samme jobben. Men det er ikke denne lille strengen som er viktig, det er til syvende og sist store mengder data som utgjør sekunder, minutter som gjelder. Når vi bruker store mengder data blir det mange sekunder akkumulert.

 

Oppsummert så er resultatet dette:

 

Drogun sin 64 bit kode ciphrer 2,27 GB per sekund

Drogun sin 32 bit kode ciphrer 2,22 GB per sekund

 

Min 32 bit assembler kode ciphrer 6,66 GB per sekund

64 bit kode enda ikke laget.

 

Drogun satte c++ kompilatoren til maksimal optimalisering. Og jeg optimaliserte min kode for hånd. Dvs kompilatoren gjorde sitt beste know-how, og jeg kan ikke si jeg har gjort mitt beste, der er ting jeg enda kan se litt nærmere på. I tillegg vil jeg si at de tingene jeg har endret på i koden min er ikke en algoritme endring, det er en endring i bruk av maskininstruksjoner, og denne endringen kan ikke la seg gjenspeile ved å endre algoritmen i c++ varianten. Det er visse ting som ikke lar seg gjøre i c++. Det fins to felt i algoritme-verdenen, den ene er å endre algoritmen i en pseudo kode (noe som kan gjøres i c++) den andre er å endre algoritmen eller sammensetningen av instruksjoner og det kan kun gjøres i asm.

Endret 28. september 2012 av LonelyMan