Springen naar inhoud

Code optimaliseren in assembler


  • Log in om te kunnen reageren

#1

Betonac

    Betonac


  • >25 berichten
  • 26 berichten
  • Gebruiker

Geplaatst op 27 oktober 2007 - 21:24

Hey,

Is er hier iemand die goed in assembler kan programmeren ?
Ik zou willen leren optimaliseren van code.

Dank.

Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 27 oktober 2007 - 22:57

why? (Leer liever compilers te verbeteren...)

1. Don't.
2. Don't... yet.
3. Profile Before Optimizing

(Rules Of Optimization)


Premature optimization is the root of all evil

Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs

#3

Betonac

    Betonac


  • >25 berichten
  • 26 berichten
  • Gebruiker

Geplaatst op 28 oktober 2007 - 03:59

Eigenlijk heb je wel gelijk hoor. :D
Waar kun je dat leren, betere compilers schrijven ?

#4

EvilBro

    EvilBro


  • >5k berichten
  • 6703 berichten
  • VIP

Geplaatst op 28 oktober 2007 - 09:27

Ik zou willen leren optimaliseren van code.

Naast hetgeen al gezegd is: "Optimaliseer alleen daar waar dat blijkt nodig te zijn." en "de beste optimalisatie is een beter algoritme."

#5

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 28 oktober 2007 - 10:22

Mijn ervaring is dat als een programma onderdeel traag is (en dat ontdek je alleen als je het gaat onderzoeken) dit vrijwel altijd komt door een onhandig gekozen algoritme.

Tevens kon je vroeger nog wel eens een beetje snelheidswinst halen door in asm te programmeren, tegenwoordig valt dat behoorlijk tegen. De huidige cpu's hebben multiple cores, pipelining, branch-prediction.. er zijn maar heel weinig mensen die het beter kunnen doen dan een compiler.


Gentle, yet insistent executive summary: If you don't know how compilers work, then you don't know how computers work. If you're not 100% sure whether you know how compilers work, then you don't know how they work.

READ: rich programmer food

Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs

#6

Betonac

    Betonac


  • >25 berichten
  • 26 berichten
  • Gebruiker

Geplaatst op 28 oktober 2007 - 11:52

Ik heb niet alles gelezen van die blog, maar ik kan het maar beter vergeten denk ik.

#7

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 29 oktober 2007 - 08:49

Er is een Compiler Construction Wiki book.

Maar je moet eerst wel een beetje kennis hebben van automata theory en aanverwante onderwerpen.

Persoonlijk zou ik zeggen dat je het beter kunt beginnen met SICP
Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs

#8

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 29 oktober 2007 - 12:26

En voor cutting edge ontwikkelingen kun je wellicht kijken naar LLVM.
Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs

#9

Rogier

    Rogier


  • >5k berichten
  • 5679 berichten
  • VIP

Geplaatst op 29 oktober 2007 - 13:23

Heb je wel eens gezien wat voor asm een c++ compiler als die van VS2005 produceert? Daar is met de hand nauwelijks tegenop te optimizen hoor...

Vroeger heb ik menig routine versneld door inline assembler te gebruiken, maar tegenwoordig nooit meer. Behalve dat er ondanks ontzettend veel moeite waarschijnlijk nauwelijks iets te winnen valt, kleven er allerlei nadelen aan: asm code is veel lastiger te onderhouden, onbegrijpelijk voor anderen, een ramp om te debuggen, zo platform afhankelijk als maar kan, en één foutje en je code blijkt juist tientallen procenten trager dan wat die compiler ervan maakt.

Bedenk trouwens ook dat in de meeste programma's 99% van de CPU tijd wordt gespendeerd in 1% van de code.
In theory, there's no difference between theory and practice. In practice, there is.

#10

Schwartz

    Schwartz


  • >250 berichten
  • 691 berichten
  • Verbannen

Geplaatst op 11 december 2007 - 17:53

Je kunt soms veel/wat snelheid winst behalen door niet gebruik te maken van interne modulen...
zelf schrijven van de module scheelt soms stukken omdat modulen soms gemaakt zijn voor te veel doeleinden.
Ook het geheugenbeheer van de interne modue is soms regelrecht pet.

Bijvoorbeeld:
het inlezen van een file gaat in delphi met blockread gewoon al 2 keer sneller.

Ik schrijf zelf een compiler en de compiler is meer bezig met het uitvoeren van niet compiler gerichte handelingen dan aan het compileren zelf.
Daarom heeft het geen zin om de compiler zelf in een andere taal dan C++ of pascal te schrijven.

Ik schrijf veel met tprocedure arrays zodat de compiler meteen weet wat voor routine hij moet uitvoeren voor de handeling.
Door mijn speciale commando-techniek waarbij A_B hetzelfde commando is als B_A heb ik een speciale techniek moeten ontwikkelen omdit snel af te handelen.

Ik probeer op veel vlakken efficient te schrijven maar heb ook wel eens routinen die niet efficient zijn.
Bij commandos die niet vaak voorkomen is dat geen enkel punt.
voorbeeld: Het opzoeken van AMSTERDAM ion een database moet zo zijn dat amsterdam voorrang bekomt tegen
Vierhuizen.

Een punt van aandacht is het feit hoe men data inleest voor de compiler..
Als de kop van de harddisk moet gaan bewegen is dat een slechte zaak.
Het is daarom zinvol om een file geheel in te lezen en deze dan pas te verwerken alsj men andere data van files nodig heeft.
De harddiskkop hoeft dan niet telkens heen en weer....
De processor werkt met 2 000 000 000 stapjes per seconde, de kop van de harddisk is 100 stapjes per seconde of zoiets.

Ik heb mijn compiler op kleine files geschreven en hij leest grofweg 500 files per seconde uit.
Het produkt omvat nu rond de 10.000 regels en de software omvat rond 253000 bytes.
En dat is geen klein programma....

Ik zeg maar van: de muis naar de compilertoets bewegen kost meer tijd dan het compileren.......
Een computertaal is voor mensen, niet voor de computer.

#11

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 11 december 2007 - 20:14

boek: Basics of Compiler Design free download.
Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs





0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures