Assembly: Lære assembly sier du ? Hvorfor ?

[LonelyMan]

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

[Drogin]

- Lage ditt eget OS

Store deler av et OS kan man lage i C - ja.

Men hvordan har du tenkt til å lage f.eks context-switchet uten assembly?

[LonelyMan]

Ps. Tro det eller ei, men assembly språket er faktisk av de enkleste å lære da det kun er et fåtall instruksjoner. Det som er komplekst er systemene man programmerer.

 

1. Det er ikke ett fåtall med instruksjoner, det er hundrevis, og beveger du deg mellom ulike systemer så akkumulerer det til tusenvis, men selv om du holder deg til en spesifik plattform så er det likevel hundrevis.

 

2. Assembler er ikke lett å lære seg fordi du vet om instruksjonene, det som er virkelig tungt, og da mener jeg VIRKELIG tungt med assembler, er å lære seg å bruke instruksjonene på en super måte, og denne biten er ALLDELES ikke enkelt. Langt ifra. For å dette til å gå ihop på en super måte så krever det utrolige kunnskaper.

 

3. Systemene er ikke komplekse, iallefall ikke windows systemet, men det er STORT og det er TIDKREVENDE, det er hva det er, men det er ikke komplekst, med unntak som jeg sa tidligere DX9, GDI+, COM o.l konsepter. Vanlige API funksjoner er rett frem.

[Sebbert]

Nå skriver man ikke akkurat én linje i minuttet, da men...

[LonelyMan]

Nå skriver man ikke akkurat én linje i minuttet, da men...

 

Ja ikke sant

 

Trådstarter snakker ikke sant her, men jeg skjønner veldig godt at c kodere har behov for å snakke voldelig mot assembler for det er hva som driver dem, det som holder rettferdiggjørelsen vedlike.

 

Faktumet er at (iallefall i mitt tilfelle) jeg merker at mine asm programmer er raskere enn tilsvarende c++ programmer allerede før jeg har optimalisert dem, det kan hende jeg har gjort meg opp noen gode rutiner og vaner gjennom årene, men dette er tilfelle. Jeg behøver ikke engang anstrenge meg for å lage ett program som er 2 ganger raskere enn ett tilsvarende c++ program. Jeg kan helt sikkert skylde på noen gode vaner som sagt.

Endret 8. desember 2011 av LonelyMan

[Matsemann]

Men hvem søren gidder skrive større ting i assembly? Den overheaden en får ved å programmere i høyere nivå spiller sjeldent noen rolle.

 

Ikke at jeg er enig med trådstarter, men en kommentar som "han snakker ikke sant, jeg gidder ikke komme med kilder og så slenger jeg litt piss i andre retningen" er bare dum.

[torbjørn marø]

Mitt spørsmål/sammenligning er: Hvordan bygger du et hus? Kjøper du deg hammer og spiker, eller leier du inn en snekker?

 

Det kommer an på, ikke sant - men det finnes klare fordeler ved å gå opp et abstraksjonsnivå og leie snekkeren.

[LonelyMan]

Men hvem søren gidder skrive større ting i assembly? Den overheaden en får ved å programmere i høyere nivå spiller sjeldent noen rolle.

 

Når en programmerer i høynivåspråk, så bygger en med klosser. Problemet med klossebygging er at overheaden vokser stadig høyere og høyere, denne klossebyggingen er blitt en standard i c++, mens i assembler så bruker vi klossebygging til et minimalt.

 

"Hvem søren gidder skrive større ting i assembly?" Vel dette er nok ett uttrykk som kommes fra folk som aldri har skrevet noe større i assembly.

 

Jeg kan gi deg et lite eksempel, jeg skrev en irc klient i assembler, tilsvarende irssi, bare at denne er for windows, terminal basert irc klient, og jeg skrev den 50% ferdig på 3 uker (effektiv koding i asm). Det som gjenstår nå er bare kjedsomhetsarbeid, rutinearbeid.

 

Og irc klienten min har ca 5 ganger større throughput enn irssi og jeg kan forøvrig nevne at winsock wrapperen er den raskeste i verden, ikke mulig å gjøre den raskere, man vil alltid mene at ting kan optimaliseres mer, men i mitt tilfelle så er det ikke mer å optimalisere, det fins nesten ikke overhead i wrapperen min, hastigheten kan sies å ligge fullstendig på microsoft sitt bibliotek, min egen kode går så fort unna at den nesten ikke kan tas med i målingen. En tilsvarende winsock wrapper skrevet i c++ er omtrentlig 30 ganger tregere enn den jeg har skrevet. Jeg skrev den helt fra scratch, irc protokollen fra scratch, terminalen fra scratch, winsock wrapperen fra scratch og stringrutiner har jeg spesialisert (bruker biblioteker minimalt), jeg valgte å spesialisere stringrutinene for å optimalisere den maksimalt.

 

Det du sier om at ting tar lang tid i asm, er nok ett uttrykk fra c programmerere som ikke vet helt hva de snakker om. Jeg kunne selvsagt gitt mange flere eksempler.

 

Endret 9. desember 2011 av LonelyMan

[LonelyMan]

Litt viktig å også forstå at c++ ikke er ett portabelt dataspråk i motsetning til hva som sies. C++ er ikke ett dataspråk, det er et simulert dataspråk, og nettopp derfor er det portabelt, fordi det ikke har noenting med datamaskiner å gjøre i utgangspunktet.

 

Assembler er ikke ett simulert dataspråk, alle mnemonics eksisterer bare for å enkelt kunne huske de represantive tall oppkodene, så assembler er ett rent dataspråk.

 

C++ er ett mellom-menneskelig språk hvor en kommuniserer med den som skrev kompilatoren og den som scripter dette mellom-menneskelige språket. Så det er lett å ta feil her, c++ er ikke ett portabelt datamaskinspråk.

[vebbiii]

Litt viktig å også forstå at c++ ikke er ett portabelt dataspråk i motsetning til hva som sies. C++ er ikke ett dataspråk, det er et simulert dataspråk, og nettopp derfor er det portabelt, fordi det ikke har noenting med datamaskiner å gjøre i utgangspunktet.

 

Assembler er ikke ett simulert dataspråk, alle mnemonics eksisterer bare for å enkelt kunne huske de represantive tall oppkodene, så assembler er ett rent dataspråk.

 

C++ er ett mellom-menneskelig språk hvor en kommuniserer med den som skrev kompilatoren og den som scripter dette mellom-menneskelige språket. Så det er lett å ta feil her, c++ er ikke ett portabelt datamaskinspråk.

 

Joda, men den desidert største fordelen med assembly er jo optimalisering av programmet. Uten at jeg har vært mye borti assembly, så vil jeg tro at en god c++ utvikler skriver kode ganske mye raskere enn en god assembly programmerer. Og med tanke på at vi får bedre og bedre hardware, tenker du ikke da på at assembly blir mindre aktuelt med tiden?

[LonelyMan]

Joda, men den desidert største fordelen med assembly er jo optimalisering av programmet. Uten at jeg har vært mye borti assembly, så vil jeg tro at en god c++ utvikler skriver kode ganske mye raskere enn en god assembly programmerer. Og med tanke på at vi får bedre og bedre hardware, tenker du ikke da på at assembly blir mindre aktuelt med tiden?

 

Uansett hvor kraftig hardware vi har, så vil software industrien utnytte dagens hardware til det maksimale, det kan du se på både program og spill industrien, uansett hvor mye bedre hardware vi får, så ligger spill og programmer på yttergrensen av hva maskinen klarer å takle. Og det er helt naturlig at, jo bedre hardware vi får, jo bedre programmer og spill ønsker bransjen å lage, det er jo dette som er konkurransen, hvem klarer å lage best.

 

Så hvis vi tar denne sannheten til oss, så vil vi se at, dersom X utviklermiljø klarer å lage ett program eller spill med Y hastighet, så vil alltid assembler kunne utvinne Y+1 potensiale, uansett hvor langt hardware industrien kommer. Og hvis vi også tar med at vi alltid ligger på yttergrensen, så vil alltid Y+1 være relevant.

 

Det er ikke slik at om 10 år at noen lager et superspill i c++, at man bare får LITT raskere spill ved å bruke assembler, nei det er her mange misforstår, optimaliserer du c++ koden til å kjøre 5 ganger raskere, så utnytter du den hardwaren til den tiden 5 ganger mer effektivt, og det vil alltid være helt relevant.

 

Det eneste som kan utfase assembler er RISC arktitektur, men selv ikke da blir vi kvitt assembler heller, microsoft skriver fortsatt deler av operativsystemet i assembler, alle språk må omgjøres til assembler og mange skriver biblioteker i assembler.

 

Jeg vil legge til at alt tyder på at vi ikke går i den retningen, vi får stadig flere instruksjonssett tilgjengelig, og det tyder på at kompilatorer vil få det vanskeligere og vanskeligere med å utnytte hardwaren til fulle. Ikke lettere med tiden. Dette forteller meg at assembler kommer til å fortsette å være en del av mindretallet av utviklere, og disse elitistene vil alltid lage de raskeste programmene, bare prøv ett hvilket som helst assembler program, du vil fort merke den ekstremt lette flyten og hvor lett det kjører.

Endret 9. desember 2011 av LonelyMan

[GeirGrusom]

Det er alltid mer å hente i å optimalisere algoritmen enn det er i å skrive ting i assembly. Det er for helt spesielle ting en kan bruke assembly (eksempelvis vektor og matrisematematikk) men for vanlig logikk er det svært lite å hente i å bruke assembly, bortsett fra frustrasjon.

Ved siden av det må du være klar over at du brukte tre uker på å skrive noe som hadde tatt deg en ettermiddag i C++, og som du deretter må skrive helt på nytt hvis du skal støtte andre prosessorer.

 

Kanskje du har hørt om MenuetOS? Skrevet 100% i AMD64 assembly.

 

Et operativsystem må alltid ha noe assembly, men en prøver å bruke det så lite som mulig grunnet at det er kode som er svært vanskelig å debugge, ekstremt lite vedlikeholdbar, og null prosent portabel.

[Sokkalf™]

Jeg kan gi deg et lite eksempel, jeg skrev en irc klient i assembler, tilsvarende irssi, bare at denne er for windows, terminal basert irc klient, og jeg skrev den 50% ferdig på 3 uker (effektiv koding i asm). Det som gjenstår nå er bare kjedsomhetsarbeid, rutinearbeid.

 

Og irc klienten min har ca 5 ganger større throughput enn irssi og jeg kan forøvrig nevne at winsock wrapperen er den raskeste i verden, ikke mulig å gjøre den raskere, man vil alltid mene at ting kan optimaliseres mer, men i mitt tilfelle så er det ikke mer å optimalisere, det fins nesten ikke overhead i wrapperen min, hastigheten kan sies å ligge fullstendig på microsoft sitt bibliotek, min egen kode går så fort unna at den nesten ikke kan tas med i målingen. En tilsvarende winsock wrapper skrevet i c++ er omtrentlig 30 ganger tregere enn den jeg har skrevet. Jeg skrev den helt fra scratch, irc protokollen fra scratch, terminalen fra scratch, winsock wrapperen fra scratch og stringrutiner har jeg spesialisert (bruker biblioteker minimalt), jeg valgte å spesialisere stringrutinene for å optimalisere den maksimalt.

 

Det du sier om at ting tar lang tid i asm, er nok ett uttrykk fra c programmerere som ikke vet helt hva de snakker om. Jeg kunne selvsagt gitt mange flere eksempler.

Greit nok at assembly har sine bruksområder, men en IRC-klient, virkelig?

5 ganger større throughput enn irssi, javel, irssi greier likevel å presse gjennom data fortere enn jeg greier å lese eller skrive, uten at det belaster verken CPU eller minne merkbart.

 

Jeg skrev en IRC-klient i Java på en ettermiddag, som førsteårsstudent. Den belaster heller ikke CPU eller minne merkbart. Den er selvfølgelig langt mindre effektiv en din, men på denne typen applikasjoner har det da virkelig minimalt å si?

 

Edit: må presisere at jeg syns det er kult å se folk som kan, og bruker assembly, og har respekt for det. Jeg bare har vanskelig med å se argumentene dine som argumenter for assembly.

Endret 9. desember 2011 av Sokkalf™

[torbjørn marø]

Men hvem søren gidder skrive større ting i assembly? Den overheaden en får ved å programmere i høyere nivå spiller sjeldent noen rolle.

Jeg kan gi deg et lite eksempel, jeg skrev en irc klient i assembler, tilsvarende irssi, bare at denne er for windows, terminal basert irc klient, og jeg skrev den 50% ferdig på 3 uker (effektiv koding i asm). Det som gjenstår nå er bare kjedsomhetsarbeid, rutinearbeid.

 

I et høyerenivåspråk kan jeg lage en tilsvarende konsollbasert IRC-klient på 2 til 4 timer effektiv koding. Det er bare 1% av tiden du sier du ville ha brukt (har gjort noen forutsetninger om hvor mye du koder hver uke da selvsagt).

 

Time To Market er uhyre viktig. Min løsning vil ikke være så optimal som din, men vil den være god nok? For de aller fleste vil den det! Som jeg sa tidligere, de fleste bør velge snekkeren, men noen trenger også en hammer.

 

... det kan du se på både program og spill industrien, uansett hvor mye bedre hardware vi får, så ligger spill og programmer på yttergrensen av hva maskinen klarer å takle. Og det er helt naturlig at, jo bedre hardware vi får, jo bedre programmer og spill ønsker bransjen å lage, det er jo dette som er konkurransen, hvem klarer å lage best.

 

Ser du på spillindustrien så ser du at svært få gjør noe som helst i Assembly. Brorparten av spillutvikling fordeler seg på to områder: (1) Utvikling av kjernefunksjonalitet i språk som C/C++, og (2) spill-logikk i høyerenivå skriptspråk som Lua/Python. I bunn ligger det gjerne noen utviklere som optimaliserer deler av kjernen i Assembly - men det er tidskrevende, og derfor minimaliserer man dette arbeidet. Man bruker ofte skriptspråkene på toppen fordi det er det som går raskest å utvikle.., og ofte kjører det også raskt nok.

 

I tillegg har man spesielle språk for grafisk prosessering som jeg ikke snakker om her.

 

Jeg forsøker å vise at det er viktig å tenke på den gyldne middelveien her. Diskusjonen preges nå av personer som står på hver sin side. Det føles i alle fall sånn.

[LonelyMan]

1% av tiden er noe tullball da. Det er ikke slik at du bruker 1% av tiden til en assembler programmerer. Dette er nesten verre enn hva trådstarter påstår. At du klarer en irc klient på 1-2 timer, det vil du ikke klare. Jeg skal gi deg 2 uker, og selv etter den tid har du nok ikke klart å få satt sammen noe betydelig. Slike påstander bygger på folk som nesten ikke vet noen ting om assembler programmering.

 

Implementer irc protokollen på 1-2 timer, så skal jeg erklære deg for supermann av dette århundret. :!:

Endret 9. desember 2011 av LonelyMan

[Matsemann]

Jeg skal gi deg 2 uker, og selv etter den tid har du nok ikke klart å få satt sammen noe betydelig. Slike påstander bygger på folk som nesten ikke vet noen ting om assembler programmering.

 

Implementer irc protokollen på 1-2 timer, så skal jeg erklære deg for supermann av dette århundret. :!:

Poenget hans var jo nettopp at det går raskere å skrive i høynivå. Da trenger man ikke implementere irc-protokollen en gang. Alle biblioteker ligger der, fritt tilgjengelig, klare til bruk.

 

Imponerende det du har gjort, men totalt bortkastet om man tenker tidsbruk.

[LonelyMan]

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.

Endret 9. desember 2011 av LonelyMan

[blackbrrd]

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.

[LonelyMan]

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.

Endret 9. desember 2011 av LonelyMan

[Thomas.]

så assembler er ett rent dataspråk.

 

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

Endret 9. desember 2011 av Thomas.