Re: Compiler optimisation

121 views
Skip to first unread message

Will DeWitt Jr.

unread,
Jan 20, 2005, 4:02:52 AM1/20/05
to
Alan Garny wrote:

> A friend of mine compiled some Fortran code using the Intel compiler.
> I coded the exact same code in Delphi 7. We then ran the executables
> on the same machine and surprise, surprise, the Intel compiler won by
> a huge margin. For the particular type of code I am interested in
> (mathematical modelling), the Intel code was more than 7 times faster
> (!!!). Why is that? Well, the Intel compiler is up to date (uses
> SSE2 for instance), while the D7 ones is very backward!

I'd definitely like to see the x86 (and, if it ever materializes, the
AMD64) compiler updated with better optimization, but it doesn't sound
like it's in the cards.

I'd happily pay $2-5 extra for a copy of Delphi if they'd add better
optimization.

Will

--
Want native support in Delphi for AMD64/EM64T? Vote here--

http://qc.borland.com/wc/qcmain.aspx?d=7324

Alan Garny

unread,
Jan 20, 2005, 3:58:53 AM1/20/05
to
A friend of mine compiled some Fortran code using the Intel compiler. I
coded the exact same code in Delphi 7. We then ran the executables on the
same machine and surprise, surprise, the Intel compiler won by a huge
margin. For the particular type of code I am interested in (mathematical
modelling), the Intel code was more than 7 times faster (!!!). Why is that?
Well, the Intel compiler is up to date (uses SSE2 for instance), while the
D7 ones is *very* backward!

So, is there any chance of seeing an up to date Delphi compiler some day or
am I asking for too much here? I haven't tested with D2005, for I have
uninstalled it (don't worry, I don't intend to start yet another enraged
thread on D2005), but I do remember checking the kind of code it generated
and it was identical to that of D7.

Alan.


Jeff Butterworth

unread,
Jan 20, 2005, 4:10:52 AM1/20/05
to
> I'd happily pay $2-5 extra for a copy of Delphi if they'd add better
> optimization.
>
That's very generous of you<g>

Jeff


Liz

unread,
Jan 20, 2005, 4:25:02 AM1/20/05
to
Alan Garny wrote:

> A friend of mine compiled some Fortran code using the Intel compiler.
> I coded the exact same code in Delphi 7. We then ran the executables
> on the same machine and surprise, surprise, the Intel compiler won by
> a huge margin. For the particular type of code I am interested in
> (mathematical modelling), the Intel code was more than 7 times faster
> (!!!). Why is that? Well, the Intel compiler is up to date (uses

> SSE2 for instance), while the D7 ones is very backward!

Surely that depends a lot on the code? Fortran was always amazingly
fast with numbers, faster than anything else.

Alan Garny

unread,
Jan 20, 2005, 4:43:44 AM1/20/05
to
"Liz" <liz_want...@xcalibur.nospam.co.uk> wrote in message
news:41ef78ee$1...@newsgroups.borland.com...

It obviously depends on the code. There is no doubt about that. This said,
independent of the language, it's the compiler that makes the difference.
Intel's Fortran compiler is better than their C++ compiler and this for
historical reasons. Having said that their C++ comiler is way better than
Delphi's compiler.

As I said, Intel's comiler takes advantage of modern processors' technology,
while Delphi's comiler doesn't at all (for the code I have tested). That's
where the difference lies.

Alan.


Atmapuri

unread,
Jan 20, 2005, 5:07:16 AM1/20/05
to
Hi!

The same is true for Intel's C++ also. If you would like to
catch up you can always try MtxVec. 2.0. (www.dewresearch.com)
It will allow you to stay in Delphi, but it also delivers way more than
what Intel's compilers alone have to offer.

Regards!
Atmapuri

"Alan Garny" <som...@somewhere.cm> wrote in message
news:41ef...@newsgroups.borland.com...

Ray Mond

unread,
Jan 20, 2005, 5:11:28 AM1/20/05
to
Er, time to get a new keyboard where the 'p' key works?

--
Ray Mond


Alan Garny

unread,
Jan 20, 2005, 5:22:03 AM1/20/05
to
"Ray Mond" <nos...@nospam.com> wrote in message
news:41ef83d9$1...@newsgroups.borland.com...

> Er, time to get a new keyboard where the 'p' key works?

And besides that? Next time, you may as well spare all of us some time by
not replying.

Alan.


Alan Garny

unread,
Jan 20, 2005, 5:42:45 AM1/20/05
to
"Atmapuri" <janez.m...@usa.net> wrote in message
news:41ef82d8$1...@newsgroups.borland.com...

> The same is true for Intel's C++ also. If you would like to
> catch up you can always try MtxVec. 2.0. (www.dewresearch.com)
> It will allow you to stay in Delphi, but it also delivers way more than
> what Intel's compilers alone have to offer.

Thanks for the link. Surely interesting, but not what I am after. I don't
need a mathematical library, even if very performant. I have all my
numerical routines that work fine. I just wish they could be compiled in an
optimised way.

Alan.

PS: also, my project is open source, so that would exclude MtxVec or
anything of the like straight from the onset. Granted, I didn't mention that
in my original post.


Ray Mond

unread,
Jan 20, 2005, 5:42:20 AM1/20/05
to
Sure. I see that it's working now.

Ray Mond


Hallvard Vassbotn

unread,
Jan 20, 2005, 7:21:11 AM1/20/05
to
"Alan Garny" wrote:
> independent of the language, it's the compiler that makes the difference.

Yes and no. ;)

The compiler and the amount of optimizations it performs makes a heck of a
difference of course. But a compiler must follow a language spec, and that
spec often includes things about what the compiler can assume and cannot
assume. Such as aliasing of pointer values etc. Fortran was designed from
the outset to generate fast mathematical code. IIRC, both C/C++ and Pascal
have language semantics regarding aliasing that prevents certain numeric
aggressive optimizations. When that is said, modern template programming (á
la Boost) can use the template machinery and capable C++ compilers to
perform as good as (and sometimes better than) Fortran.

As always, use the right tool for the job.


Alan Garny

unread,
Jan 20, 2005, 7:45:46 AM1/20/05
to
"Hallvard Vassbotn" <hallvard...@nospam-c2i.net> wrote in message
news:41ef...@newsgroups.borland.com...

Obviously. The reason I went for Delphi, though, is that my application's
GUI is very important too, so Delphi sounded like the obvious choice to me.
This doesn't undermine the fact that Delphi's compiler could be improved.
Alternatively, I could use another compiler for the mathematical part of my
program, but I would rather avoid it if at all possible...

Alan.


Andrew Rybenkov

unread,
Jan 20, 2005, 7:41:38 AM1/20/05
to
> So, is there any chance of seeing an up to date Delphi compiler some day or
> am I asking for too much here?


Sure, NO, - you know yourself, Borland have not those huge Intel resources,
Borland have very tiny resources, and that resources Borland need to buy
consulting companies, because Borland cannot make money selling compilers.


--
Andrew Rybenkov.

Atmapuri

unread,
Jan 20, 2005, 7:50:31 AM1/20/05
to
Hi!

> Sure, NO, - you know yourself, Borland have not those huge Intel
resources,
> Borland have very tiny resources, and that resources Borland need to buy
> consulting companies, because Borland cannot make money selling compilers.

That is not true. There are many "small" shops that can make a very
good compiler. Didnt Borland spent 250MUSD on Together?

If it had spent 10% of that money on improving the Delphi compiler
over the last 3 years, it would probably stand within 10% against what Intel
and MS have today.

There is a big difference between:
- being in the same class, although maybe not the fastest
- being completely outclassed

Regards!
Atmapuri.


Eric Grange

unread,
Jan 20, 2005, 8:06:23 AM1/20/05
to
> That is not true. [...]

I guess that's what Andrew meant ;)

> Didnt Borland spent 250MUSD on Together? [...]

With fox hunt already banned, don't you try banning
memory leaks hunt in D2005!

Eric

Atmapuri

unread,
Jan 20, 2005, 8:22:22 AM1/20/05
to
Hi!

Oh.. man, .. when you shoot yourself in the foot...
I better put those guns away... <g>
Atmapuri

"Eric Grange" <egra...@SPAMglscene.org> wrote in message
news:41efac58$1...@newsgroups.borland.com...

Andrew Rybenkov

unread,
Jan 20, 2005, 9:18:20 AM1/20/05
to
> I guess that's what Andrew meant ;)

/whisper on
hey, man, don't disguise me. I am trying to infiltrate into their camp
/whisper off

[walking away, whistling loudly "I'm singing in the NET, I'm singing in the NET..."]


--
Andrew Rybenkov.

John McTaggart

unread,
Jan 20, 2005, 10:07:25 AM1/20/05
to
> That is not true. There are many "small" shops that can make a very
> good compiler.

For example, Bob Zale's PowerBASIC - an ex-Borlander.

http://www.powerbasic.com/aboutpb.asp

John McTaggart


John Jacobson

unread,
Jan 20, 2005, 11:37:19 AM1/20/05
to
"Alan Garny" <som...@somewhere.cm> wrote in message
news:41ef...@newsgroups.borland.com...

> So, is there any chance of seeing an up to date Delphi compiler some day
> or am I asking for too much here? I haven't tested with D2005, for I have
> uninstalled it

Well, if you don't test new versions of Delphi, you'll never know when the
compiler was updated, will you? Kind of silly to complain about the compiler
being out of date in it's optimizations when the one you are using is
already something like three years old and superceded by a new release that
had obvious changes to the compiler to accomodate things like inlining.


Alan Garny

unread,
Jan 20, 2005, 11:48:34 AM1/20/05
to
"John Jacobson" <jjacobso...@wi.rr.com> wrote in message
news:41efde3d$2...@newsgroups.borland.com...

Read me again. I haven't tested that particular piece of code that was
compiled with D7 and the Intel's Fortran compiler. However, I have checked
(when I still had D2005 installed on my system) other pieces of code
compiled by D2005 and they were identical to those compiled by D7. So, the
only thing I cannot tell you for sure is how fast/slow that particular piece
of code compiled with D2005 would be in comparison with D7. This said, from
what I have seen in D2005 I would assume it's pretty much the same. That's
all I am saying.

So, sorry, not entirely silly...

Alan.


Jason Southwell

unread,
Jan 20, 2005, 12:39:31 PM1/20/05
to
> I'd definitely like to see the x86 (and, if it ever materializes, the
> AMD64) compiler updated with better optimization, but it doesn't sound
> like it's in the cards.

You seem very knowledgable about what these optimizations need to be.
Perhaps you could put some time into helping the optimization of the
FreePascal x86 compiler?

David Smith

unread,
Jan 20, 2005, 12:42:42 PM1/20/05
to
Alan Garny wrote:
> modelling), the Intel code was more than 7 times faster (!!!). Why is that?
> Well, the Intel compiler is up to date (uses SSE2 for instance), while the
> D7 ones is *very* backward!

From D2005 feature matrix :

"Enhanced! 32-bit inline assembler with support for the full Intel® x86
instruction set (including Intel Pentium® Pro, Pentium III, Pentium 4,
Intel MMX,™ SIMD, Streaming SIMD Extensions, SSE, SSE2, and SSE3, and
AMD® 3DNow!®"


--
David S.
Delphi programming : http://www.borland.com/delphi/

Dave White

unread,
Jan 20, 2005, 1:08:06 PM1/20/05
to
"David Smith" <da...@nowhere.com> wrote in message
news:41efedd4$1...@newsgroups.borland.com...

> From D2005 feature matrix :
>
> "Enhanced! 32-bit inline assembler with support for the full Intel® x86
> instruction set (including Intel Pentium® Pro, Pentium III, Pentium 4,
> Intel MMX,™ SIMD, Streaming SIMD Extensions, SSE, SSE2, and SSE3, and
> AMD® 3DNow!®"
>

That's for inline assembly code, not the Pascal compiler. The compiler
itself is still "optimized" for the older processors, (either 386 or 486, I
can't remember which) . The floating point optimization is very poor, and
the memory alignment isn't optimized for todays processors.

Dave White


Alan Garny

unread,
Jan 20, 2005, 12:54:22 PM1/20/05
to
"David Smith" <da...@nowhere.com> wrote in message
news:41efedd4$1...@newsgroups.borland.com...
> Alan Garny wrote:
>> modelling), the Intel code was more than 7 times faster (!!!). Why is
>> that? Well, the Intel compiler is up to date (uses SSE2 for instance),
>> while the D7 ones is *very* backward!
>
> From D2005 feature matrix :
>
> "Enhanced! 32-bit inline assembler with support for the full Intel® x86
> instruction set (including Intel Pentium® Pro, Pentium III, Pentium 4,
> Intel MMX,™ SIMD, Streaming SIMD Extensions, SSE, SSE2, and SSE3, and AMD®
> 3DNow!®"

I am not quite sure how to understand this. My take is that one can indeed
write inline assembler code that takes advantage of the new technologies,
but that doesn't necessarily mean that the compiler takes full advantage of
them... As it happens, it didn't in my case, but I am ready to accept that I
might have overlooked something...

Alan.


Eric Grange

unread,
Jan 20, 2005, 1:06:15 PM1/20/05
to
> From D2005 feature matrix :

That's for BASM only, and it only saves you the hassle
of assembling the instructions when editing with the likes
of MMXasm. The compiler won't use any of these on his own.

Eric

David Smith

unread,
Jan 20, 2005, 3:52:10 PM1/20/05
to

Ok, I might have misunderstood, somehow I had the feeling that I read
something about compiler support of SSE in D2005. But now I only found
this piece :

http://blogs.developerfusion.com/thushan/archive/2004/11/27/469.aspx

"Generate P4 SSE3/SSE2 instructions (yayy! you can include OpCodes for
newer p4s)"

But if that doesn't mean compiler generated code, then I must be wrong.
As you have already guessed, I'm not a BASM guy.

John Jacobson

unread,
Jan 20, 2005, 4:12:49 PM1/20/05
to
"Alan Garny" <som...@somewhere.cm> wrote in message
news:41efe0e2$2...@newsgroups.borland.com...

> This said, from what I have seen in D2005 I would assume it's pretty much
> the same. That's all I am saying.
>
> So, sorry, not entirely silly...

Maybe. Invalidity is not necessarily silliness.


Andrew Rybenkov

unread,
Jan 20, 2005, 4:21:05 PM1/20/05
to
> As you have already guessed, I'm not a BASM guy.

become him, it's big fun - you will never regret.


--
Andrew Rybenkov.

Dave White

unread,
Jan 20, 2005, 5:40:50 PM1/20/05
to
"David Smith" <da...@nowhere.com> wrote in message
news:41f01a08$1...@newsgroups.borland.com...

>
> "Generate P4 SSE3/SSE2 instructions (yayy! you can include OpCodes for
> newer p4s)"
>
> But if that doesn't mean compiler generated code, then I must be wrong.
> As you have already guessed, I'm not a BASM guy.
>

Yep, that's just in the BASM section. In the past, you couldn't enter
opcodes for newer instruction - BASM simply did not understand them. To get
around this, you would look up the code in the Intel manual, then enter the
value using DB statements. The D2005 compiler now understands these
opcodes, so you don't need to mess with DBs. However, the compiler still
doesn't generate them.

Dave White


Will DeWitt Jr.

unread,
Jan 20, 2005, 6:21:27 PM1/20/05
to
Jason Southwell wrote:

> You seem very knowledgable about what these optimizations need to be.
> Perhaps you could put some time into helping the optimization of the
> FreePascal x86 compiler?

I'm not as good as some of the people in b.p.d.l.basm (see the FastCode
competitions in there). And besides, I'd like to see Delphi improve.
FreePascal might one day be great as an alternative to Delphi though.

Will

--
Want native support in Delphi for AMD64/EM64T? Vote here--

http://qc.borland.com/wc/qcmain.aspx?d=7324

Will DeWitt Jr.

unread,
Jan 20, 2005, 6:23:02 PM1/20/05
to
Jeff Butterworth wrote:

> > I'd happily pay $2-5 extra for a copy of Delphi if they'd add better
> > optimization.
> >
> That's very generous of you<g>

Indeed it is-- assuming they sell 100,000 copies of Delphi with each
new version, that's $200,000-500,000. More than enough to fund 2-3 new
employees to work on just compiler optimization and adding new switches
for the compiler to emit PPro/P2/P3/P4 optimized code.

I mean, what can I say: I'm a giving kind of guy.

Andrew Rybenkov

unread,
Jan 20, 2005, 10:03:27 PM1/20/05
to
> If I'm not mistaken Delphi doesn't have many optimizations. The only one
> I know it has is peephole.

I am pretty sure it has not, otherway there would not be such pieces like
push esi
pop edi

--
Andrew Rybenkov.

Dejan Stankovic

unread,
Jan 20, 2005, 10:00:03 PM1/20/05
to
Alan Garny wrote:
> A friend of mine compiled some Fortran code using the Intel compiler. I
> coded the exact same code in Delphi 7. We then ran the executables on the
> same machine and surprise, surprise, the Intel compiler won by a huge
> margin. For the particular type of code I am interested in (mathematical
> modelling), the Intel code was more than 7 times faster (!!!). Why is that?
> Well, the Intel compiler is up to date (uses SSE2 for instance), while the
> D7 ones is *very* backward!

If I'm not mistaken Delphi doesn't have many optimizations. The only one
I know it has is peephole. Intel's compilers, on the other hand, are
designed for high performance and have many different optimizations.

>Alan

Dejan

Dejan Stankovic

unread,
Jan 20, 2005, 10:25:28 PM1/20/05
to

Did I say it was good? :)

> --
> Andrew Rybenkov.
>
>
>

Andrew Rybenkov

unread,
Jan 20, 2005, 11:15:13 PM1/20/05
to
> Did I say it was good? :)

LOL


--
Andrew Rybenkov.

Captain Jake

unread,
Jan 20, 2005, 11:24:11 PM1/20/05
to
Dejan Stankovic <dejanDot...@altium.ComDotAu> wrote in message
<41f0...@newsgroups.borland.com>

> If I'm not mistaken Delphi doesn't have many optimizations.

You are quite mistaken. Optimized Delphi code runs at roughly 80-90% of the
speed of optimized VC++ code (except for heavy floating point code). It
wouldn't have that kind of speed if it had few optimizations, because I know
that the VC++ compile had quite a few optimizations.

The only one
> I know it has is peephole. Intel's compilers, on the other hand, are
> designed for high performance and have many different optimizations.

Intel's compilers are designed specifically for Intel chips, and like all C++
compilers/linkers lets you choose which optimizations apply. In Delphi you
don't get to choose which optimizations apply, you have to choose all or
nothing, but the optimizations are roughly the same as in a VC++ compile. By
the way, IIRC there was a big speed difference in VC++ code between the Intel
and AMD chips when you ran optimized code on them, with the AMD chips being
much much slower. That leads me to believe that the VC++ optimizer was
Intel-specific too, just like Intel's C++ compilers are.

It would be interesting to compare code speed for Intel C++ versus Delphi on
non-Intel chips, or on old Intel chips. Delphi produced code that was
optimized for Cyrix, Intel and AMD.

It is too bad Danny Thorpe is no longer posting here, as he would be able to
authoritatively set you straight on the issue of optimizations in Delphi
code.

--
***Free Your Mind***

Posted with JSNewsreader-BETA 0.9.4.369


JED

unread,
Jan 20, 2005, 11:43:12 PM1/20/05
to
Captain Jake wrote:

> It is too bad Danny Thorpe is no longer posting here, as he would be
> able to authoritatively set you straight on the issue of
> optimizations in Delphi code.

Hopefully he's coding a few more (optimizations) into the compiler
instead of being here :-)

Although he's probably knee deep in generics (pure speculation)


--
QC Client: http://www.alphalink.com.au/~jed/QC/
Blog: http://jedqc.blogspot.com/

Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm

Checkout my code central submissions for D2005
http://cc.borland.com/ccweb.exe/author?authorid=205627

Captain Jake

unread,
Jan 20, 2005, 11:49:35 PM1/20/05
to
JED <nos...@nospam.com> wrote in message
<xn0dxiu2...@newsgroups.borland.com>

> Hopefully he's coding a few more (optimizations) into the compiler
> instead of being here :-)

I wish my D2005 would come so I could check out the inline directive. I'd
love to see if it speeds up my already really zippy newsreader.

>
> Although he's probably knee deep in generics (pure speculation)

I hope he finds a way to do them that works at least as well as templates
worked in BC++. That would be sweet.

Dejan Stankovic

unread,
Jan 21, 2005, 2:30:00 AM1/21/05
to
Captain Jake wrote:
> Dejan Stankovic <dejanDot...@altium.ComDotAu> wrote in message
> <41f0...@newsgroups.borland.com>
>
>>If I'm not mistaken Delphi doesn't have many optimizations.
>
>
> You are quite mistaken. Optimized Delphi code runs at roughly 80-90% of the
> speed of optimized VC++ code (except for heavy floating point code). It
> wouldn't have that kind of speed if it had few optimizations, because I know
> that the VC++ compile had quite a few optimizations.

That is based on your experience and feeling and doesn't mean that was
result of optimizations.

Keep in mind that Delphi is one-pass compiler (apparently). This limits
number of possible optimizations to ones that do not operate on
intermediate code. Furthermore, there are three different levels of
intermediate languages upon which various optimizations are performed.

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

-Aggregation of global references
-Algebraic simplifications, including reassociations
-Basic-block and branch scheduling
-Branch optimizations and conditional moves
-Branch prediction
-Code hoisting
-Constant folding
-Control-flow optimizations
-Data prefetching
-Data-cache optimizations
-Dead-code elimination
-Global value numbering
-In-line expansion
-Induction-variable removal
-Induction-variable strength reduction
-Instruction prefetching
-Interprocedureal constant propagation
-Interprocedureal register allocation
-Intraprocedureal instruction cache optimization
-Leaf-routine optimization
-Linear-function test replacement
-Local and global common-subexpression elimination
-Local and global copy propagation
-Loop-invariant code motion
-Machine idioms
-Partial-redundancy elimination
-Procedure integration
-Procedure specialization and clonning
-Scalar replacement of aggregates
-Scalar replacement of array references
-Shrink wrapping
-Software pipelining, with loop unrolling, variable expansion, register
-renaming and hierarchical reduction
-Sparse conditional constant propagation
-Tail call optimization, including tail recursion elimination
-Tail merging
-Unnecessary bounds checking elimination

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

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.


> The only one
>
>>I know it has is peephole. Intel's compilers, on the other hand, are
>>designed for high performance and have many different optimizations.
>
>
> Intel's compilers are designed specifically for Intel chips, and like all C++
> compilers/linkers lets you choose which optimizations apply. In Delphi you
> don't get to choose which optimizations apply, you have to choose all or
> nothing, but the optimizations are roughly the same as in a VC++ compile. By
> the way, IIRC there was a big speed difference in VC++ code between the Intel
> and AMD chips when you ran optimized code on them, with the AMD chips being
> much much slower. That leads me to believe that the VC++ optimizer was
> Intel-specific too, just like Intel's C++ compilers are.

Most of the benefits come from pipeline optimizations. I read somewhere
that on MIPS you can get sevenfold increase in speed if you are careful
about pipeline.

As for AMD vs. Intel you might be right. If MS compiler does pipeline
optimization, this wouldn't work on AMD. I gues they go by the number of
usres that have Intel as opposed to AMD.

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.

> It would be interesting to compare code speed for Intel C++ versus Delphi on
> non-Intel chips, or on old Intel chips. Delphi produced code that was
> optimized for Cyrix, Intel and AMD.
>
> It is too bad Danny Thorpe is no longer posting here, as he would be able to
> authoritatively set you straight on the issue of optimizations in Delphi
> code.
>

I'd like to set this straight. Especially, I'd like to hear what
optimizations from the list above Delphi has.

Dejan

Per Larsen

unread,
Jan 21, 2005, 6:44:44 AM1/21/05
to

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

Quite a list. I'll admit that the optimizer in the Delphi compiler is not
exactly state of the art, but in all fairness, it does exist and it does
improve the quality of the code considerably. You should have seen the code
that TurboPascal 3 emitted. It was horrible. Unfortunately, the optimizer
doesn't appear to have received much work, if at all (other than possibly
necessary support for new language constructs), since Delphi 2.

I don't know the precise meaning of all the optimizations you list, but I do
know that Delphi does at least some of:

> -Algebraic simplifications
> -Branch optimization
> -Constant folding
> -In-line expansion (explicit, requires D2005)
> -Induction-variable removal
> -Local common-subexpression elimination
> -Machine idioms

In addition to those your list, it also does

- Redundant register store/load and load/reload elimination (not perfect but
way better than TP3)
- Unreachable code elimination (note that this is different from dead-code
elimination, which it doesn't do)

- Per


Dejan Stankovic

unread,
Jan 21, 2005, 7:11:29 AM1/21/05
to
Per Larsen wrote:
> Quite a list. I'll admit that the optimizer in the Delphi compiler is not
> exactly state of the art, but in all fairness, it does exist and it does
> improve the quality of the code considerably. You should have seen the code
> that TurboPascal 3 emitted. It was horrible. Unfortunately, the optimizer
> doesn't appear to have received much work, if at all (other than possibly
> necessary support for new language constructs), since Delphi 2.

I have seen code TP3 emitted, that's where I started. Oh happy days :)

> I don't know the precise meaning of all the optimizations you list, but I do
> know that Delphi does at least some of:
>
>
>>-Algebraic simplifications
>>-Branch optimization
>>-Constant folding
>>-In-line expansion (explicit, requires D2005)
>>-Induction-variable removal
>>-Local common-subexpression elimination
>>-Machine idioms

You do realise that all except Inlining and Machine idioms are
optimizations performed at the time of parsing and that pretty much
every compiler does them.

>
>
> In addition to those your list, it also does
>
> - Redundant register store/load and load/reload elimination (not perfect but
> way better than TP3)

This is job for peep-hole optimizer. It looks at generated code
(sometimes intermediate code) through a 2-3 instruction window and then
eliminates redundant cases. I didn't check Andrews statement (few posts
before this one), but if it is correct than it doesn't do very well here.

> - Unreachable code elimination (note that this is different from dead-code
> elimination, which it doesn't do)

Only partially. While:

If False Then Statement;

is correctly eliminated, this is not (D6):

Exit;//Or Break or Continue
Statement;

I would like to say that I do like Delphi and I don't mind too much it's
lackings, but we need to face reality. Delphi is a bit outdated compiler
(by Delphi here I mean Win32 compiler, not .NET).

> - Per
>
>

Best regards,
Dejan

Anders Isaksson

unread,
Jan 21, 2005, 8:06:54 AM1/21/05
to
On Fri, 21 Jan 2005 18:30:00 +1100, Dejan Stankovic
<dejanDot...@altium.comDOTau> wrote:

>Keep in mind that Delphi is one-pass compiler (apparently).

Yes, and no. Take a look at Danny's post:

http://tinyurl.com/6plmf

(same as:)
http://groups.google.com/groups?q=delphi+compiler+pass+danny+thorpe&hl=sv&lr=&selm=3f2dd72a%241%40newsgroups.borland.com&rnum=1


--
Anders Isaksson, Sweden
BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm

Per Larsen

unread,
Jan 21, 2005, 8:13:34 AM1/21/05
to

"Dejan Stankovic" <dejanDot...@altium.comDOTau> wrote in message
news:41f0f17f$1...@newsgroups.borland.com...

> You do realise that all except Inlining and Machine idioms are
> optimizations performed at the time of parsing and that pretty much
> every compiler does them.

I don't know whether Delphi does them precisely while parsing or later, but
yes these are obviously relatively basic optimizations.

> Delphi is a bit outdated compiler (by Delphi here I mean Win32 compiler,
not .NET).

Delphi is not a heavily optimizing compiler. I, like some others, would like
to see that change, but Borland's emphasis in the past has always been
compile speed over final code speed/size, and granted some of the analysis
required by the more advanced optimization algorithms does take significant
time to do - even on today's hardware.

However, saying that the compiler is outdated is missing the mark in this
context, IMHO. After all, the theory behind nearly all of the optimizations
listed has been known for 30+ years.

- Per


Dejan Stankovic

unread,
Jan 21, 2005, 10:29:54 AM1/21/05
to
Anders Isaksson wrote:
>>Keep in mind that Delphi is one-pass compiler (apparently).
>
> Yes, and no. Take a look at Danny's post:
>

Fair enough, I take it back. Thanks for the link.

Paul Dolen

unread,
Jan 21, 2005, 10:37:23 AM1/21/05
to
>It is too bad Danny Thorpe is no longer posting here, as he would be able to
>authoritatively set you straight on the issue of optimizations in Delphi
>code.

I hadn't seen Danny here in a bit, but what's this about "no longer
posting here"--like he's said "I'm outta here" or something like that?

Kostya

unread,
Jan 21, 2005, 10:49:26 AM1/21/05
to
> However, saying that the compiler is outdated is missing the mark in this
> context, IMHO. After all, the theory behind nearly all of the optimizations
> listed has been known for 30+ years.

Well if it stays let's say within 10-20% of what the other good
compilers do performance wise then it is fine. But they
should certainly take care of floating point that sucks.

Kostya

John Jacobson

unread,
Jan 21, 2005, 1:33:40 PM1/21/05
to

"Paul Dolen" <nos...@nowhere.com> wrote in message
news:1c82v01b52nialqet...@4ax.com...

No, just hasn't been around.


Danny Thorpe

unread,
Jan 21, 2005, 3:03:23 PM1/21/05
to
Paul Dolen wrote:

> I hadn't seen Danny here in a bit, but what's this about "no longer
> posting here"--like he's said "I'm outta here" or something like that?

No, more like "I have work to do."

--
Delphi Compiler Core: http://blogs.borland.com/dcc

Danny Thorpe

unread,
Jan 21, 2005, 3:02:01 PM1/21/05
to
Dejan Stankovic wrote:

>
> Keep in mind that Delphi is one-pass compiler (apparently).

Incorrect. The Delphi compiler is a one-pass, top-down parser with
incremental code generation.

> This
> limits number of possible optimizations to ones that do not operate
> on intermediate code.

True, but not applicable to Delphi. 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
>