Re: Compiler optimisation
Will DeWitt Jr.
> 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--
Alan Garny
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
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
> optimization.
>
Jeff
Liz
> 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
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
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
--
Ray Mond
Alan Garny
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
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
Ray Mond
Hallvard Vassbotn
> 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
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
> 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
> 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
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
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
/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
> good compiler.
For example, Bob Zale's PowerBASIC - an ex-Borlander.
http://www.powerbasic.com/aboutpb.asp
John McTaggart
John Jacobson
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
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
> 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
> 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
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
>> 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
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
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
> 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
become him, it's big fun - you will never regret.
--
Andrew Rybenkov.
Dave White
>
> "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.
> 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--
Will DeWitt Jr.
> > 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
> 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
> 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
> 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
Did I say it was good? :)
> --
> Andrew Rybenkov.
>
>
>
Andrew Rybenkov
LOL
--
Andrew Rybenkov.
Captain Jake
<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
> 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
<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
> 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
> 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
> 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
<dejanDot...@altium.comDOTau> wrote:
>Keep in mind that Delphi is one-pass compiler (apparently).
Yes, and no. Take a look at Danny's post:
--
Anders Isaksson, Sweden
BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm
Per Larsen
"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
>>Keep in mind that Delphi is one-pass compiler (apparently).
>
> Yes, and no. Take a look at Danny's post:
>
> http://groups.google.com/groups?q=delphi+compiler+pass+danny+thorpe&hl=sv&lr=&selm=3f2dd72a%241%40newsgroups.borland.com&rnum=1
>
Fair enough, I take it back. Thanks for the link.
Paul Dolen
>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
> 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
"Paul Dolen" <nos...@nowhere.com> wrote in message
news:1c82v01b52nialqet...@4ax.com...
No, just hasn't been around.
Danny Thorpe
> 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
>
> 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
> 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.
> >
> > 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 wish you people would quit invoking my name. Popping in here with a
big puff of smoke and a few lightning bolts is fun and all, but it
takes days to get the smell of sulfur out of my hair.
-Danny
John Wester [Group W]
dth...@bozofilter.borland.com says...
> <snip>
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
That, and chiseling stuff on tablets of stone takes a heck of long time
:)
--
John
Life is complex. It has real and imaginary parts
Jason Southwell
> 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.
One day it might be the only alternative.
Per Larsen
"Danny Thorpe" <dth...@bozofilter.borland.com> wrote in message
news:41f15fb9$1...@newsgroups.borland.com...
> > -Interprocedureal constant propagation
> Unclear. A constant is constant everywhere, no?
I think he may be referring to propagating constant procedure argument into
the routine.
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
hehe
- Per
Allen Bauer
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
That's not sulphur.. and it's not in your hair. Check your shoes. It's
hard to walk through here without tracking something back into the house :-/
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
http://blogs.borland.com/abauer
Wayne Niddery [TeamB]
>
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
LOL. Fortunately I had just set my coffee down before reading this.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
It used to be that other people's achievements were considered an
inspiration, not a grievance.
Dejan Stankovic
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
>
Well this really sets the record straight. It was worth being wrong just
for that reason.
> -Danny
>
Thanks,
Dejan
Captain Jake
> > 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.
Feelings had nothing to do with it. In JCEC, contestants wrote code for
Delphi 5 ( or 6, I don't remember which) and VC++ 6. Both sets of code were
compiled with optimizations on and the resulting code run several times and
the times averaged out, to improve the quality of the estimate. Google for
Jake's Code Efficiency Challenge. There was nothing subjective about this at
all. <y personal feelings and experience had absolutely nothing to do with it.
Captain Jake
> I wish you people would quit invoking my name. Popping in here with a
> big puff of smoke and a few lightning bolts is fun and all, but it
> takes days to get the smell of sulfur out of my hair.
But, trust me, it has great benefits for us.
Lord Crc
<dth...@bozofilter.borland.com> wrote:
>Popping in here with a
>big puff of smoke and a few lightning bolts is fun and all, but it
>takes days to get the smell of sulfur out of my hair.
Thanks for the highly informative post though.
- Asbjørn
dimitris
"Hallvard Vassbotn" <hallvard...@nospam-c2i.net> wrote in message
news:41ef...@newsgroups.borland.com...
> "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.
What about some compiler option for not assuming all the hard stuff, and
just do the best possible optimization for those parts of our code where it
is important? I believe that most of us have our algorithms developed in
separate units.
I would pay up to 1000 euros for a really good optimization option.
Atmapuri
VC++6 is also a "little" out of date. It is Intels Fortan
and C++ compiler that can beat Delphi 5-10x (not %)
in floating point and integer math that uses arrays.
(Because of SSE and MMX and a lot of other
array processing related optimizations).
The only are where Delphi is still "in class"
is string processing and object field access <g>
Write me any loop that works on arrays float
or integer an I can show you the code and performance.
If you can find an Asm code that can do better
in 3 days from what Intel does in seconds.
I would be impressed.
Regards!
Atmapuri
"Captain Jake" <jake[nospam]@jsnewsreader.com> wrote in message
news:41f26de8$1...@newsgroups.borland.com...
Danny Thorpe
>
> "Danny Thorpe" <dth...@bozofilter.borland.com> wrote in message
> news:41f15fb9$1...@newsgroups.borland.com...
>
> > > -Interprocedureal constant propagation
> > Unclear. A constant is constant everywhere, no?
>
> I think he may be referring to propagating constant procedure
> argument into the routine.
>
That's not particularly useful unless your compiler is rewriting the
code for the routine to suit every call site. That's trading a lot of
memory for a little speed.
Danny Thorpe
>
> The compiler itself is still "optimized" for the older processors,
> (either 386 or 486, I can't remember which) .
Neither. The Delphi codegen is tuned for the Pentium U/V pipelines.
Danny Thorpe
>
> What about some compiler option for not assuming all the hard stuff,
Which portion of compiler optimization isn't "the hard stuff"?
If you have any special insight into what semantic rules can be
discarded at leisure, I'm all ears.
> and just do the best possible optimization for those parts of our
> code where it is important?
Define "important."
Usually, "important" is determined by profiling. Do you know where
your code spends most of its time? If you don't, then you should
invest in a profiler to find out.
> I believe that most of us have our
> algorithms developed in separate units.
>
The fact that Delphi's units contain ready-to-link precompiled code
makes global optimizations and things like interprocedural register
allocations much harder. The fact that the code is in units means that
each may alter its implementation independently without breaking the
program as a whole. If you throw away precompiled units, then you're
back to glacial C++ must-see-all-source compilation times.
>
> I would pay up to 1000 euros for a really good optimization option.
My intolerance for bribes is a bit higher than that. ;>
Danny Thorpe
>
> 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)
Actually, I'm knee deep in niggly bug fixes in the compiler, RTL, and
VCL for the next D2005 update. Tagawa-san is, too.
So, there's been no forward progress on new compiler features.
Andrew Rybenkov
> makes global optimizations and things like interprocedural register
> allocations much harder. The fact that the code is in units means that
> each may alter its implementation independently without breaking the
> program as a whole. If you throw away precompiled units, then you're
> back to glacial C++ must-see-all-source compilation times.
How about to keep in "dcu"s intermediate code (triads, tetrades, whatever),
not optimized at all. Optimizations will be done by current compiler version.
Contra:
(probably) Drop in speed: slightly for not-optimized, noticable for hard optimizations.
Pro:
a) "dcu"s will be portable between different versions of compiler. Actually they will be portable
even between different OSs and CPUs (meaning non-Intel stuff).
b) per platform you would need just one "back-end" optimizing generator for Delphi, C++, and, e-hem, C#.
c) you can perform any optimizations that exist in the nature (depending on user "check-boxes", only)
?
--
Andrew Rybenkov.
Captain Jake
> Actually, I'm knee deep in niggly bug fixes in the compiler, RTL, and
> VCL for the next D2005 update. Tagawa-san is, too.
That's good news, actually.
--
Read Jake's Blog at http://blogs.slcdug.org/jjacobson/
Or Get the RSS Feed at http://blogs.slcdug.org/jjacobson/Rss.aspx
Everything contained in this post that is not quoted from others, is merely
an opinion. It may be a well-informed opinion motivated by an uncanny grasp
of facts and amazingly well-formulated theories, but it remains opinion
nevertheless. I speak for nobody but myself, and even then I may get it
wrong from time to time.
Captain Jake
> If you throw away precompiled units, then you're
> back to glacial C++ must-see-all-source compilation times.
I wonder about that statement. If I do a Build-All (not a compile), isn't
Delphi destroying and then recreating all the DCU flies? I've always thought
that was what differentiated a build from a compile, like it is in C++. But
Build-Alls in Delphi are lightning fast compared to C++ builds.
Bruce McGee
> I wonder about that statement. If I do a Build-All (not a compile),
> isn't Delphi destroying and then recreating all the DCU flies? I've
> always thought that was what differentiated a build from a compile,
> like it is in C++. But Build-Alls in Delphi are lightning fast
> compared to C++ builds.
It rebuilds anything where you have the source in the path, but not
(for example) the DCUs that Delphi ships with.
I make a point of building my library code separately from projects and
only pointing at the DCUs. Aside from improving build times, it cuts
way down on the amount of stuff I have to look through when I do things
like static code analysis (PAL2).
--
Regards,
Bruce McGee
Glooscap Software
Bob Dawson
> "Danny Thorpe" wrote
> > Actually, I'm knee deep in niggly bug fixes in the compiler, RTL, and
> > VCL for the next D2005 update. Tagawa-san is, too.
>
> That's good news, actually.
Yes, it is. There is so much new in D2005 that a bit of
consolidation/stabilization time is well spent. I'm still looking forward to
class vars and class constructors in the win32 compiler--but it can wait
until what's in so far has settled.
bobD
Leonel
> > I would pay up to 1000 euros for a really good optimization option.
>
> My intolerance for bribes is a bit higher than that. ;>
So, is should it be chocolate? Lots and lots of it? <g>
--
Leonel
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> > I would pay up to 1000 euros for a really good optimization option.
>
> My intolerance for bribes is a bit higher than that. ;>
What if the 600 voters for a Win64 compiler all gave $1000 each? <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"So I rang up a local building firm, I said 'I want a skip outside
my house.' He said 'I'm not stopping you.'" -- Tommy Cooper
Rudy Velthuis [TeamB]
> > The fact that Delphi's units contain ready-to-link precompiled code
> > makes global optimizations and things like interprocedural register
> > allocations much harder. The fact that the code is in units means
> > that each may alter its implementation independently without
> > breaking the program as a whole. If you throw away precompiled
> > units, then you're back to glacial C++ must-see-all-source
> > compilation times.
>
> How about to keep in "dcu"s intermediate code (triads, tetrades,
> whatever), not optimized at all. Optimizations will be done by
> current compiler version.
Same problem: glacial must-see-all-source compilation times.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"God is real unless declared integer" -- david
Andrew Rybenkov
huh?
they are compiled, just native opcodes not generated.
--
Andrew Rybenkov.
Rudy Velthuis [TeamB]
> > Same problem: glacial must-see-all-source compilation times.
>
> huh?
> they are compiled, just native opcodes not generated.
Yes, but the must-see-all (instead of just the interface info) part is
the problem, not necessarily that it is in source or not.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"And God said, 'Let there be light' and there was light, but the
Electricity Board said He would have to wait until Thursday to be
connected." -- Spike Milligan.
Jason Southwell
I'm a voter and I'm in.
Rudy Velthuis [TeamB]
> > What if the 600 voters for a Win64 compiler all gave $1000 each? <g>
>
> I'm a voter and I'm in.
OK, now we can see how many of the votes are serious. <g>
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"If absolute power corrupts absolutely, where does that leave God?"
-- George Deacon.
John Kaster (Borland)
> So, is should it be chocolate? Lots and lots of it? <g>
LOL.
FTR, that was NOT a bribe, and it WAS a joke.
In a strange way, it worked though, because the humor of it brought
attention to an algorithms newsgroup that otherwise might never have
happened.
IOW, stay tuned ...
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
What's going on? http://calendar.borland.com
Leonel
> FTR, that was NOT a bribe, and it WAS a joke.
I'm still waiting for the photographic evidence to believe that. <g>
> In a strange way, it worked though, because the humor of it brought
> attention to an algorithms newsgroup that otherwise might never have
> happened.
>
> IOW, stay tuned ...
Good news seems to be coming, then.
--
Leonel
John Kaster (Borland)
> I'm still waiting for the photographic evidence to believe that. <g>
Timing is everything
> Good news seems to be coming, then.
That's why I haven't posted it yet ...
Jim Cooper
> In a strange way, it worked though, because the humor of it brought
> attention to an algorithms newsgroup that otherwise might never have
> happened.
Oooh, wouldn't it be nice if every vocal lobbying group here used that
tactic? :-) (Humour, I mean, not necessarily chocolate)
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper j...@falafelsoft.com
Falafel Software http://www.falafelsoft.com
_______________________________________________
John Kaster (Borland)
> Oooh, wouldn't it be nice if every vocal lobbying group here used
> that tactic? :-) (Humour, I mean, not necessarily chocolate)
Well, those sadly funny flash animations of problems with Delphi 2005
sure got the attention of the team when I forwarded them, and as the
poster followed-up, Borland has got cases for the issues he showed.
I've been trying to get Camtasia or something else to be a standard
part of our development process for demonstrating reproducible bugs,
and those flash files greatly helped in my campaign.
Paul Dolen
>VCL for the next D2005 update. Tagawa-san is, too.
So, this is the first time I've heard a Borlander confess a next D2005
is going to happen.
John Kaster (Borland)
> So, this is the first time I've heard a Borlander confess a next D2005
> is going to happen.
That's because everyone insists on reading the worst into this by
over-analyzing the text, rather than paying attention to the request:
http://blogs.borland.com/johnk/archive/2005/01/06/2336.aspx
dimitris
"Jason Southwell" <ja...@southwell.net> wrote in message
news:41fab580$1...@newsgroups.borland.com...
> > What if the 600 voters for a Win64 compiler all gave $1000 each? <g>
>
> I'm a voter and I'm in.
I am not a voter, but I am in too.
dimitris
"Danny Thorpe" <dth...@bozofilter.borland.com> wrote in message
news:41f9a72f$1...@newsgroups.borland.com...
>
> >
> > What about some compiler option for not assuming all the hard stuff,
>
> Which portion of compiler optimization isn't "the hard stuff"?
I mean this. Instead of writing all the compiler up,
>
> If you have any special insight into what semantic rules can be
> discarded at leisure, I'm all ears.
>
> > and just do the best possible optimization for those parts of our
> > code where it is important?
>
> Define "important."
Optimization is most important in those parts of code dealing with number
crunching, like engineering algoriths (FFT, matrix operations, graphics
etc). Usually, these parts of code have very premitive pascal syntax. In
some extreme way, someone could write a program that would read those parts
of code (marked with compiler directives) and write very optimized routines
in assembly replacing the original code.
Borland could implement this idea transparently.
Paul Dolen
>> is going to happen.
>
>That's because everyone insists on reading the worst into this by
>over-analyzing the text, rather than paying attention to the request:
>
>http://blogs.borland.com/johnk/archive/2005/01/06/2336.aspx
I hadn't looked at that page before. I was referring to some
comments, I'm pretty sure by you, that specifically said that it was
not yet determined if there was going to be a second update to D2005
or not.
John Kaster (Borland)
> I hadn't looked at that page before. I was referring to some
> comments, I'm pretty sure by you, that specifically said that it was
> not yet determined if there was going to be a second update to D2005
> or not.
I would be interested in you finding a quote from me saying we are not
doing a second update to Delphi 2005. Everything else is just pessimism
on the part of the reader.
Will DeWitt Jr.
> > I hadn't looked at that page before. I was referring to some
> > comments, I'm pretty sure by you, that specifically said that it was
> > not yet determined if there was going to be a second update to D2005
> > or not.
>
> I would be interested in you finding a quote from me saying we are not
> doing a second update to Delphi 2005. Everything else is just
> pessimism on the part of the reader.
He didn't say he thought you'd said there *wouldn't* be a second
update, only that he thought you'd said it was still being considered.
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
John Kaster (Borland)
> He didn't say he thought you'd said there wouldn't be a second
> update, only that he thought you'd said it was still being considered.
And it is still being considered. It will continue to be considered
until and if we release it. You have to think about what you're doing
while you're doing it, unless it's just your autonomic nervous system
running things. We're talking about more than basic breathing and
heartbeat here.
Will DeWitt Jr.
> And it is still being considered. It will continue to be considered
> until and if we release it. You have to think about what you're doing
> while you're doing it, unless it's just your autonomic nervous system
> running things. We're talking about more than basic breathing and
> heartbeat here.
I thought you just misunderstood what he thought you'd said because you
asked someone to find a quote of you saying there wouldn't be another
update (which isn't what he said you said).
I'm glad Borland is still investigating another update seriously
though. =)
John Kaster (Borland)
> I thought you just misunderstood what he thought you'd said because
> you asked someone to find a quote of you saying there wouldn't be
> another update (which isn't what he said you said).
LOL. Ok. Amazingly enough, I understood your explanation, and now
understand your purpose in the previous post ;)
> I'm glad Borland is still investigating another update seriously
> though. =)
I don't have time to waste, and I don't lie to our customers. I
wouldn't be asking people to post reports to QC if it was an exercise
in futility.
Thomas Miller
make your software virtually 99% bug free should be like
basic breathing and heartbeat. That is what is so
frustrating with the new Borland. Of course you guys have
blogs now, and I like that about the new Borland. ;-)
John Kaster (Borland) wrote:
> Will DeWitt Jr. wrote:
>
>
>>He didn't say he thought you'd said there wouldn't be a second
>>update, only that he thought you'd said it was still being considered.
>
>
> And it is still being considered. It will continue to be considered
> until and if we release it. You have to think about what you're doing
> while you're doing it, unless it's just your autonomic nervous system
> running things. We're talking about more than basic breathing and
> heartbeat here.
>
>
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus
Will DeWitt Jr.
> Actually, for a software company, releasing enough SPs to make your
> software virtually 99% bug free should be like basic breathing and
> heartbeat. That is what is so frustrating with the new Borland. Of
> course you guys have blogs now, and I like that about the new
> Borland. ;-)
I just wish they posted in them more. ;) Especially roadmap-ish type
things where we might get some idea of what's making it into the next
version and what's not.
John Kaster (Borland)
> Actually, for a software company, releasing enough SPs to make your
> software virtually 99% bug free should be like basic breathing and
> heartbeat.
Unfortunately, the real world differs from what "should be"
> That is what is so frustrating with the new Borland.
Ummm ... the old Borland was no different in terms of updates.
Lord Crc
<jo...@borland.com> wrote:
>And it is still being considered.
I guess that when people hear the word "consider", they assume nothing
is actually beeing done. That is how it's around me, in the dailylife
anyway. I consider doing something, until I'm doing it, at which point
I'm no longer considering it as I've made a decision. However I can
see that releasing an update and the process of communicating this is
not the same as me taking out the garbage or doing the laundry.
- Asbjørn
Thomas Miller
> Thomas Miller wrote:
>
>
>>Actually, for a software company, releasing enough SPs to make your
>>software virtually 99% bug free should be like basic breathing and
>>heartbeat.
>
>
> Unfortunately, the real world differs from what "should be"
>
>
>>That is what is so frustrating with the new Borland.
>
>
> Ummm ... the old Borland was no different in terms of updates.
>
>
We will have to just disagree on this one. D4 is a prime
example. The VCL is much tighter then the D7 VCL. I still
think the D7 IDE is the best ever (haven't tested D2005 yet).
Paul Dolen
<jo...@borland.com> wrote:
>And it is still being considered.
That's my point. You say it is "being considered" but Danny spoke of
it as a fact.
John Kaster (Borland)
> That's my point. You say it is "being considered" but Danny spoke of
> it as a fact.
it is a fact we are doing bug fixes on the code that shipped in Delphi
2005.
Captain Jake
<420813ba$1...@newsgroups.borland.com>
> it is a fact we are doing bug fixes on the code that shipped in Delphi
> 2005.
That is good news. I love D2005 and find it to be the best Delphi yet. But
another patch is definitely needed to make it everything it could be.
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.398
Lord Crc
<jo...@borland.com> wrote:
>it is a fact we are doing bug fixes on the code that shipped in Delphi
>2005.
You're just not sure if you're gonna release them, that's all ;)
Just kidding, but I presume that's how many will read the "we are
considering it" message.
- Asbjørn