Today I guess it is far more important the speed of compiled executables, not the compiler speed itself. And until we will be able to test the new compiler, the actual one is becoming pretty old regarding code generation. And C/C++ compilers speed is closing in, while generating more modern code.
@LDS: I'm pretty sure that your statement is correct for some class of application but I believe they are in a minority. Most apps don't care about is the compiled code is perfect or only average.
In my experience, 95% percend of stuff I write (or even more) is not time-critical at all. In all other cases, a correct approach to the problem gives me better speed improvement as any optimizing compiler would.
I compile often, so I really appreciate the speed of Delphi's compiler. Anyone who worked on large C++ code can appreciate this -- even if they used pimpl, etc.
But it would be nice if Delphi's (and C++ Builder's) built-in assembler can be compatible with Visual Studio. Sometimes, we need runtime speed and it would be nice if we can use existing assembler code intermixed with C++ or Delphi.
Does anyone know if the new assembler in upcoming RAD Studio 2011 is compatible with MASM or NASM? It would be nice if the built-in assembler had compatibility mode for MASM.
"174.684 lines per second. What’s your compile speed?" I just tested with BCC (the C++Builder compiler), and it compiles 11162548 lines in 27s, which is about 413428 lines/s if I'm not mistaken, and about 2-3x faster than DCC. I hope that doesn't impact your wold view :)
Seriously, the real problem with C++ code is the amount of code which has to be compiled for every single module (all the header files). Most languages with support for a real module system (Delphi, C#, Java - well, about everything else) don't have this problem.
A lot of those lines are empty, but only because the preprocessor (which represents the first stage of the compilation process) included header files, stripped comments, replaced macros etc. And generally, due to some "special" features of C++ (template metaprogramming, scoping rules such as ADL, ...), C++ compilers usually perform much worse than C compilers. (You should watch BCC compile plain C code. Don't have much of that myself though.)
BCC is probably the fastest C++ compiler; IME, VC is a bit slower, GCC is significantly slower, and massively optimizing compilers (such as ICC) are slower by at least one magnitude. Conversely, DCC isn't really that fast because it uses almost-linear lookup algorithms in many places where it shouldn't (read Barry's comment on http://blog.marcocantu.com/blog/hundred_thousand_lines_unit.html). Most "modern" compilers /should/ be able to perform better than that.
Oh, and did I mention I can easily parallelize the compilation of my C++ code and run four instances of BCC on my quad-core machine? Try that with Delphi :)
(FTR, above numbers were measured on a single core.)
"Most apps don't care about is the compiled code is perfect or only average." That's true because most Delphi users code user-driven applications, where often the slower part is the database backend. When you start to code a different kind of applications, the quality of the generated code starts to matter a lot. And remember you don't sell customers your compiler speed (although it may help you to be more productive), but the resulting executable. And watch at the speed of VC++ 2010, I've read reports it's pretty fast. "meaningful benchmarks that can be used across compilers?" that's a touchy area, because some algorithms may not be ported 1:1 due to language differences, it's pretty easy to compare C++ compilers, but comparing C++/Delphi/C# may become difficult.
@LDS: I meant benchmarks to compare performance between different Delphi versions compiling the same code. It would be a quantitative way to test the new compiler.
I'd love to see good benchmarks that could be used to compare Delphi and C#, but I agree that this would be tougher.
@gabr: yeah, parallel compilation sounds awesome, hopefully the new compiler already takes advantage of that to enhance the programmer experience (what is what it counts in this subject I think, to be as much productive as possible), specially for compiling your code in the IDE with the background compilation feature on, which slows down per-se the compilation time when working in the IDE. I didn't tried that in D2kX since I'm stuck in TD2k6, but noticed about it's importance when implementing background compilation in the MIDletPascal 3 IDE, for which I used your OTL (~1.04) btw ;).
I'm more interested in the speed of the "background" compilation in Delphi. It's been interesting dropping back into Delphi 7 recently and noticing how many habits I have that have developed around modern Delphi's need for little holidays every time the "background" compiler kicks in. At work we've all got the delay before that starts set as high as it will go and would like it to be even longer - explicit invokation sounds more reasonable by the day.
Today I guess it is far more important the speed of compiled executables, not the compiler speed itself. And until we will be able to test the new compiler, the actual one is becoming pretty old regarding code generation. And C/C++ compilers speed is closing in, while generating more modern code.
ReplyDelete@LDS: Do you know of some meaningful benchmarks that can be used across compilers?
ReplyDelete@LDS: I'm pretty sure that your statement is correct for some class of application but I believe they are in a minority. Most apps don't care about is the compiled code is perfect or only average.
ReplyDeleteIn my experience, 95% percend of stuff I write (or even more) is not time-critical at all. In all other cases, a correct approach to the problem gives me better speed improvement as any optimizing compiler would.
I compile often, so I really appreciate the speed of Delphi's compiler. Anyone who worked on large C++ code can appreciate this -- even if they used pimpl, etc.
ReplyDeleteBut it would be nice if Delphi's (and C++ Builder's) built-in assembler can be compatible with Visual Studio. Sometimes, we need runtime speed and it would be nice if we can use existing assembler code intermixed with C++ or Delphi.
Does anyone know if the new assembler in upcoming RAD Studio 2011 is compatible with MASM or NASM? It would be nice if the built-in assembler had compatibility mode for MASM.
"174.684 lines per second. What’s your compile speed?"
ReplyDeleteI just tested with BCC (the C++Builder compiler), and it compiles 11162548 lines in 27s, which is about 413428 lines/s if I'm not mistaken, and about 2-3x faster than DCC. I hope that doesn't impact your wold view :)
Seriously, the real problem with C++ code is the amount of code which has to be compiled for every single module (all the header files). Most languages with support for a real module system (Delphi, C#, Java - well, about everything else) don't have this problem.
@mb: Now that is very quick.
ReplyDeleteNow we would only have to find out how many of those lines are empty/begin/end/{/} ...
A lot of those lines are empty, but only because the preprocessor (which represents the first stage of the compilation process) included header files, stripped comments, replaced macros etc. And generally, due to some "special" features of C++ (template metaprogramming, scoping rules such as ADL, ...), C++ compilers usually perform much worse than C compilers. (You should watch BCC compile plain C code. Don't have much of that myself though.)
ReplyDeleteBCC is probably the fastest C++ compiler; IME, VC is a bit slower, GCC is significantly slower, and massively optimizing compilers (such as ICC) are slower by at least one magnitude. Conversely, DCC isn't really that fast because it uses almost-linear lookup algorithms in many places where it shouldn't (read Barry's comment on http://blog.marcocantu.com/blog/hundred_thousand_lines_unit.html). Most "modern" compilers /should/ be able to perform better than that.
Oh, and did I mention I can easily parallelize the compilation of my C++ code and run four instances of BCC on my quad-core machine? Try that with Delphi :)
(FTR, above numbers were measured on a single core.)
@mb: Ahh, parallel compilation ... I'd like to see that in Delphi ...
ReplyDelete"Most apps don't care about is the compiled code is perfect or only average." That's true because most Delphi users code user-driven applications, where often the slower part is the database backend. When you start to code a different kind of applications, the quality of the generated code starts to matter a lot. And remember you don't sell customers your compiler speed (although it may help you to be more productive), but the resulting executable.
ReplyDeleteAnd watch at the speed of VC++ 2010, I've read reports it's pretty fast.
"meaningful benchmarks that can be used across compilers?" that's a touchy area, because some algorithms may not be ported 1:1 due to language differences, it's pretty easy to compare C++ compilers, but comparing C++/Delphi/C# may become difficult.
@LDS: I meant benchmarks to compare performance between different Delphi versions compiling the same code. It would be a quantitative way to test the new compiler.
ReplyDeleteI'd love to see good benchmarks that could be used to compare Delphi and C#, but I agree that this would be tougher.
The amount of lines per second are not comparable, because the compilation speed heavily depends on the code and the compiler switches.
ReplyDelete@gabr: yeah, parallel compilation sounds awesome, hopefully the new compiler already takes advantage of that to enhance the programmer experience (what is what it counts in this subject I think, to be as much productive as possible), specially for compiling your code in the IDE with the background compilation feature on, which slows down per-se the compilation time when working in the IDE. I didn't tried that in D2kX since I'm stuck in TD2k6, but noticed about it's importance when implementing background compilation in the MIDletPascal 3 IDE, for which I used your OTL (~1.04) btw ;).
ReplyDeleteI'm more interested in the speed of the "background" compilation in Delphi. It's been interesting dropping back into Delphi 7 recently and noticing how many habits I have that have developed around modern Delphi's need for little holidays every time the "background" compiler kicks in. At work we've all got the delay before that starts set as high as it will go and would like it to be even longer - explicit invokation sounds more reasonable by the day.
ReplyDelete