Assembly: Hvordan begynne i Assembly?

[Drogin]

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.

ArrayTester.zip

[Gjest Slettet+9871234]

1. Kan deler av koden puttes i en subrutine?
   
2. Dersom svaret er ja, hvor mye unik kode gjenstår?
   

[LonelyMan]

Jeg alignet pre bufferen og gikk fra 2,23 GB til 2,28 GB per sekund (50 MB mer per sekund). En liten forbedring, men jeg holder på å utvikle en annen algoritme, jeg tror kanskje jeg kan skvise det litt lengre.

Endret 8. september 2012 av LonelyMan

[LonelyMan]

Skrevet om noen instruksjoner for smartere minne håndtering og gikk fra 2,28 GB per sekund til 3,38 GB per sekund (1,10 GB mer per sekund), 3,38 bytes per nanosekund.

 

Skal forsøke å forbedre den enda mer, der er noen instruksjoner til som jeg kanskje kan gjøre noe med.

Endret 8. september 2012 av LonelyMan

[LonelyMan]

Nei jeg trekker meg, den algoritmen fungerte bare 95%, en feil som gjør at jeg må endre mye for at det skal fungere. Du vant

[Gjest Slettet+9871234]

kgun, det er ikke uvanlig for en assembler programmerer å først kjøre en pseudo kode gjennom en kompilator med full optimalisering, deretter å plukke ut assembler koden og så optimalisere den for hånd. Det er faktisk veldig vanlig.

 

Nei jeg trekker meg, den algoritmen fungerte bare 95%, en feil som gjør at jeg må endre mye for at det skal fungere. Du vant

 

Kunne du ikke kopiere assembly koden fra hans output og forbedre den på minst ett punkt? Jfr. at det "svakeste beviset" man kan gi i mattematikken er ett kontra eksempel på det man tror (antar at) gjelder.

 

Eller var ikke problemstillingen generell og kompleks nok?

 

Jeg antar at dere kan lese denne

 

http://www.dinitside...astFractals.pdf

 

artiklen. Er budskapet tidsavhengig eller er den fortsatt aktuell?

Endret 9. september 2012 av Slettet+9871234

[GeirGrusom]

 

Kunne du ikke kopiere assembly koden fra hans output og forbedre den på minst ett punkt? Jfr. at det "svakeste beviset" man kan gi i mattematikken er ett kontra eksempel på det man tror (antar at) gjelder.

 

Et poeng her er at Assembly krever ganske mye innsats, mens det kan ta fem minutter å skrive et ekvivalent program i C++ som tar deg en halvtime til en time å skrive i Assembly. Mikrooptimaliseringer på assembly output er ikke verdt innsatsen. I C++ er det også veldig trivielt å implementere multi-prosessor-støtte, noe det ikke er i Assembly.

[Gjest Slettet+9871234]

Et poeng her er at Assembly krever ganske mye innsats, mens det kan ta fem minutter å skrive et ekvivalent program i C++ som tar deg en halvtime til en time å skrive i Assembly.

 

Slik har det vel alltid vært. Ikke desto mindre finner noen det åpenbart lønnsomt å drive med assembly.

 

We're not afraid to resort to assembler or touch the bare metal to get the job done. We are doers. We do what others only talk about.

Kilde: http://www.haxx.se/

 

Som nevnt andre steder. (Resten) av mitt liv er for kort til å programmere i assembler og antageligvis også i C++. Det forhindrer ikke at andre kan finne det nyttig, men da må man komme på et visst nivå. Det nivået tror jeg det er svært få som holder her i landet.

Leste du den artiklen jeg har skannet inn i et PDF dokument? Selve koden er kanskje uleselig, men budskapet - 100 ganger rasker i assembly enn i C - kommer vel klart nok frem?

 

Er dagens prosessorer så gode at faktoren på 100 er redusert til under 1?

 

Mikrooptimaliseringer på assembly output er ikke verdt innsatsen. I C++ er det også veldig trivielt å implementere multi-prosessor-støtte, noe det ikke er i Assembly.

 

Jeg kjenner ikke til hvordan et eventuelt ASM instruksjonssett er for multiprosessorer. Det gjør kanskje du eller andre?

 

Men en ting må man også være klar over. Dagens kompilatorer og disassamblere er bedre enn gårsdagens. Jeg gjentar

 

kgun, det er ikke uvanlig for en assembler programmerer å først kjøre en pseudo kode gjennom en kompilator med full optimalisering, deretter å plukke ut assembler koden og så optimalisere den for hånd. Det er faktisk veldig vanlig.

 

Dermed skulle en god assembly programmerer ha et bedre verktøy til rådighet til å kikke den automatisk genererte koden i kortene. Det er således ikke bare en ulempe at kompilatorene er blitt bedre.

 

Du nevner C++.

 

Stay out of memory if you can.

 

er en sentral ide i Assembly. Det overrasker meg mye om ikke dagens C++ kompilatorer bruker minnet altfor mye. Ved å studere den koden som kompilatoren produserer samtidig som man behersker assembly, kan der således være mange klokkesykler å tjene og flere deste mer kompleks og uforutsigbar gangen gjennom et program er.

 

Noen hevder at en god måte å lære seg assembly på er nettopp å studere den asm koden som kompilatoren produserer og forbedre den. Assembly håndbøker, bruker og referanse manualer fra Intel, AMD etc. antar jeg fremdeles er å få kjøpt. Det var de ihvertfall da jeg drev litt med dette.

 

Ett konkret eksempel på en slik mursteinsmanual fra Intel.

 

"Intel486 Micoprocessor Family Programmer's Reference Manual."

 

Det er her den seriøse student titter og kombinerer det med for eksempel innsikt fra studier og lærebøker samt asm utskrift fra C / C++ kompilatoren.

 

Personlig har jeg ingen ambisjoner om å synge i et orkester, dirigere det eller komponere musikken orkesteret spiller. Noen komponerer imidlertid den musikken.

 

Jeg har heller ingen ambisjoner om å bli en ekspert på assembly. Det forhindrer ikke at jeg håper jeg kan gi et bidrag til at andre blir det.

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

Endret 9. september 2012 av Slettet+9871234

[Drogin]

Nei jeg trekker meg, den algoritmen fungerte bare 95%, en feil som gjør at jeg må endre mye for at det skal fungere. Du vant

Hehe, Visual studios kompilator vant, ikke jeg.

Og noen må jo skrive kompilatorene også...

 

Og for all del, det finnes garantert noen situasjoner hvor du kan få bedre ytelse enn en kompilator...virker som du har god kontroll på assembly, langt bedre enn meg.

 

Men å skrive hele programmer i assembly ser jeg ikke noen vits i, når dagens kompilatorer er så gode som de er. Bedre å skrive programmet i C/C++ og heller eventuelt optimize kritiske deler av koden manuellt i assembler.

[Gjest Slettet+9871234]

Hehe, Visual studios kompilator vant, ikke jeg.

 

Man kan jo også produsere de vakreste fraktaler og fraktal musikk http://www.fractal-r.../anim/anim.html med ganske enkel matte uten at jeg ville lyttet til den musikken fremfor musikken skapt av de store klassiske mestre.

 

Og for all del, det finnes garantert noen situasjoner hvor du kan få bedre ytelse enn en kompilator...virker som du har god kontroll på assembly, langt bedre enn meg.

 

Men å skrive hele programmer i assembly ser jeg ikke noen vits i, når dagens kompilatorer er så gode som de er.

1. Et utsagn jeg tar med en stor klype salt.
   
2. Hvor gode er de egentlig?
   
3. Hvordan bruker de minnet i forhold til registrene?
   
4. Er der noen vitenskapelige tester?
   

Bedre å skrive programmet i C/C++ og heller eventuelt optimize kritiske deler av koden manuellt i assembler.

 

Ja som et minimum der hurtighet / effektivitet er essensielt.

Endret 9. september 2012 av Slettet+9871234

[etse]

Det er jo standardmåten å gjøre ting på. Man skriver en rask kode, med en kort og enkel implementasjom av algoritmen man vil bruke. Profilerer koden og oppdager hvor det blir brukt mye tid og optimaliserer disse delene for å få den mer effektiv.

[Gjest Slettet+9871234]

Can computers "learn" real games?

 

Whether or not the program in this chapter can be said to learn from experience does not seem to be a very interesting question, since its answer depends almost solely on how you choose to use words like "learn" and "experience". More interesting is the question of whether or not the ideas behind the program are generally applicable. Can the same ideas be utilized to "teach" a computer to play chess or to "learn" to perform other tasks?

 

Fortunately (some would say "alas") the idea are not applicable to any but the simplest tasks. The main reason for this is that the number of possible situations that could arise is overwhelmingly large for most interesting games. For example, the number of possible situations in the game of chess is larger than the number of elementary particles in the known universe. That means that it is impossible - and will always remain impossible, no matter what size of computers may be constructed in the future - to declare arrays that are large enough to hold bead values for every possible situation in a game of chess. It also means that the number of training games necessary to produce acceptable values in a bead array is far too large to be played in the lifetime of any human being. Even the period between two "Big Bangs" of the universe would be too short to produce a chess-player that plays measurably better than completely randomly by the method described in this chapter. There do exist programs that enable computers to play acceptable chess, but they are based on very different ideas, and cannot be said to have learned to play chess.

Kilde: Professor Bjørn Kirkerud (1989): "Object Oriented Programming With Simula". Addison Wesley Publishing Company ISBN 0 201 17574 6 chapter 10.10

 

Hvorfor slår mennesker sjakk "blautvare"?

 

Kan det skyldes at menneskets hjerne er overlegen når det gjelder å se og gjenkjenne mønstre? Noe lignende påstår jeg gjelder assembly til det motsatte er bevist.

Endret 9. september 2012 av Slettet+9871234

[GeirGrusom]

Hvis maskiner hadde slått oss i å se mønster tror jeg alle her hadde vært uten jobb.

[Gjest Slettet+9871234]

Hvis maskiner hadde slått oss i å se mønster tror jeg alle her hadde vært uten jobb.

 

Sikkert riktig.

 

Noe av mitt poeng er at vår høsting av naturressurser kan bli (er) vår achilleshel. Vi vender oss til et altfor høyt forbruksnivå basert på tømming av lagerressurser og høsting fra naturen. Vi trenger jo bare å ta fisk og olje opp av havet. Utdannelse betaler seg ikke lenger. Jeg opplevde selv at jo mer utdannelse jeg tok i Norges Bank, dess verre fikk jeg det. Det er ikke tull. I dag tjener man millioner om man lærer seg å behandle en ball. Nå kan vi ikke det heller. Islendingene (landsforviste vestlendinger) slår oss i fotball og håndball. Når får vi en landslagstrener som tør å spille med to spisser og elsker angrep fremfor forsvar?

 

Drillo er etter mitt syn historie, selv om han er professor: Hans defensive filosofi, kan gjennomsyre våre fotballferdigheter helt ned til guttenivå. Mitt syn på hans fotballfilosofi kan kokes ned til dette.

 

Spill så tett forsvar som mulig og håp på minst ett kontringsmål.

 

Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand.

Einstein.

 

Så er Drillo for lite oppfinnsom? Holder ikke hans kunnskap lenger? Den som er ferdig utlært er ikke utlært, men ferdig. Men hva sier dette om temaet i denne tråden? Det kan være en generell holdning i noen bransjer og idrettsgrener.

 

Så tilbake til temaet.

 

C++ Oppfunnet av danske.

C# Oppfunnet av danske.

Ruby On Rails Oppfunnet av danske.

PHP Oppfunnet av grønlender.

cURL oppfunnet av svensker som programmerer i Assembly.

Linux Oppfunnet av Finne.

 

Hva har vi her i landet gjort etter Simula?

 

Jeg var med som rådgiver for en som skulle gjøre avtaler med den danske http://www.saxobank.com/ Nå arbeider vedkommende i oppdrettsnæringen.

 

Jeg trodde jeg var kommet inn i et datahus og ikke i en bank. Hele første etasje var en dataavdeling. Misforstå ikke. Tradisjonell konservativ banking er viktig, men der finnes noen ting datamaskiner kan gjøre bedre enn mennesker. Jeg er overbevist om at der sitter noen gode assembly programmerere i mange av verdens finansinstitusjoner og finpusser på programmer laget i for eksempel C eller C++ som noen hevder er "neste generasjons assembler". Men det er jo mer villedende enn veiledende, da assembly er prosessoravhenging. Det første man må gjøre er:

1. Bestemme seg for hvilken plattform man vil beherske. Intel, AMD, Motorola, Sparc, iPhone etc.
   
2. Lære den plattformens instruksjonssett inngående, blant annet ved å studere output fra ulike kompilatorer.
   

Der er uendelig mange kombinasjoner på et sjakkbrett. Hvor mange ord er der med et alfabet på 29 bokstaver. Hvor mange muligheter er der med et assembly instruksjonssett på 100 instruksjoner? Å lære seg assembly er en ting. Å se mønstre er noe annet. Man har sett det i språk som C++ og andre høynivåspråk, ikke minst i ftp://ftp.daimi.au.d...ok/betabook.pdf

 

Mønstre er nok noe annet i assembly enn i slike høynivåspråk (noen mener C er lavt) men jeg er overbevist om at de finnes.

 

Min intuisjon sier at der er så mye overhead i C++ på grunn av portabilitet at minnet brukes altfor mye.

Endret 10. september 2012 av Slettet+9871234

[Drogin]

Min intuisjon sier at der er så mye overhead i C++ på grunn av portabilitet at minnet brukes altfor mye.

C++ er "portabel" ved at den kan kompileres for hvert system.

Det vil si at en kompilator står fritt til å lage så spesialisert kode den bare vil for sitt target system

[Gjest Slettet+9871234]

Nesten som betinget kompilering med andre ord, men det forhindrer ikke at jeg står ved påstanden.

[Drogin]

Som i at hvis du ber kompilatoren om å kompilere et C-program for en 64bits core i7, så bruker den alle registerne tilgjengelig, tilsvarende for et 32bits system.

 

Som oftest gjør kompilatoren en veldig god jobb i å velge hvilke variable den skal ha i registerne og hvilke den skal legge i minnet. Ta f.eks eksperimentet vårt ovenfor hvor kompilatoren var like rask som assembly-programmet.

Endret 10. september 2012 av Drogin

[Gjest Slettet+9871234]

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?

Endret 10. september 2012 av Slettet+9871234

[Drogin]

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.

 

 

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, så får man heller gå inn manuellt i de kritiske stedene hvor optimalisereren ikke gjør det godt, om det er nødvendig.

Endret 10. september 2012 av Drogin

[Gjest Slettet+9871234]

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?

Endret 10. september 2012 av Slettet+9871234