Assembly: Lære assembly sier du ? Hvorfor ?

[LonelyMan]

eax, ecx, edx = 3 registre

 

r8d, r9d, rdx, r9d = 4

 

 

 

eax, ecx, edx, r8d, rdx, r9d VS eax, ecx, edx = 200%

 

Beklager feilkalkuleringen i forrige innlegg

 

JUUUUUUUUUUKS! :!:

 

Du er en juksemaker, men jeg synes det er gøy da likevel.

 

Men på siden av dette, spiller det ingen rolle. De tidmålingene vi har gjort med begge systemene forteller meg at det ikke er sammenlignbart. Vi er nødt til å begge bruke en 32 bits windows plattform og så er vi nødt til å utveksle kode for å finne en faktor mellom målingene.

 

Fordi vi har faktisk begge kjørt den eksakt samme asm koden og noe viser seg å ikke stemme mtp hastigheten på begge våre systemer. Samme koden, same code. Uten compiler work, vi brukte begge asm koden som var ferdig skrevet, så ingen kompilator arbeid står bak, forklaringen kan kun skyldes på OS og hardware.

Endret 19. desember 2011 av LonelyMan

[David Brown]

Jeg ser 4 ekstra registre i koden din som jeg ikke har tilgang til, noen av de opererer på 32 bit operander og noen på 64 bit. 4 ekstra registre er helt katastrofalt i en sammenligning. 4 ekstra registre betyr at du har 225% av mine general purpose registre tilgjengelig.

 

Til det du skrev over, lag gjerne en funksjon som ikke er for tidkrevende, noe enkelt så kan du skrive den ferdig så kan jeg forsøke å optimalisere den.

 

Men jeg liker ikke at du genererer assembler listing, så legger inn asm forandringer i denne listingen og så kommer på forumet og sier at dette er "compiler work", den oppførselen er kjedelig og virker dårlig.

 

Spesielt kjedelig er det når du koder 32 bits med ekstra registre. Dette tar toppen av kaka.

 

Alle assembly kode som jeg har lagt ut, bortsett fra "unrolling eksempel" som var soleklart en modifikasjon av din kode, var genererte av kompilatoren min. Jeg har ikke endret på noe av det. Hva ville være vitsen med den? Hele poenget var å vise deg hva kompilatoren lagde.

 

Og selvfølgelig er 32-bit koden uten ekstra registrerer - det er kompilert på en 32-bit maskin for å kjøre på 32-bit maskin. 64-bit koden i post 141 brukte et par ekstra register, men den var jo generete til amd64 ISA. Det at de fleste kalkulasjonene der er 32-bit betyr ikke at det er et slags jukse "32-bit kode med ekstra registers".

 

Jeg skjønner virkelig ikke denne trangen du har for å bevise at jeg jukse på en eller annen måte. Er det så vanskelig å akseptere at kompilatorer generere gode kode?

[David Brown]

eax, ecx, edx = 3 registre

 

r8d, r9d, rdx, r9d = 4

 

 

Du kan ikke telle "r9d" to ganger, og "rdx" er det samme register som "edx" - det er bare brukt i 64-bit modus fordi kompilatoren referere til den som en adresse register (i "lea" instruksjon). Dermed er det to register - "r8d" og "r9d" som kompilator min brukte i 64-bit kode som du ikke hadde tilgang til i 32-bit kode. De er begge to brukt for å holde immediate verdier, som ellers kan stå direkte i instruksjonene. I mange type kode har ekstra registerer mye å si - det er derfor de ble lagt til av AMD. Men i dette kode har det lite å si - og som bevis må jeg (igjen!) minne deg om at 32-bit koden uten disse registerene kjørte fortere på samme PC enn 64-bit kode.

 

 

eax, ecx, edx, r8d, rdx, r9d VS eax, ecx, edx = 200%

 

 

Jeg vet ikke om problemet ditt er med grunnlegende regning, eller om du ikke kan så mye om x86 som du tror (jeg velger å tro at du ikke skriver feil med vilje).

 

På x86 i vanlig 32-bit protected mode har man 6 generelle register - eax, ebc, ecx, edx, esi og edi. I 64-bit modus har man 8 ekstra - r8 .. r15. I dette tilfelle brukte kompilatoren min 2 av dem. Jeg lar deg regne ut selv hvor stor økning det er fra 6 til 8 - bruk en kalkulator hvis du syns det er vanskelig.

 

 

 

Beklager feilkalkuleringen i forrige innlegg

 

JUUUUUUUUUUKS! :!:

 

Du er en juksemaker, men jeg synes det er gøy da likevel.

 

Men på siden av dette, spiller det ingen rolle. De tidmålingene vi har gjort med begge systemene forteller meg at det ikke er sammenlignbart. Vi er nødt til å begge bruke en 32 bits windows plattform og så er vi nødt til å utveksle kode for å finne en faktor mellom målingene.

 

Fordi vi har faktisk begge kjørt den eksakt samme asm koden og noe viser seg å ikke stemme mtp hastigheten på begge våre systemer. Samme koden, same code. Uten compiler work, vi brukte begge asm koden som var ferdig skrevet, så ingen kompilator arbeid står bak, forklaringen kan kun skyldes på OS og hardware.

 

Dersom du faktisk er interessert i optimisering, assembly programmering, og å få det beste ut av hardwaren din, er det på tid å flytte fra 32-bit windows. 32-bit windows har absolutt sin plass og jeg bruke det ofte - det er det beste systemet for å kjøre de fleste windows programmer. Men til egen programmering, er det vel mer naturlig å kjøre 64-bit - du ønsker jo å kunne få mest mulig ut av systemet. Og jeg syns det er rart at en som er interessert i programmering holder seg til windows. Jeg har ihvertfall ikke tenkt å nedgradere.

[LonelyMan]

Nei, det sier jeg ikke. Kompilatorer er ekstremt god på å bryte ned aritmetiske sammensetninger og finne de rette instruksjonene. Men i de fleste tilfeller, i de aller fleste tilfellene så kan man optimalisere det enda lengre.

 

Den koden du postet på forumet fra din kompilator, jeg ser flere optimaliseringer som kan gjøres der.

Endret 20. desember 2011 av LonelyMan

[David Brown]

Nei, det sier jeg ikke. Kompilatorer er ekstremt god på å bryte ned aritmetiske sammensetninger og finne de rette instruksjonene. Men i de fleste tilfeller, i de aller fleste tilfellene så kan man optimalisere det enda lengre.

 

Den koden du postet på forumet fra din kompilator, jeg ser flere optimaliseringer som kan gjøres der.

 

Det fins ofte små justering man kunne gjøre manuelt for å forbedre kompilator genererte kode. Men i mange tilfeller er det nokså ubetydelige endringer, som flytting rundt litt på registers og litt optimalisering av prologue eller epilogue. I noen tilfelle kan også looper forbedres. Men likevel er disse småting - husk at kompilatoren genererte raskere kode her enn den du skrev med samme algoritme, som kalkulere (i % 3) og (i % 5). Mens du prøve å tenke ut små forbedringer her og der, har kompilatoren funnet ut at å bytte "div" med "imull" gjøre koden mye raskere.

 

Et menneske er gjerne bedre på detaljerte optimalisering av små stykker assembly, og kan fine-tune den innermest koden. Det gjelder spesielt når det er kode som ikke lett kan skrives i C, som regning med carry eller rotate instruksjoner, eller der man kan benytte SIMD. Men kompilatoren er flinkere til å se "the big picture" - flytting av kode til inlining, gjenbruk av kalkulasjoner og data, bruk av mange register (ikke så relevant på register-fattig x86, men aktuelt på amd64 og andre cpu'er), optimisering av konstanter, osv. Moderne kompilatorer kan t.o.m. flytte rundt på data strukture, snu looper inn-ut, osv., for å få bedre bruk av cache. Og kompilatorer er også flinkere til å ta vanskelige detaljer, som i dette tilfelle med endring av "div" til "imull". Ja, du /kunne/ ha gjort det i assembly - men det ville ta mye tid å finne ut hvordan man tok den endringen, og for å verifisere at det faktisk var riktig.

[LonelyMan]

Jeg vet ikke om problemet ditt er med grunnlegende regning, eller om du ikke kan så mye om x86 som du tror (jeg velger å tro at du ikke skriver feil med vilje).

 

På x86 i vanlig 32-bit protected mode har man 6 generelle register - eax, ebc, ecx, edx, esi og edi. I 64-bit modus har man 8 ekstra - r8 .. r15. I dette tilfelle brukte kompilatoren min 2 av dem. Jeg lar deg regne ut selv hvor stor økning det er fra 6 til 8 - bruk en kalkulator hvis du syns det er vanskelig.

 

Jeg sa "general purpose registre" og jeg regnet kun med de så er forkastelig, du har nøyaktig de samme registrene tilgjengelig utover de forkastelige registrene. Det er ingen vits å regne med disse, da kun eax registeret har interne optimaliseringer for aritmetiske operasjoner.

 

esi og edi er ikke forkastelige. "ebc" er ikke ett register, jeg antar du mener ebx, og det er heller ikke forkastelig.

Endret 20. desember 2011 av LonelyMan

[LonelyMan]

Men som jeg sa i tidligere innlegg, selv ikke en diskusjon om registre vil være nok i den sammenhengen vi diskuterer, det er en forskjell mellom våre systemer som vi ikke kan rettferdiggjøre

 

Jeg tror forumet begynner å bli lei denne diskusjonen, la den nå bare ligge.

Endret 20. desember 2011 av LonelyMan

[blackbrrd]

Jeg må si meg helt enig LonelyMan, argumentene til David Brown er veldig overbevisende og har på flere måter illustrert hvorfor man det 99,9% av tiden ikke er gunstig å programmere i assembly.

[LostOblivion]

Jeg er litt usikker på hva det er du prøver å argumentere for, LonelyMan.

 

Det er en grunn til at John Backus utviklet Fortran, at Dennis Ritchie utviklet C, at John McCarthy utviklet Lisp, i tillegg til tusenvis av andre folk som har definert nyttige programmerings- og scriptespråk siden datamaskinens fødsel. Grunnen til at man fortsatt utvikler språk den dag i dag, f.eks. Googles Go, er nettopp fordi det er mennesker som skal skrive software, og da er man nødt til å gjøre det så enkelt og intuitivt som mulig for et menneske å forstå språket.

 

Naturligvis kan ikke alle problemer løses i et hvilket som helst høynivåspråk, derfor burde problemet man har, reflekteres i hvilket språk man velger for å løse problemet, og da er det viktig at man velger et språk som har den riktige mengden abtraksjon fra den underliggende maskinen, slik at man ikke bruker unødvendig mye tid på å løse problemet på en fornuftig og god måte. Derfor har svært mange språk blitt skapt over årene for å skjule underliggende uvesentligheter for utvikleren. Man har assembly for å slippe å skrive maskinkoden, man har C og Java for å slippe å skrive assembly, man har Groovy for å slippe å skrive Java, man har PHP for å slippe å skrive C, osv. (En grov sammenligning, men det gir mening.)

 

Assembly har sin nytte, og den nytten er ikke liten, men i praksis brukes det i dag kun der hvor det virkelig trengs, nemlig 1. fullstendig kontroll over maskinvare (close to the metal-programmering), eller 2. mest mulig ytelse. Du trenger ikke en Ferrari for å ta lappen, eller assembly for å skrive en Hello, World!-app, selv om det utvilsomt er mer moro.

 

Jeg forstår godt at du synes det er gøy å skrive en IRC-implementasjon i assembly, og jeg har fullstendig respekt for det, men la det bli med det, og ikke prøv å generalisere det. Det er ingen tvil om at en god kompilator i de fleste tilfeller kompilerer til svært effektive programmer, som da også mye enklere kan endres i ettertid uten like store konsekvenser som dette ville hatt om man skulle gjort samme endringen i assembly.

Endret 21. desember 2011 av LostOblivion

[LonelyMan]

Jeg må si meg helt enig LonelyMan, argumentene til David Brown er veldig overbevisende og har på flere måter illustrert hvorfor man det 99,9% av tiden ikke er gunstig å programmere i assembly.

 

Du har rett i at c++ er enklere. Det er det eneste du har rett i, men at c++ genererer raskere kode er usant. Jeg har bevisst det i veldig mange innlegg nå, og jeg kan legge frem enda ett bevis. Her er koden som David Brown kompilerte, jeg har nå brukt ca 1 minutt på å kommentere helt basiske dependencies i koden, bare for å se hvor elendig en kompilator er til å foreta seg oppgaver. Absolutt helt elendig, flerfoldige sykluser er tapt i denne koden bare pga dette. Jeg kunne pekt ut en hel haug av andre ting som er dårlig i den genererte koden.

 

Det vil aldri nærme seg asm i optimalisering på noen måter. Det eneste er at man kan foreta seg mediocre optimaliseringer ved noen enkle tastetrykk. Men i bunn og grunn vi som skriver i assembly, vi lagrer koden i biblioteker, og skriver det ikke på nytt igjen, vi har den helt optimale koden med oss for alltid.

 

pushl ebp
xorl ecx, ecx
movl esp, ebp
andl $-16, esp
pushl edi
movl $1431655766, edi        ; Register dependency
pushl esi
xorl esi, esi                ; Register dependency
pushl ebx
subl $20, esp
22 .L4:
movl ecx, eax                
movl ecx, ebx                ; Register dependency
imull edi
sarl $31, ebx
subl ebx, edx                ; Register dependency
leal (edx,edx,2), eax        ; Register dependency
cmpl eax, ecx                ; Register dependency
je .L2
movl $1717986919, eax        ; Register dependency
imull ecx                    ; Register dependency
sarl edx                     ; Register dependency
subl ebx, edx                ; Register dependency
leal (edx,edx,4), eax        ; Register dependency
cmpl eax, ecx    
jne .L3
L2:
addl ecx, esi
L3:
addl $1, ecx
cmpl $100000000, ecx
jne .L4
movl esi, 4(esp)
movl $.LC0, (esp)
call printf
addl $20, esp
xorl eax, eax
popl ebx
popl esi
popl edi
movl ebp, esp
popl ebp
ret

 

Bare det ene minuttet jeg brukte på å peke ut disse tingene, hvis du retter på det får du 32 % raskere kode. Dvs, kjører den teoretisk sett på 1000 ms så vil den etterpå kjøre på 680 ms. Jeg brukte 1 minutt på å finne dette nå, på denne "supre" kompilator koden.

Endret 22. desember 2011 av LonelyMan

[blackbrrd]

@LonelyMan jeg kan bare sitere David Brown her: "Mens du prøve å tenke ut små forbedringer her og der, har kompilatoren funnet ut at å bytte "div" med "imull" gjøre koden mye raskere."

 

At kompilatoren ikke finner den optimale løsningen på et problem er vi nok enige om, men i 99,9% av tilfellene så lønner det seg å skrive i f.eks c++ og bruke en kompilator. Da kan man jo f.eks lage en 64bits versjon som bruker masse ekstra registre uten vesentlig mer jobb.

 

Det er også litt morsomt å henge seg opp i register dependicies osv, det kan jo godt være at instruksjonene blir utført i en annen rekkefølge enn de er satt opp. x86 prosessorer har jo kunnet kjøre instruksjonene out-of-order og rename registre siden Pentium Pro kom i 1995.

[LonelyMan]

Det er ikke snakk om små forbedringer her og der, det er snakk om mange ganger raskere kode når man har optimalisert den ferdig. Det å bytte div med imull er noe vi alle asm programmerere vet om, det er ikke ett triks en bruker 5 uker på å finne ut av. Jeg vet ikke om du er helt klart over det, men det ER assembler kompetente programmerere som lager kompilatorer, bare for til din opplysning. Det er ikke rene c programmerere som lager dem. C programmerere snakker ett helt annet språk, jeg er asm programmerer og de som lager kompilatorer er også det. Vi er i samme båt. Så når du snakker negativt om assembly, når det er kompetansen innen assembly som er drivkraften til c kompilatorer så synes jeg du skyter gevær i løse lufta. Dessuten er ett c program ikke verdt noenting om en ikke konverterer det til assembly.

 

Det er viktig å forstå at c ikke er ett dataspråk i det hele tatt. Det du skriver i din IDE eller notisblokk, det er pseudokode, som ikke har noen verdens relevans til datamaskiner på noen måte. Det er like mye verdt som ett helt vanlig brev. Det du skriver der er i prinsipp ett brev til den personen som skrev kompilatoren. Kompilatoren sjekker da brevet og ser om du følger reglene som den som skrev kompilatoren satte ned. Bryter du reglene så nekter kompilatoren deg å lage ett program av det.

 

Det skribleriet du lager i c syntaksen er pseudo engelsk, som ikke har noen verdens relevans til datamaskiner i det hele tatt. Det er derfor c også er portabelt språk, det er portabelt fordi det ikke har noenting med datamaskiner å gjøre i utgangspunktet.

 

C++ er ikke ett programerings språk. Det kan legitimt kalles scripting, for du skriver i prinsippet ett script som kjører inni ett annet program (kompilatoren), mens ekte asm, så er oppkoder i prinsipp helt likt proporsjonalt og identisk med mnemonics og kan skrives direkte i binærfiler.

 

Det er viktig å forstå at c ikke er ett dataspråk, men ett mellommenneskelig språk, hvor du kommuniserer med den som skrev kompilatoren.

 

Du som c programmerer kan skrive noe som dette (pseudo) : Make my screen print some pixels.

 

Kompilatoren: Foretar seg en rekke komplekse oppgaver for å bryte dette ned til ett dataspråk som scripteren ikke forstår. Det brytes ned i flere levels.

 

c programmereren kan da si: "set memory to 10"

 

Kompilatoren: foretar seg en rekke komplekse oppgaver, men legger merke til at du har brutt noen regler, så den forteller deg på ett vennlig språk "Du kan ikke gjøre dette, gå tilbake er du snill"

Endret 22. desember 2011 av LonelyMan

[LonelyMan]

Automatikk er fint, men dere som sverger til automatikk lærer aldri noe, og det er tross alt vi som er nysgjerrige, det vil måtte være noen pionerer i fremtiden for å drive dette mesterverket (som vi kaller datamaskiner) videre, det er ingeniører, teknisk anlagte og interesserte som driver det videre. De som sverger til automatikk vil ikke gjøre verden til ett bedre sted.

[LonelyMan]

Og så har vi nisje markedene, militæret f.eks, der kreves det software som er skrevet helt på det laveste nivået. Så er det operativsystemer som krever endel lavnivå programmering. Så har vi kritisk kode i drivere eller andre programmer hvor vi trenger lavnivå programmering. Kompilatorer, der må en hele tiden bruke intel og amd's sine instruksjonsmanualer og optimaliseringsmanualer, gå gjennom hver eneste instruksjon og lage en god kompilator av dette, og dette er assembler programmerere.

 

Det er en populær myte eller vrangforestilling at det er c++ kodere som lager kompilatorer, he-he. Det er vi asm programmerere som lager dem, men de har selvsagt også en lang teknisk utdannelse på toppen. Men de er asm programmerere.

Endret 22. desember 2011 av LonelyMan

[GeirGrusom]

Det er viktig å forstå at c ikke er ett dataspråk, men ett mellommenneskelig språk, hvor du kommuniserer med den som skrev kompilatoren.

Det er da assembly også. Det er ikke støtte for labels i hardware, og ei heller for makroer du finner i en makro-assembler.

En makro assembler skrives på mye samme måten som en annen kompilator. Det er tokenizer, etterfulgt av en parser etterfulgt av en code generator i en assembler også.

[David Brown]

LonelyMan, nå skriver du bare tull. Det er best å avslutte tråden mens du har en snev av verdighet igjen.

 

Du er velkommen til meningene dine, og du er velkommen til hobbyen din som assembly programmerer på x86 windows.

 

Men jeg er ihvertfall lei av din sta nektelse av å se på realitet i dataverden, din nesten totalt manglende forståelse av kompilatorer, programmering, prosessorer, C, kompilator forfatterer, optimisering, osv.

[LonelyMan]

Det er viktig å forstå at c ikke er ett dataspråk, men ett mellommenneskelig språk, hvor du kommuniserer med den som skrev kompilatoren.

Det er da assembly også. Det er ikke støtte for labels i hardware, og ei heller for makroer du finner i en makro-assembler.

 

Det er ikke noe som heter labels i asm. Labels erstattes av en minneadresse, og derfor er den helt proporsjonal, derfor kan du ikke bruke det som eksempel på at asm ikke er rent. I c++ gjør du ting der ting er uproporsjonale. En labels kan du direkte erstatte med en minneadresse, fungererer bare som "huskelapp". Akkurat slik mnemonics fungerer som huskelapper. "mnemonic" betyr "hjelpe å huske"

 

Det du sier om macroer er ikke en assembler sak, det er en utvidet funksjon i noen assemblere, men de fleste rene assemblere støtter ikke macroer, så du skyter deg selv i leggen når du assosierer asm med macroer.

[LonelyMan]

LonelyMan, nå skriver du bare tull. Det er best å avslutte tråden mens du har en snev av verdighet igjen.

 

Du er velkommen til meningene dine, og du er velkommen til hobbyen din som assembly programmerer på x86 windows.

 

Men jeg er ihvertfall lei av din sta nektelse av å se på realitet i dataverden, din nesten totalt manglende forståelse av kompilatorer, programmering, prosessorer, C, kompilator forfatterer, optimisering, osv.

 

Du snakker tåkeprat her, ingen argumenter å vurdere. Og dermed er det du som bør gå videre, du er i asm forumet forresten. Om du ikke liker det, gå til c++ forumet.

[David Brown]

Det er viktig å forstå at c ikke er ett dataspråk, men ett mellommenneskelig språk, hvor du kommuniserer med den som skrev kompilatoren.

Det er da assembly også. Det er ikke støtte for labels i hardware, og ei heller for makroer du finner i en makro-assembler.

En makro assembler skrives på mye samme måten som en annen kompilator. Det er tokenizer, etterfulgt av en parser etterfulgt av en code generator i en assembler også.

 

Jeg er helt enige med deg. I tillegg kjører ikke moderne x86 cpu'er faktisk x86 kode - de oversetter den til interne RISC instruksjoner. Og siden det er slett ikke direkte oversetting - en x86 instruksjon kan ble til flere RISC instruksjoner, og flere x86 instruksjoner kan ble slått til færre RISC koder - må det kalles for en optimaliserende interpreter. Og så er det en del assemblerer til andre cpu'er som optimalisere koden du skriver i assembly.

 

Assembly er så klart et veldig lavt nivå språk, og det er en nær 100% samsvar mellom assembly og machine code, men det er ikke helt det samme. Skal man dermed påstå at C er ikke en programmeringsspråk, gjelder det samme assembly.

[LonelyMan]

David, du har nettopp oversett mitt svar tilbake til Geir, så da er dere begge to i samme båt med feil analysering. Det kommer ikke overraskende at du kommer med enda en feil analysering.

 

Men om jeg skal være snill mot deg og likevel gi deg sjansen til å si at du får lov å regne macroer med inn, så er det ikke nødvendig og langt ifra alle bruker macroer. Dette kan du ikke gjøre i C, der kan du ikke eksludere pseudo språket slik vi kan gjøre i macroassemblere. Vi kan kutte den fullstendig ut, og det vil likevel virke, men i c der må er du avhengig av alle de layerene som er, uansett hva du gjør, uansett hva du sier og uansett hva du liker med det.

 

Så i begge tilfeller vinner jeg argumentet. En assembler ER IKKE en macroassembler, du har forvirret noen enkelte assemblere som har utvidet macro capabilities med rene assemblere.

 

I begge tilfeller vinner jeg.

 

 

Alltid gøy når c++ kodere "vet best" om asm.

Det er som en russisk pengeinnkrever som har kjørt lada i 40 år, så skal han forklare ferrari sjåføren hvordan motoren i ferrarien virker.

Endret 22. desember 2011 av LonelyMan