-
As I remember, Delphi came with nice libraries for GUI development.
Their GUI library (VCL) was overblown, deficient, and buggy.
Maybe, I don't know. Never used it, but it was somewhat popular at the time. Then again isn't that true for almost all general-purpose GUI libraries out there?
All I know is that Delphi-based apps tended to be rather stable and nice-looking.But they had a crazy-fast Pascal compiler. It could compile big projects in less than a second, and it produced good quality code. I've never seen any other compiler which would come even close. They completely re-wrote the compiler ca. 2010, so there's nothing good left in Delphi
For those remotely interested, there is the open Lazarus environment which doesn't seem too shabby (based on freepascal).
-
But they had a crazy-fast Pascal compiler. It could compile big projects in less than a second, and it produced good quality code. I've never seen any other compiler which would come even close. They completely re-wrote the compiler ca. 2010, so there's nothing good left in Delphi
the trick is to not recompile intermediate objects that their source files unchanged. similar to other enterprise grade C/C++ IDE such as Ms Visual Studio. seems like a lost trick when young people thought its ok to brute force recompile all on modern faster CPU, or are they the professionals who think its not worth their time? because they are pro, and pro need to complete things fast? at the stake of users worst experience, so long the money got into their pocket. the worst case i've seen is Arduino IDE but well, its free who can complaint? Borland Delphi aimed to rival its contender Ms Visual Basic. i had a chance to try Borland Delphi and C++ but i had problem building DLL with them to interconnect with Delphi apps, and never got it figured out. this was the main reason i keep Ms VB (for GUI) and VC++ (for near assembly speed grade DLL), the second main reason is the pascal criptic syntax, compared to the lovely VB. -
The Turbo Pascal and likely the later Delphi compiler was really amazingly fast - or should we say modern C compilers and many other are amazingly slow. I remember an old Pascal version at the C64 that was nearly as fast - however that one cheated a little, they already saved the source coder with special codes for the main language elements.
C is often slow, because all the imported .h files and #defines, that are recompiled every time. Turbo pascal, Modula and similar hat the files precompiled, as more elements for using multiple files are part of the language definition and not just simple include a text file to the source and do lots of defines. In C, a lot is done by the pre-processing step, and the actual compiler sees a much different final C code than the source code. Even quite some part of the library code goes through the compiler every time, as the actual languish elements are rather limited - much comes from the std. libraries.
The common GCC also does quite some optimization - much of the takes time though only giving slightly fast code. They just spend the time they have from a modern PC. An old compiler on a new PC tends to run fast, as it was made for a PC that was ways slower. So slow optimizations could no be used. -
... the trick is to not recompile intermediate objects that their source files unchanged.
I actually re-compile everything every time, and it runs very fast. The biggest project I have is about 400k lines. Delphi compiles everything under a second. You just press a button and see your program running.
-
What?But they had a crazy-fast Pascal compiler. It could compile big projects in less than a second, and it produced good quality code. I've never seen any other compiler which would come even close. They completely re-wrote the compiler ca. 2010, so there's nothing good left in Delphi
the trick is to not recompile intermediate objects that their source files unchanged. similar to other enterprise grade C/C++ IDE such as Ms Visual Studio.
This is how make has worked for some forty-odd years, now, in the Unix world. (It compares the modification timestamps of the source and intermediate object files, to determine which ones need to be regenerated.)
What kind of shitty development tools are you guys used to?
-
Not even Arduino rebuilds unnecessarily.
-
if arduino ide which uses gcc/make that is optimized, tell me why it compiled only few hundreds of code lines in minutes? it slowness is like someone who eats cannabis. i believe this is vendor's implementation. anyway i never had issue with my VB/VC, they always compile in like 10 seconds or less on my larger code. its when i tried those free version, i feel like playing with toys.
-
if arduino ide which uses gcc/make
There are no static source files in the Arduino environment, though.
You see, Arduino IDE is inherently a code generator. The reason it is slow, is that its design is poor: you cannot determine which intermediate object files need to be recompiled, because the Arduino environment regenerates even the source files every single time! Its slowness has nothing to do with the tools it relies on.
If you want an automotive analog, it is like a grandma driving a Porche in reverse down the highway.
If you want to see how powerful Makefile-based building can be, look at how the Linux kernel is configured and built. It uses internal C programs to generate the Makefiles, and both gcc and make to keep track of dependencies (make dep). Because the Linux kernel is monolithic, reconfiguring does force a full recompile. However, you can then fully rely on make to compile/build/rebuild the entire kernel, even in parallel (make -jN). If you keep the same configuration, but make changes to some source files, you only need to re-run make to rebuild the kernel; and in most cases, even when your modifications span many files, the recompiles take subsecond times. If you look at the amount of C code involved, the speed at which it does this, is absolutely impressive.
The difference between Unix and Microsoft philosophies is that in Unix land, the tools just won't try to stop you from driving like a grandma in reverse; they only exist to do your bidding, not to tell you what to bid on and how and when. -
Its slowness has nothing to do with the tools it relies on.
this thing need highlighting so youngsters will not take other arguments to go against C. i know this fact very well, thats why i keep typing "IDE", not "compiler". C/C++ compiler by itself is an efficient piece of tool made by real man. its just how a programmers or automated tool (IDE) uses it. this is why i suspect this is tools/IDEs specific implementation. AVR Studio 4 that i use, uses similar gcc toolchain (i guess) as Arduino IDE, but compiles at blazing fast speed, well not very fast when intermediate files not existing yet or got deleted, but not that minutes slow time. Arduino IDE is like making the code 10-100X bigger (compared to AVR Studio same code) and compile all in each go, super bloated inefficient again... IDE tool implementation, not the C. C is number one, backbone for everything else after assembler.
-
I'd agree with the C part, it's pretty much that C++ or xC when I write programs. I've dabbled with python, java, C#, turbo pascal, visual basic and various ASM but I don't think I'm proficient with any of them.
The Arduino IDE does store intermediate files in a temporary folder on a per instance basis. When something doesn't need to be recompiled it won't be. Obviously some actions require a full clean and rebuild(changing target MCU for instance, or a new instance of the IDE even if it's the same project open in another instance) and it will do it. I haven't used it in some time but I don't remember it being all that slow. Took longer to reconnect to a Teensy and program than compile a program which had already been compiled even after altering sources.
So it is slow the first time, essentially building the entire code base for the target MCU, but after that it works as quickly as you'd expect. -
The Arduino IDE does store intermediate files in a temporary folder on a per instance basis. When something doesn't need to be recompiled it won't be...
it doesnt seem so... i did modify my 3d printer marlin fw, that inevitably coded in arduino IDE, changing a single value and recompile will require me to light my "stick" if i dont want to get mad, and wait outside for 5 minutes to relax. 10X changing value in an IDE instance, requires 10 sticks. an abomination.
So it is slow the first time, essentially building the entire code base for the target MCU, but after that it works as quickly as you'd expect. -
Turbo Vision! Turbo Pascal OOP! the v7 (for DOS) is still awesome!
-
If you keep the same configuration, but make changes to some source files, you only need to re-run make to rebuild the kernel; and in most cases, even when your modifications span many files, the recompiles take subsecond times.
Sure if you compile one file instead of compiling the whole thing, it's much much faster. However this doesn't mean GCC is fast. if you change something in an *.h file which is included everywhere, you still need to re-compile everything.
But this is not the point. The point is that the old Delphi compiler works 100+ times faster than GCC. -
The Arduino IDE does store intermediate files in a temporary folder on a per instance basis. When something doesn't need to be recompiled it won't be...
it doesnt seem so... i did modify my 3d printer marlin fw, that inevitably coded in arduino IDE, changing a single value and recompile will require me to light my "stick" if i dont want to get mad, and wait outside for 5 minutes to relax. 10X changing value in an IDE instance, requires 10 sticks. an abomination.
So it is slow the first time, essentially building the entire code base for the target MCU, but after that it works as quickly as you'd expect.
So this was a 2nd compile and it still took that long? Perhaps it was a dependency issue, or maybe even a bug(There are a lot of bugs and issues). There are SO MANY stupid things with the Arduino IDE but they made this change at some point to stop rebuilding everything every time and it was mostly appreciated. Even now when I do Arduino based stuff I use the Visual Micro plugin for Visual Studio. It's really beyond frustrating to use the Arduino IDE and possibly the worst way to quickly get through code to debug, make changes, or just figure out where everything is and how it's put together. -
The point is that the old Delphi compiler works 100+ times faster than GCC.
How do you compare the speed of compilers compiling completely different programming languages?
Isn't that like comparing apples and oranges? -
The point is that the old Delphi compiler works 100+ times faster than GCC.
How do you compare the speed of compilers compiling completely different programming languages?
Isn't that like comparing apples and oranges?
It is. But somehow you manage to pick one to eat. The way I did it back in CPM days was that I had Microsoft's compiler package. It had four languages. C, Fortran, Basic and Cobol. I was proficient in Fortran and Algol, ok in Basic and had no clue about Cobol. I had a modest program (something like one or two hundred lines) that I needed for a business project. With the two MS languages I could write in the debug, compile, execute and test cycle took over forty five minutes on the 2 Mhz Z80 machine, with nearly ten minutes being execution cycle. Turbo Pascal came out and the same cycle took about ten minutes. Execution was two and a half, and much of the other 7.5 minutes with my nose in the language description. With those kind of results comparing apples and oranges isn't hard.
The key is that you have to evaluate the tools relative to a task or project that you need to do. Different objectives may give different results. -
The key is that you have to evaluate the tools relative to a task or project that you need to do. Different objectives may give different results.
Ahem. Care to re-read the comment I commented to, then my comment, and your own? You are restating my own statement, in a comment attempting to rebutt me. Weird. Did you have a point of your own, or did you just want to express your dislike of me via disagreeing?
Yes, current versions of GCC use quite a lot of CPU time to compile to machine code, but I would not characterize it as slow.
The standard Unix toolchain (make + a compiler) is quite efficient, as it does not do unnecessary work;
and among similarly capable compilers and build systems, GNU make and gcc are surprisingly fast.
If you test say gcc 2.95, you'll find that it is much faster than current versions of gcc. This is not because gcc has become worse, but because it spends more time in constructing the best machine code from the same sources than it used to. If you look at the generated machine code, the newer versions do a much better job. (In particular, older versions of gcc were terribly poor at register use, and generated a lot of unnecessary moves between registers. On hardware architectures with few registers, like x86, this meant the old versions generated pretty inefficient machine code.)
gcc is not as good as Intel CC when compiling to x86 or AMD64, but then again, gcc can compile the same C code to many different hardware architectures. I personally want AMD64, AVR, and various flavours of ARM Cortex support.
The way I define slow is comparing the time taken to the amount of work done. The Arduino environment is slow, because it does a lot of unnecessary work; and what work it does, it does in inefficient ways.
If you consider a build system that only recompiles intermediate object files whose sources or configuration has changed "enterprise grade", when that approach has been standard in the unixy world for four decades, you must be bonkers. I consider any build system that does not do that a toy, or a hack. I haven't decided which one I think Arduino is, but I'm leaning towards a cheap hack.
-
while some language(s) may compile faster, and perform comparable to C/C++, but in the end, applications that run matters. coding it and running it to make useful works consume the most time in the lifetime. when it comes to language features and capabilities to ease programmers, i'm yet to find a language that can do all in one... pointers, operator overloading etc, type casting to my heart content etc, besides other powerful features (that may be available in another languages too, or may not) such as true OOP, inheritance polymorphism pure abstraction etc... it may not be politically or turingly correct, and it may not have built-in fancy stuffs such as memory boundary check, which it expects the programmers to do by themselves when required (which is its main intention in the first place as low level language as possible and machine independent platform) but who cares? i'm happy enough to have a tool and know that i can do something with it that i cant with another tool. if someone argue a steel hammer may blunt your nail blue if accidentally hit with it, hence use wooden hammer to be foolproof, heck let them use wooden hammer, i will stick with my steel hammer because i know i can hit something hard with it that i cant with wooden hammer. about the blue blunt nail risk, there is workaround for that... be careful and be thoughtful.
as to Delphi/Pascal, to me its just a little bit more powerfull than VB in term of GUI development and language features, but VB is more syntax human friendly, and more powerful other features (bell and whistle) such as custom user control creation, and incorparation with VC/C++ DLL at ease, Delphi + Borland C++ gui dev may be able to do as well, but i dont have a chance to know, they made it too difficult to know. so Ms VB + VC combo solved my problem for GUI easiness + speed performance. but that was a long time ago, VB may not be applicable today anymore, Ms stops supporting and making new version of it sad. but what i know is i'm still a C/C++ fanboy, and support for it never diminished. there is hope in term of Windows GUI, even better.. multi platform OS... Qt... thats where i'm heading, if i'm heading at all (i'm getting old, but not yet old
)...
ymmv.
-
The point is that the old Delphi compiler works 100+ times faster than GCC.
How do you compare the speed of compilers compiling completely different programming languages?
Isn't that like comparing apples and oranges?
You can write a program in C which does something. Then you can write the same in Pascal. It'll be roughly the same amount of code which probably can be easily converted from one to other (most likely even possible with automated C<->Pascal tool). Then you compile one and the other and compare the compilation time.
Of course some of the difference will be because Pascal is inherently faster to parse, but most of it would be attributed to the compiler. -
You can write a program in C which does something. Then you can write the same in Pascal. It'll be roughly the same amount of code which probably can be easily converted from one to other (most likely even possible with automated C<->Pascal tool). Then you compile one and the other and compare the compilation time.
I recommend you actually do that. Perhaps calculate a small Mandelbrot fractal. Then, measure the compilation and run times for both.
You'll be surprised at what the differences are. No, it won't be "pascal 1% of the time gcc takes", not even close. In fact, on non-Windows machines, gcc will typically be faster, and generate faster code.
(On x86 and AMD64, as I already mentioned, ICC will be faster than gcc, and generate faster machine code too.) -
But this is not the point. The point is that the old Delphi compiler works 100+ times faster than GCC.
I'd certainly admit that the Delphi compiler was fast. But not 100 times faster.
Comparing GCC (which is not anymore the 'gnu C compiler' but the 'Gnu Compiler Collection' ) to Delphi is comparing apples to oranges. The different language behind it is even the slightest difference between the two (Pascal can't do most of the optimizations C can, so it saves a lot of time with that).
Here, GCC is merely a victim of its versatility.
First, it follows the good old Unix tradition that working file based saves a lot of memory/allows to compile programs with much less main memory requirements. When Delphi just slurped in the whole source and compiled from memory, gcc reads it line by line and stores intermediate results into temporary files.
Then, Delphi supported only one single platform with one single architecture while GCC supports about any platform thinkable. It is usually the very first development tool available if anything new (processor/OS) emerges. GCC also suports many different languages, from Ada to Fortran. To make this possible, it's inner workings are strictly separated. One path analyzes the program for syntactical correctness, another translates it into a synthetical RTL while the next one knows about the specific processor and writes the output as assembly language source that the next pass translates into object files that finally get glued together with the linker.
Considering all that, I'd say that gcc is pretty fast for what it does. -
Yeah. Pascal (at least in its original definition) is very easy and fast to parse. And the really fast Pascal compilers of the time (such as Turbo Pascal) were not doing any kind of optimization. Maybe the later versions of Turbo Pascal were (does anyone know for sure?)
Delphi (/Object Pascal) was already more complicated to parse and compile, but not that much compared to C++ which is a monster.
So there is the language difference, and then the optimizations. To be fair, compare compile times of the same program without any optimization.
There is also a difference in the way modularity was handled. When "units" were introduced in Pascal, it was a more efficient way of dealing with modularity and dependencies, since the units interfaces were basically pre-compiled, so that was the equivalent of precompiled headers in C compilers way before they were introduced in C compilers, and even so, I think the interfacing was also much more efficient in itself than even precompiled C headers. So to be fair again here, just compare compile times of sources with minimal or no dependencies.
But yes, the grammar of the language and the modularity features made Pascal compilers potentially much faster than C ones in general.
As to pure efficiency of the compiler, not considering optimizations and complexity of the language's grammar, sure GCC is not the best out there. Whereas many older Pascal compilers had parsers that were completely hand-written and hand-optimized, GCC used to rely on tools like YACC which are powerful but do not yield the fastest parsers. Apparently, they rewrote the parsers in GCC at some point: https://gcc.gnu.org/wiki/New_C_Parser , I don't know what the current state of things is though, as it has evolved a lot since then. And not all Pascal compilers were fast. Borland ones were, but I think Microsoft Pascal was a dog...
-
You'll be surprised at what the differences are. No, it won't be "pascal 1% of the time gcc takes", not even close. In fact, on non-Windows machines, gcc will typically be faster, and generate faster code.
I'm not talking about Pascal, I'm talkng about Delphi compiler. I'm certainly not going to port 300k projects back and forth between C and Pascal to prove it. If you want ballpark, look at this (which I got in my almost 10 year old i5 with Win7):Code: [Select]Borland Delphi Version 14.0
Copyright (c) 1983,2002 Borland Software Corporation
329346 lines, 0.48 seconds, 1340788 bytes code, 2489045 bytes data.
Now, get your GCC compiler and compile a 300k project on your favorite PC. See how long it takes.
-
Best way to evaluate a programming language, ignoring Jetbrains and taking in reality...
1. Hit a job site.
2. Find the most expensive thing out there.
3. Learn it over a weekend.
4. Ponce a job in it by sounding like you know what you're talking about.
5. Leverage their mandatory certification scheme.
6. Fail to renew the contract.
7. Go to 4 (until the fad wears off)
8. Go to 1.
Problem solved or so I'm told
-
(...)
Now, get your GCC compiler and compile a 300k project on your favorite PC. See how long it takes.
Yep, good point. We can devise forever about the hows and whys GCC is or is not slower than a typical Pascal compiler, but that's moot when you have concrete examples of typical projects taking infinitely less time to build with one tool than with the other. That's the practical cases that matter for the user, not theory.
And I agree you can't get a typical 330kLOC C project to build in 0.48s with GCC even on a killer machine (not saying a supercomputer ), and even if you use precompiled headers and stuff and a low level of optimization, or even none.