Assembly: Lære assembly sier du ? Hvorfor ?

[torbjørn marø]

Tilgjengelige bibliotek er jeg enig i, det kommer man ikke bort ifra, men han må aldri finne på å prøve å si at en skriver med 1% av tiden likevel.

så er det også viktig å forstå at de samme bibliotekene som måtte finnes, kan også brukes i assembler, jeg skjønner ikke hvorfor det tas opp, selv om jeg med nød og neppe ikke ville gjort det.

Jeg er fortsatt rimelig sikker på at jeg skulle klart å implementere en enkel irc-klient som støtter IRC-protokollen på rundt 4 timer i f.eks. C# (uten å bruke et ferdig IRC-biblotek). Det er jo en rimelig enkel protokoll, har implemenetrt deler av det for flere år siden.

 

Kan hende jeg tar for lett på det, men tviler.

 

1% var basert på at du sa du hadde gjort halvparten på 3 uker. Jeg tenkte da 3 uker ganger 5 arbeidsdager ganger 7,5 timer ganger 2 for å bli helt ferdig. Det blir 225 timer. 4 timer er 1,8 % av det. Påstår ikke direkte at jeg bare bruker 1% av tiden, men om du bruker så lang tid som du sier, og mine antagelser om arbeidstid er korrekt, så er det konklusjonen.

 

Skulle du derimot laget den type software-løsninger som jeg lager til daglig i ren Assembly, så regner jeg med at du ikke hadde blitt ferdig før instruksjonssettet du benyttet var utdødd. Det finnes begrensninger for hvor mye kompleksitet det er mulig for mennesker å håndtere uten å bygge abstraksjoner som høyere-nivå programmeringsspråk.

 

(( dette var heller ingen sannhetspåstand, men min personlige oppfatning og tro ))

[torbjørn marø]

UPDATE

 

Sitter for tiden og progger litt Rebol. For kick forsøkte jeg å finne en IRC klient i Rebol, siden det aner meg at det ikke ville vært mange linjene. Har ikke funnet enda, men fant dette interessante sitatet:

 

Learned about Rebol from Amiga hacker, History teacher, and friend, Jim, in high school. Didn't really do anything with it until much later when I decided to sit down and learn it properly. Wrote an automated IRC client in under 6 hours, from scratch.

http://mytechne.com/programming-languages/rebol/

 

Dette beviser selvsagt ingen ting, men tror man vedkommende her laget han altså en IRC-klient helt fra scratch på 6 timer i et språk han egentlig ikke kunne. Har du et foreløpig timeantall på den uferdige Asm-klienten?

[LonelyMan]

torbjørn, "automated irc client" betyr som regel en bot, og boter har absolutt minimal funksjonalitet. Det er ikke noe problem å lage en irc klient og noen få kommandoer, men jeg tror nok du undervurderer kompleksiteten. Der er mer enn du tror.

[LonelyMan]

så assembler er ett rent dataspråk.

 

Kan du forklare hvordan assembly kommuniserer med elektronikken/komponentene i PCen/hvordan fungerer det?

Det gjør du ikke normalt under windows, du bruker API funksjoner ellers så må du lage priviligerte systemdrivere. Men ellers så må du lære deg å kode PIC.

[torbjørn marø]

torbjørn, "automated irc client" betyr som regel en bot, og boter har absolutt minimal funksjonalitet. Det er ikke noe problem å lage en irc klient og noen få kommandoer, men jeg tror nok du undervurderer kompleksiteten. Der er mer enn du tror.

Skjønner det. Vet det er mye kompleksitet om man ønsker å støtte alle serverne som finens der ute, men selve standarden er ikke så fryktelig stor.

 

Begynte som sagt på dette arbeidet en gang, men så fant jeg et enkelt biblotek som gjorde jobben, og da var det ikke mye poeng

 

Poenget er at det ikke er noen vits i å forsøke å få det til å fremstå som om Assembly er et verktøy det kan være fornuftig å bruke til hva som helst. De fleste oppgaver vil det ta lengre tid å løse. Selv om det ikke er mere komplisert så vil det rett og slett bli mer kode å skrive i Asm. Og når kompleksiteten øker vil det også bli mye vanskeligere.

 

Og på den andre siden er det ingen vits å påstå at assembly-programmering er ubrukelig. Det finnes mange områder hvor Asm er fornuftig. Det viktige er å vite når det er det riktige verktøyet - og i tvilstilfeller er det viktig å vite hvilke kostnader og verdier det har.

[LonelyMan]

Det er mange ting c++ kodere skal være glade for, for å si det sånn. Det er ikke alltid lett å sitte på bunnen av "ernæringskjeden"

[torbjørn marø]

Hvor vanlig er det forresten å benytte seg av inline assembly i C/C++ ?

[David Brown]

assembly kan være greit å kunne, driver selv å leker en del med mikrokontrollere og det kan være veldig praktisk å skrive løkker som skal utføres mye i Assembly da det kreves færre klokkesykluser å utføre en løkke i ASM enn i f.eks C

 

Hvis du unroller løkken, lagrer stackregistre og andre viktige registre så kan du kjøre hele løkken med bare registre. Eliminer register dependencies, og koder du programmet slik at du bruker v og u pipe riktig og/eller hvis du koder for en nyere prosessor har du 4 piper du kan bruke, align koden så får du hastigheter som er helt umulig å komme i nærheten å gjenspeile i c++.

Eller så kan du få C++ kompilatoren til å gjøre dette for deg. Den kan faktisk inline kode, unrolle loops osv.

 

Ja at kompilatorer kan optimalisere er en kjent sak. Vi snakket dog om nytten av asm i det innlegget du refererte til.

 

At kompilatorer kan optimalisere er dog ikke en erstatter for god asm optimalisert kode. Inline asm er begrenset mtp overhead og muligheter til å gjenbruke registre, jeg har alltid sett på inline asm som noe tilsvarende som å putte ei maur i en grisebinge for å fore grisene og så konkludere med at det fikk god effekt. Det kan dog ha effekt i mange tilfeller hvor en kjører loops.

 

Hvis du har ett eksempel på hvor c++ kompilatoren unroller og optimaliserer en del av koden din, så paste gjerne inn her så kan jeg se på den.

 

Det ser ut for meg at du har et veldig begrenset erfaring med både prosessorer og kompilatorer.

 

Det var et tid da det lønte seg å skrive i assembly på PC'er. Men den tiden er forbi for lenge siden, av tre grunn - prosessorer har blitt mye mer kompliserte, kompilatorer har blitt mye flinkere, og programmer har blitt større og mer kompliserte. Det er selvfølgelig fortsatt mange område der assembly er nyttig eller nødvendig - men ikke til generelle programmering på de fleste cpu'ene.

 

Dersom hastighet er viktig, er det forst og fremst algoritme som er viktigst. Jo høyre nivå språk man har, jo lettere det er å prøve ut og optimalisere algoritmene. Det er derfor interpreterte språk som Python kan ofte gi raskere programmer enn lavnivå språk som C og C++, som igjen gir raskere programmer enn assembly.

 

Når man da har det beste algoritme i C eller C++, og har funnet ut (med profilering, ikke gjetting) hvor flaskehalsene ligger, kan man optimalisere koden. For å få det beste ut av kompilatoren må man kjenne den godt, og lese manualen. Det at du lurer på hvordan en kompilator unroller koden viser at du aldri har lært så pass mye om en (god) kompilator.

 

Er det veldig kritisk her, så hjelper det hvis du kan forstå den genererte assembly kode mens du jobber med kompilatoren og koden under optimalisering.

 

Jeg nevnt at prosessorer har blitt mer avanserte. Kjenner du til alle detaljer rundt timing, pipelining, scheduling, branch buffers, interlocks, osv., i prosessoren du jobber med? Det gjør kompilatorene - men det gjør veldig, veldig få assembly programmerer (på større cpu'er, selvfølgelig). Kjenner du til hvordan det variere mellom forskjellige prosessorer med samme ISA? Du sier du liker å ha alt i registers - vet du hvor stor forskjell det gjør å lagre data på stack istedenfor i en register? (Hint - på moderne x86 cpu'er, er mange stack operasjoner gjort like raskt som register operasjoner.) Vet du hvor mye sykler som blir bortkastet fra interlocks og pipeline stalls p.g.a. overbruk av registers?

 

Med andre ord, svært mye av det du tror er optimalisering lager faktisk være kode. Og med en gang du endre prosessoren - selv om det er samme ISA - er alt bortkast.

 

Det er selvfølgelig klart at alt som kan skrives i C eller C++ kan skrives minst like raskt i assembly. Men det er feil hvis man begrenser seg til assembly som er forstålig og vedlikeholdsvennlig. Kompilatoren har muligheter til optimalisering som constant propagation, inlining, strength reduction, load and store hoisting, osv., som en assembly programmer ikke kan bruke i samme grad og likevel skrive kode av god kvalitet. Og dersom du bruke en mer moderne ISA enn x86, med mange registerer, er det ennå verre.

 

 

Når alt det er sagt, er det fortsatt plass til assembly. Det er veldig nyttig å kunne forstå assembly dersom man skal lage raskest mulig kode, eller jobber med veldig lavt nivå kode. Det er enkelte type oppgaver der assembly kan gi en betydelig fordel, spesielt i looper som bruker SIMD og vector instruksjoner (med kompilatorer har blitt flinkere til å benytte seg av disse). Det er enkelte type oppgaver som krever assembly, fordi C eller C++ har ingen måte å beskrive problemet (typisk veldig lavt nivå kode). Og det fins prosessorer (brukt i små mikrokontroller) som er så begrenset at det kompilator-generert kode blir sjelden effektivt.

 

Men den eneste grunnen til å skrive en IRC klient i assembly er for gøy. Det er en god grunn i seg selv, men det er ikke fornuftig arbeid.

 

Og det eneste grunn til å tro at man kan lage en bedre IRC klient i assembly enn i C eller C++ er at man ikke mestre C eller kompilatoren.

[David Brown]

Hvor vanlig er det forresten å benytte seg av inline assembly i C/C++ ?

 

Det kommer an på hva type programmering man gjør. Til generelle programmering på PC'er, er det svært sjelden. I embedded programmering er det mer vanlig å ha litt, men det er typisk gjemt vekk i makros eller egen funksjoner.

 

Det også kommer an på kompilatoren. gcc er veldig flink til å integrere inline assembly med resten av koden, og (gitt at du skrive assembly'en riktig) kan gjøre mange optimiseringer med koden. En del andre kompilatorer får panikk med inline assembly og dermed slår av alt av optimilisering i nærheten.

[LonelyMan]

Dersom hastighet er viktig, er det forst og fremst algoritme som er viktigst. Jo høyre nivå språk man har, jo lettere det er å prøve ut og optimalisere algoritmene. Det er derfor interpreterte språk som Python kan ofte gi raskere programmer enn lavnivå språk som C og C++, som igjen gir raskere programmer enn assembly.

 

Hvis du har en rutine du har skrevet i c++ som du mener kan kjøre raskere enn jeg får til i asm, så er jeg åpen for at du deler debuggerdata med meg så skal jeg ta utfordringen. Deretter kan jeg dele hastighetstabell før og etter.

Endret 9. desember 2011 av LonelyMan

[torbjørn marø]

Et par relevante sitater:

 

Language shapes the way we think and determines what we can think about.

- Benjamin Lee Whorf

 

That language is an instrument of human reason, and not merely a medium for teh expression of though, is a truth generally admitted.

- George Boole

 

By relieving the brain of all unnecessary work a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of of the race.

- A.N. Whitehead

 

Det er poenget med språk hvor man har gode abstraksjoner.

[LonelyMan]

torbjørn marø, jeg er ikke uenig, men det er flere problemer med sistnevnte sitat:

 

1: Så komplekst språket blir, så kompleks stimulans får hjernen din, og så mye kan du lære av det. Jo mindre stimulering, jo mindre lære.

 

2: Det å bli stimulert av måten en koder i asm, det stimulerer deg til å tenke bedre, og dermed løse andre komplekse problemer bedre.

 

3: Det at en bruker mye tid på selve språket og ikke så mye på ett komplekst problem, det kan lære en å løse det komplekse problemet på en mer kompleks måte og resultatet blir bedre. Det at du fokuserer på ett komplekst problem med minimalt fokus på språket, kan gjøre at du løser det komplekse problemet med et dårligere resultat, siden du har mindre fokus på fremgangsmåten enn på selve løsningen.

 

4: Det at en fokuserer på språket mer enn andre språk, det tar sin tid selvfølgelig, men der er da ikke SÅ mye mer en fokuserer på i asm hvis en virkelig har instruksjonene intuitivt i hodet. Jeg tror at de som ikke er vant med asm, de ser på det som unødvendig mye tullball, men jeg kan forsikre de som ikke er vant med det, med tiden så flyter det så vakkert, og man kan nesten ikke se tilbake igjen, slik føler jeg det iallefall.

[David Brown]

Dersom hastighet er viktig, er det forst og fremst algoritme som er viktigst. Jo høyre nivå språk man har, jo lettere det er å prøve ut og optimalisere algoritmene. Det er derfor interpreterte språk som Python kan ofte gi raskere programmer enn lavnivå språk som C og C++, som igjen gir raskere programmer enn assembly.

 

Hvis du har en rutine du har skrevet i c++ som du mener kan kjøre raskere enn jeg får til i asm, så er jeg åpen for at du deler debuggerdata med meg så skal jeg ta utfordringen. Deretter kan jeg dele hastighetstabell før og etter.

 

De største fordelene for kompilatoren når det er større funksjoner, når den kan slå sammen flere funksjoner, og når den kan benytte informasjon om konstant verdiene eller gjenbruk av kalkulerte verdier. Det gjør at det pleier å kreve mer enn en enkel funksjon for å se effektene.

 

Du må huske at det er ikke spørsmål om du /kan/ skrive raskere assembly kode. Det er spørsmål om du ville ha skrevet raskere assembly kode i en virkelig programmeringsoppgave, der det er viktig at koden er klar, at det kan vedlikeholdes, at det kan lett modifiseres og gjenbrukes, og at man skriver den etter fornuftig tidsbruk.

 

For eksempel, hvis vi tar koden:

 

static const int a = 3;

static const int b = 5;

static const int c = 67;

int quadratic(int x) {

return (a * x * x + b * x + c);

}

 

Kode genererte til en Coldfire prosessor:

 

quadratic:

43 0000 222F 0004 move.l 4(%sp),%d1 | x, x

44 0004 2041 move.l %d1,%a0 | x,

45 0006 41F0 1A05 lea 5(%a0,%d1.l*2),%a0 |,

46 000a 2008 move.l %a0,%d0 |, tmp37

47 000c 4C01 0800 muls.l %d1,%d0 | x, tmp37

48 0010 0680 0000 add.l #67,%d0 |,

48 0043

49 0016 4E75 rts

 

Jeg regner med at du kan skrive like god assembly på en generelle quadratic funksjon som kompilatoren. Men du må velge om du skal skrive en funksjon som fungere på alle verdier av a, b, c, eller om du skal optimisere for bare de bestemte verdiene. Lager du en fleksibel funksjon, er det mye tregere enn den her. Men lager du en spesialiserte funksjon, må du skrive det om igjen dersom en av verdiene a, b, eller c endres. Du taper konkurransen uansett hvilken du velger.

 

Og det er selv uten å ta med det faktum at moderne programmer må kunne kjøre på flere forskjellige prosessortyper. Selv om du begrenser det til Windows verden (som ville være veldig merkelig for en assembly programmerer), er det to ISA'er som er i vanlig bruk i dag (x86 og amd64), og ARM blir en viktig platform for Windows i framtiden.

 

 

Som sagt er assembly programmering en nyttig verktøy, og i min jobb kan man ikke være en topp utvikler uten å kunne tenke og skrive assembly - men du må kjenne begrensningene og lære å bruke de rette verktøyene til rette formål.

[LonelyMan]

Nå har ikke jeg en assembler for din arkitektur tilgjengelig så da blir jeg bare nødt til å konkludere med at du har bare tatt med en enkel kalkulasjon, som i seg selv utelukker optimaliseringer som kunne vært gjort rundt denne lille delen. En enkel optimalisering jeg ser i øyeblikket er lasting av data i registrene, som regel tar disse 5 sykluser og kunne vært gjort i forveien for å begrense ventetiden

 

Disse to instruksjonene:

 

46 000a 2008 move.l %a0,%d0 |, tmp37

47 000c 4C01 0800 muls.l %d1,%d0 | x, tmp37

 

De skaper en halt i prosessoren, og den dobler antall sykluser som trengs enn hvis du hadde shufflet instruksjonene rundt. Bare i denne delen kunne jeg doblet hastigheten.

[GeirGrusom]

2: Det å bli stimulert av måten en koder i asm, det stimulerer deg til å tenke bedre, og dermed løse andre komplekse problemer bedre.

Eller så pragmatiserer du alle problemer til den enkleste løsningen og kvier deg for å erstatte et komplekst problem fordi du har brukt tre uker på å løse det i utgangspunktet, selv om det hadde tatt en ettermiddag å gjøre det samme i et annet språk.

[LonelyMan]

2: Det å bli stimulert av måten en koder i asm, det stimulerer deg til å tenke bedre, og dermed løse andre komplekse problemer bedre.

Eller så pragmatiserer du alle problemer til den enkleste løsningen og kvier deg for å erstatte et komplekst problem fordi du har brukt tre uker på å løse det i utgangspunktet, selv om det hadde tatt en ettermiddag å gjøre det samme i et annet språk.

 

Nei det tar ikke en ettermiddag å erstatte 3 ukers arbeid i asm. Det du mener å si er at det tar en ettermiddag å stjele 3 ukers arbeid, hvilket er ett helt annet scenario. Alle kan stjele.

Endret 9. desember 2011 av LonelyMan

[torbjørn marø]

jeg kan forsikre de som ikke er vant med det, med tiden så flyter det så vakkert, og man kan nesten ikke se tilbake igjen, slik føler jeg det iallefall.

Det er flott å høre. Det er den følelsen jeg elsker. Jeg finner den i språk som Lisp, som er et generelt problemløsningsspråk, helt uavhengig av hvordan datamaskiner fungerer. Du finner den i Assembly, som er veldig tett knyttet til hvordan datamaskinen fungerer. To (svært forskjellige) sider, men av samme sak!

 

torbjørn marø, jeg er ikke uenig, men det er flere problemer med sistnevnte sitat:

 

1: .. komplekst ... kompleks

2: .. komplekse problemer ..

3: .. komplekst problem .. komplekse problemet .. kompleks .. komplekst problem .. komplekse problemet

osv..

Jeg tror jeg stort sett forstår deg. Er ikke helt enig, i alle fall ikke viktigheten av det du sier. Tror ikke du helt har forstått betydningen av abstraksjoner og et fleksibelt språk, og viktigheten av å unngå kompleksitet. Det er også mulig jeg tar alvorlig feil på akkurat det

 

Jeg har ikke gjort særlig mye i Assembly selv, bare et par vekttall på universitetet for mange år siden, og lest litt siden, men har lyst å se mer på det. Har også vurdert å lære meg CIL - det har jeg mer bruk for. CIL er et objektorientert, stack-basert assembly-språk. Tror du det vil være like givende. Vil kunnskapen med CIL være direkte relevant for "native" assembly? Vil du eller andre her anbefale meg å begynne med grunnleggende assembly først kanskje?

[LonelyMan]

Det blir vanskelig, iallefall for MEG å si noe annet enn at native asm var det jeg selv begynte med, og det har jeg holdt meg til siden dos dagene. Det fins noen forskjellige objektorienterte assembly språk der ute. Jeg husker ikke navnet på det jeg tenker på, men der fins også assembly bibliotek der som hvor du kan skrive asembly kode med basic syntax, MasmBasic heter det, og det er rimelig kjapt også. Men noen råd har jeg dog ikke

 

Det beste er bare å følge interessen sin.

[David Brown]

Nå har ikke jeg en assembler for din arkitektur tilgjengelig så da blir jeg bare nødt til å konkludere med at du har bare tatt med en enkel kalkulasjon, som i seg selv utelukker optimaliseringer som kunne vært gjort rundt denne lille delen. En enkel optimalisering jeg ser i øyeblikket er lasting av data i registrene, som regel tar disse 5 sykluser og kunne vært gjort i forveien for å begrense ventetiden

 

Disse to instruksjonene:

 

46 000a 2008 move.l %a0,%d0 |, tmp37

47 000c 4C01 0800 muls.l %d1,%d0 | x, tmp37

 

De skaper en halt i prosessoren, og den dobler antall sykluser som trengs enn hvis du hadde shufflet instruksjonene rundt. Bare i denne delen kunne jeg doblet hastigheten.

 

Her viser du soleklart hvor begrenset du er med assembly. For å ta det fra toppen...

 

Du har ikke en assembler for denne arkitekturen. Helt riktig - men med koden skrevet i C har man koden klar til <i>alle</i> arkitekturene, og med kode som dette kan man regne med at det er optimal kode i de alle fleste tilfeller. Det er også en hint at du er begrenset til kun x86 assembly - jeg har programmert i ihvertfall 10-12 forskjellige assembly over 25 år, og tør gjette at jeg har en bredere erfaring enn deg selv om du har mye dypere erfaring en den smale felten av x86 assembly under DOS (og eventuelt Windows). Jeg skal ikke påstå at jeg kan alt - men jeg har lært en god del om både assembly, C, og fordeler og ulemper av begge språkene.

 

Jeg valgte Coldfire fordi den har en assembly som er ganske lett å forstå. En ting du kanskje ikke har fått med deg er at i denne assembly, er rekkefølgen "source, destination". Det eneste litt komplisert instruksjon her er "lea 5(a0, d1*2), a0" som er brukt for å kalkulere "(3*x) + 5" i en instruksjon. Og det viser at kompilatoren har ingen problem med å bruke slike triks, samt Horner's rule. Som sagt, kan kompilatoren dra nytte av konstant verdiene på en måte som assembler programmereren ikke kan dersom koden skal være fleksibel og generelle.

 

Nest, påstår du at "lasting av data i registrene tar som regel 5 sykluser" - en totalt absurd påstand. Faktisk så variere det voldsomt fra prosessor til prosessor, og er avhengig av minne arkitektur og hvor i minne det fins. Selv om du holder deg til x86 verden, kan en instruksjon som leser data fra stacken tar alt fra 1 syklus (om det ligger i "store buffer" fra før) til over 200 sykluser (om det må hentes fra ekstern minne). I praksis kan man jobber ut fra noen cirka tall på pipeline forsinkelse fra en load (man tar som gitt at det er i nivå 1 cache) - noe som kompilatorene gjør. Og siden det variere etter hvilke type x86 cpu man har, pleier kompilatorene å gi brukeren opsjon til å optimalisere etter bestemte typer x86 - noe som assembly programmererer ikke gjør (med mindre enn at de vil skrive koden mange ganger).

 

Du har rett at det ofte hjelper å laste inn data på forveien - og kompilatoren hadde gjort det dersom det var noen vits. Men det er lett å se at i dette tilfelle er det ingenting å vinne fordi hver steg er avhengig av den forrige. Det samme gjelder med de to instruksjonene som du mener burde byttes om for å unngå en pipeline stall - da tror jeg du har misforstått rekkefølgen av source og destination register.

 

Og til slutt påstår du å kunne ha doblet hastigheten - uten at du forstod assembly koden her, uten at du kjente til prosessoren, og uten at du forstod poenget (som var at du ikke kan skrive like raskt kode i assembly og fortsatt være fleksibel med tanke på konstantene).

 

Jeg liker ikke å klassifisere folk, men dette "jeg kunne doblet hastigheten" påstand er veldig typisk av programmerere som er veldig geiret på assembly og tror at det er alltid den raskeste og mest effektive språk.

 

 

Jeg skriver alt dette i håpet av at du lære litt. Jeg vil ikke ta vekk gleden av assembly programmering fra deg, og jeg syns at det er svært viktig at programmererer lærer assembly og forstår hvordan det fungere - de blir bedre programmererer av det. Men du blir <i>ikke</i> en bedre utvikler av å tro at assembly er en fornuftig valg av språk til noe mer enn enkelte niche oppgaver, og du blir ikke bedre av å tro at assembly er en god metode til å få raskeste mulig kode.

[LonelyMan]

Du har ikke en assembler for denne arkitekturen. Helt riktig

 

Det er ikke du som skal bekrefte hva som er riktig med mine egne faktiske forklaringer. Hvis jeg sier at "du har 2 appelsiner i kjøleskapet ditt", så kan du si "helt riktig", men hvis jeg sier noe som du ikke har innsyn i, da skal ikke du si "helt riktig". Dette var bare en liten irritasjonsfaktor som jeg måtte få luftet.

 

- men med koden skrevet i C har man koden klar til <i>alle</i> arkitekturene, og med kode som dette kan man regne med at det er optimal kode i de alle fleste tilfeller.

 

Det er ikke noe som heter "i alle tilfeller", den koden du puttet ut her er spesiell, i c++ er der ikke noe spesiell kode du kan snakke om, og dermed kan du heller ikke si "regne med det er optimal kode", dette er fordervet filosofi og ukorrekte påstander.

 

Det er også en hint at du er begrenset til kun x86 assembly - jeg har programmert i ihvertfall 10-12 forskjellige assembly over 25 år

 

1. Hva jeg er begrenset til eller ikke det blir synsing fra din side.

2. Om du koder mange forskjellige assemblere så er du ikke en spesialist på optimalisering, ei en spesialist i assembler programmering i helhet. Da er du en som spiser sesamfrø fra mange forskjellige kilder, og da blir man skjeldent god på noe.

3. Du snakker demonisk om x86, vel, den utgjør faktisk en utrolig stor del av verdens datamaskiner, du kan ikke sette en motorola 68000 opp mot x86. Den har en fin fortid i amigaen og i min Ti-89 kalkulator.

 

, og tør gjette at jeg har en bredere erfaring enn deg selv om du har mye dypere erfaring en den smale felten av x86 assembly under DOS

 

Du kommer ikke med noe særlig konstruktivt annet enn "jeg er bedre enn deg", "jeg tør vedde", "pappan min er sterkere enn din". Ta deg ei kjøttpølse.

 

Jeg valgte Coldfire fordi den har en assembly som er ganske lett å forstå. En ting du kanskje ikke har fått med deg er at i denne assembly, er rekkefølgen "source, destination". Det eneste litt komplisert instruksjon her er "lea 5(a0, d1*2), a0" som er brukt for å kalkulere "(3*x) + 5" i en instruksjon. Og det viser at kompilatoren har ingen problem med å bruke slike triks, samt Horner's rule. Som sagt, kan kompilatoren dra nytte av konstant verdiene på en måte som assembler programmereren ikke kan dersom koden skal være fleksibel og generelle.

 

Ja, men nå leser den berømte kompilatoren din data fra ett register rett etter det har blitt skrevet til, og det var det jeg pekte ut, denne koden er alldeles ikke effektiv. Og det du sier om rekkefølgen til mnemonics har absolutt ingenting å si da i maskinvaren snakker vi uops, ikke mnemonics.

 

Nest, påstår du at "lasting av data i registrene tar som regel 5 sykluser" - en totalt absurd påstand. Faktisk så variere det voldsomt fra prosessor til prosessor, og er avhengig av minne arkitektur og hvor i minne det fins. Selv om du holder deg til x86 verden, kan en instruksjon som leser data fra stacken tar alt fra 1 syklus (om det ligger i "store buffer" fra før) til over 200 sykluser (om det må hentes fra ekstern minne).

 

Som jeg sa, "som regel", det avhenger av hvor stort programmet er, om koden er i l1, l2, l3 eller i ram eller harddisk, men at DU tar utgangspunkt i at dataene måtte befinne seg i en av de sistnevnte i en kontekst hvor vi snakker optimalisering, det sier litt om hvor useriøs du er.

 

Og JA, disse typen instruksjoner tar som regel 5 sykluser, +-

 

I praksis kan man jobber ut fra noen cirka tall på pipeline forsinkelse fra en load (man tar som gitt at det er i nivå 1 cache) - noe som kompilatorene gjør. Og siden det variere etter hvilke type x86 cpu man har, pleier kompilatorene å gi brukeren opsjon til å optimalisere etter bestemte typer x86 - noe som assembly programmererer ikke gjør (med mindre enn at de vil skrive koden mange ganger).

 

Dette beviser jo hvor lite innsikt du har i seriøs assembler programmering, det er derfor man har macroer, det er derfor man har pseudo assembly, det er derfor man har betinget assembly.

 

Å skrive koden mange ganger er ikke noe som er eliminert i høynivåspråk, det er bare at det skjer automatisk, og selv denne automatikken finner ikke den beste løsningen, den finner en "grei" løsning som på ingen måte produserer noe som kan sammenlignes med hva en assembler programmerer kan sette sammen.

 

Du har rett at det ofte hjelper å laste inn data på forveien - og kompilatoren hadde gjort det dersom det var noen vits. Men det er lett å se at i dette tilfelle er det ingenting å vinne fordi hver steg er avhengig av den forrige. Det samme gjelder med de to instruksjonene som du mener burde byttes om for å unngå en pipeline stall - da tror jeg du har misforstått rekkefølgen av source og destination register.

 

Hvert steg kan være avhengig av den forrige, ja det kan den, men du glemmer enda et optimaliserings triks her som kompilatoren din åpenbart overså, du kan benytte flere execution units samtidig og dette kunne vært lastet langt i forveien.

 

Og til slutt påstår du å kunne ha doblet hastigheten - uten at du forstod assembly koden her, uten at du kjente til prosessoren, og uten at du forstod poenget (som var at du ikke kan skrive like raskt kode i assembly og fortsatt være fleksibel med tanke på konstantene).

 

Du kommer med en rekke løse påstander som det ikke finnes hold for.

 

Jeg liker ikke å klassifisere folk, men dette "jeg kunne doblet hastigheten" påstand er veldig typisk av programmerere som er veldig geiret på assembly og tror at det er alltid den raskeste og mest effektive språk.

 

Det fins ikke noe annet språk. c++ er ikke et dataspråk, det er ett pseudo-data språk, når du nå sier at "det er alltid den raskeste og mest effektive" så er det feil, det fins ikke ett språk som er raskt og effektivt, det fins bare en spesiell sammensatt kode som er rask og effektiv, og den får du bare om du har skrevet større programmer i asm, noe du ikke har gjort, du skriver bare "niche" kode, som du selv refererte til. Og da har du ingen lang erfaring som skal til for å skjønne hva potensialet er.

 

Men du blir <i>ikke</i> en bedre utvikler av å tro at assembly er en fornuftig valg av språk til noe mer enn enkelte niche oppgaver, og du blir ikke bedre av å tro at assembly er en god metode til å få raskeste mulig kode.

 

Du snakker mot bedre vitende her. SELVFØLGELIG får du raskere kode av å kode i assembler, men da er det helt relevant at du kan assembler godt og så er det helt relevant at du til enhver tid har instruksjonsmanualene og de nye instrusjonssettene tilgjengelig til enhver tid. En c++ programmerer behøver som regel ikke disse optimaliseringsmanualene, men jeg leser disse konstant.