Přeskoč navigaci

Optimalizace Delphi kompilátoru

Při procházení různých konferencí jsem narazil na příspěvek od dřívějšího hlavního vývojáře kompilátoru Delphi Dannyho Thorpe.

V největší diskuzní skupině o Delphi (borland.public.delphi.non-technical) se někdo zeptal jaké vlastně optimalizace Delphi používá a dočkal se odpovědi od Dannyho Thorpe (Delphi Compiler Core blog), nyní už ex borlandera. Stav odpovídá roku 2005.

Nechám ho v originále protože neznám přesnou českou terminologii (tučné je DT). Některé jsem tipoval, některé mne celkem překvapují. Vytahuji ho na světlo jelikož mne zaujal a jelikož je tam beznadějně zahrabaný.

Delphi compiler optimisation

The Delphi compiler is a one-pass, top-down parser with incremental code generation. The Delphi compiler does use intermediate representations and multi-stage AST tree trimming optimizations.

For your reference, following is, as complete as I could make it, list of all optimizations that are used in todays compilers.

I've added notations for which of these the Delphi compiler implements.

-Aggregation of global references

No, if this is referring to global constant folding (strings, primarily)

-Algebraic simplifications, including reassociations

Yes, but to a limited degree. We don't replace division with multiply by reciprocal, for example, because of concerns about loss of precision at the edges.

-Basic-block and branch scheduling

No.

-Branch optimizations

Yes.

- and conditional moves

No.

-Branch prediction

Static.

-Code hoisting

No.

-Constant folding

Yes.

-Control-flow optimizations

Unclear.

-Data prefetching

No.

-Data-cache optimizations

No.

-Dead-code elimination

Yes.

-Global value numbering

No.

-In-line expansion

Yes.

-Induction-variable removal

Yes.

-Induction-variable strength reduction

Yes.

-Instruction prefetching

No.

-Interprocedureal constant propagation

Unclear. A constant is constant everywhere, no?

-Interprocedureal register allocation

No.

-Intraprocedureal instruction cache optimization

No.

-Leaf-routine optimization

No.

-Linear-function test replacement

Unclear.

-Local and global common-subexpression elimination

Yes.

-Local and global copy propagation

No.

-Loop-invariant code motion

Yes.

-Machine idioms

No.

-Partial-redundancy elimination

Yes. (for pointer derefs)

-Procedure integration

Unclear.

-Procedure specialization and clonning

No.

-Scalar replacement of aggregates -Scalar replacement of array references

If this refers to constant expression evaluation, yes.

-Shrink wrapping

??

-Software pipelining, with loop unrolling, variable expansion, register -renaming and hierarchical reduction

Codegen templates are hand-tuned to favor instruction scheduling for the U and V pipelines of the Pentium family of processors.

-Sparse conditional constant propagation

No.

-Tail call optimization, including tail recursion elimination

No.

-Tail merging

No.

-Unnecessary bounds checking elimination

Yes.

Keep in mind that even very good compilers implement only a small number of those and that not all of those are speed optimizations.

Correct. The tail recursion optimizations in your list, for example, are astronomically rare in the wild. Such optimizations typically only kick in if you write you recursive routines "just so" which means only the illuminati will benefit by it.

The mantra for Delphi optimizations is to make everyday code work better. We don't the luxury of chasing after miraculous optimizations that almost never work. I leave that to the grad students. ;>

Now going back to Delphi. It has always been a solid compiler with two important features: it generates good code to begin with and it is one-pass (lightning fast). If you ever wandered why C++ takes ages to compile as compared to Delphi, this is the answer.

A lot of that Delphi has to thank to the language itself.

True, except for the one-pass assertion. The codegen phase is multi-pass intermediate node tree traversals and pruning. We just do it many times faster than the more traditional compiler models that were originally concieved for batch processing of punched cards.

This brings me to another point. Delphi has never been designed to be high-end compiler. For the purpose that people use it, it is more than fast enough.

Correct. It could be said that Delphi is fast enough to lead some folks to believe it should be the best at every computational scenario.

Delphi's objective is to be the most productive software development tool for a very broad audience of developers. The compiler is one small part of that.

originální příspěvek na groups.google.com

Jaggni to|Linkuj

Komentáře k tomuto článku



Prosím o dodržovaní určitých pravidel (tj. žádné neslušné texty, reklamy a tak prostě podobně). Komentáře porušující tyto pravidla budou odstraněny.

Před vložením komentáře je nutno provést náhled, jedná se o ochranu proti spamu.

 

Vložení komentáře
  
 
 

 

© NetCode.cz, 2006-9 | Všechna práva vyhrazena
Provozováno na mém pikoCMS, vygenerováno: 24.11.2017 6:44:11

O mně

Informace o mé maličkosti a kontakt.

Lokální tagy

amd(1) amiga(1) apple(1) aspnet(2) audio(1) borland(5) C64(1) codegear(12) delphi(39) dotnet(9) dvd(1) electone(1) embarcadero(1) emulator(11) firebird(2) flash(1) freepascal(5) gamecube(3) gigabyte(2) google(3) hardware(48) holografie(1) homebrew(29) hry(12) ibm(14) iphone(7) jidlo(1) komponenty(1) konzole(15) latex(1) lenovo(17) migrace(1) modchip(3) moje(9) mplayer(3) mssql(1) multi-touch(3) native-api(1) navody(23) nintendo(53) Nintendo3DS(2) nintendo64(6) NintendoDS(15) onestation(2) opera(1) ot(1) palm(1) pascal(1) pdf(1) pic(2) pmd85(1) pocitace(1) print-server(2) programovani(21) programy(25) R400(1) recenze(6) retro(1) satelit(1) seamonkey(5) snes(3) svepomoci(1) technika(1) thinkpad(20) usb(1) video(3) vs(3) vykriky(12) web(7) webdesign(8) wii(83) wiimote(13) wiiware(1) wiki(2) windows(7) windows-mobile(1) wl500g(2) wtf(8) zivot(1) ZX-Spectrum(5)