Tips on comparing programming languages' performance

[Thaddy]

That was already possible: FPC has a lot of packages with translated headers to interface with libraries compiled in other languages. So, yes.

[PascalDragon]

Today (April 2020), a PC-class computer can have as many as 64 computing cores and 128GB (that's, 131,072 _megabytes_) of memory yet, compilers, with a few exceptions, are still being designed and written as if computers only had 32K of memory.

Isn't this because FPC has also to support small devices such as ARM and PIC or even very old computers?

ARM is not a small device. Just take modern ARM processors that are capable of running a full Windows. Also FPC doesn't run on small platforms, it just needs to compile code for them. Though it is true that we do support FPC on older platforms like DOS with 32-bit DOS extender or Amiga. But this doesn't necessarily prehibit optimizations. If they're used the compiler will simply take longer and might need more memory, so it's up to the user to decide. And more often than not this is worth it, because the compiled code will then run better on these pltaforms.

Sorry, I was thinking about Raspberry Pi and the like.
https://en.wikipedia.org/wiki/Raspberry_Pi

Tutorial: Install Lazarus to Raspberry Pi
https://forum.lazarus.freepascal.org/index.php/topic,46438.msg356831.html#msg356831

PicPas, Pascal compiler for Microchip PIC
https://forum.lazarus.freepascal.org/index.php/topic,36595.msg245121.html#msg245121

I was talking about the Pi as well. After all if it's powerful enough to run Lazarus it can't be considered small. Not to mention that I am running a full Windows 10 on a Pi as well. You were saying?

Language gimmicks can actually help, for example generics can help you massively decrease runtime overhead, by shifting things to the compile time. My favorite example for this is the heavy usage of function pointers for customizing objects/algorithms like the use of compare function pointers for Lists and Maps. Having code like this:

Code: Pascal  [Select][+][-]

1. if Assigned(FOnCompare) then
2.   cmp := OnCompare(a, b)
3. else
4.   cmp := StandardCompare(a, b);

Would simply be gone and all that is left at runtime would be:

Code: Pascal  [Select][+][-]

1. cmp := Comparator.Compare(a, b);

Which could potentially be inlined again. This would of course be even better if they would be a little bit more powerful (not necessarily turing complete like C++ templates), e.g. simply the ability to have 1. default values, 2. not only types but also constants and functions.

And especially syntactic sugar that doesn't have any runtime implications (like operator overloading, type helpers, etc.) are great recent (well recent in the eye of the beholder  ) additions to the language.

Apparantly you don't follow the mailing lists.

Though default values might be something that I could investigate...

Is already done in trunk for several platforms https://wiki.freepascal.org/LLVM

That's why I wrote what I wrote. I already ran some tests comparing freepascal and clang and go using wsl2 Debian64 as OS on Windows 10. When I have the same tests running on Raspbian I will publish my results.

does that mean we can link to obj of those languages too?

One can link against anything that generates valid COFF (for Windows), ELF (for *nix except macOS) or Mach-O (for macOS) objects. The problem with linking against C++ libraries is that their object layout and name mangling is different from FPCs and that is not something that's going to change with the backend nor is it something that even works with different C++ compilers (e.g. you can't use C++ code compiled with MSVC with C++ code compiled with GCC, even MinGW).

[Thaddy]

Sven, did you use this?: https://github.com/WOA-Project/WOA-Deployer-Rpi

[440bx]

I think it's the opposite of "bloat" in the C++ language. Scope-based memory management greatly reduces "bloat". Destructors are called automatically when an object goes out of scope. Combine this feature with the ability to declare / construct objects at the locations in the code where they're actually used, and you end up with very neatly encapsulated and readable code.

I can only mention my personal experience.  I use C++ (mostly MSVC but, I occasionally use g++ as well) as a better C compiler.  I don't use any OOP features.

Every program I've ported from C compiled with C++ has been substantially _smaller_ in Pascal than in C/C++.  In one case that comes to mind, the port was also substantially faster but, I cannot credit Pascal for that, the reason it was so much faster is because I coded custom formatted I/O routines.  That made a huge difference and, in spite of the additional code those custom routines took, the resulting program is a third (1/3) of the equivalent g++ program and a little bit over half (1/2) the size of the MSVC one and, in the case of MSVC the reason it's only half is because the MSVC version requires a run-time dll, IOW, it's not even a standalone program and, turning it into one simply wasn't worth all the work required.

I understand a lot of programmers use a compiler not just for the compiler but for all the "other things" that come with it (usually in the form of libraries, RTL or otherwise, RADs and who knows what else) but, I use a compiler as just a more convenient assembler and, that's all I usually want along with a good debugger (very important!).   For "proof of concept" type of code, I'll use library functions but, in the final product, it's extremely unlikely.


Not directly related to anything you said but, anyone claiming that "Pascal is slow" is claiming "A car is slow".  Obviously, it depends on the car just as in the case of Pascal (and any other language), it depends on the implementation.

[munair]

I understand a lot of programmers use a compiler not just for the compiler but for all the "other things" that come with it (usually in the form of libraries, RTL or otherwise, RADs and who knows what else) but, I use a compiler as just a more convenient assembler and, that's all I usually want along with a good debugger (very important!).   For "proof of concept" type of code, I'll use library functions but, in the final product, it's extremely unlikely.

I think that very much depends on a project's goal. In production environments compilers are never used for the compiler, but for the product. If that product requires a GUI then a RAD is the obvious solution. But I agree that RAD tools usually generate (much) bigger executables.

It is true that file sizes and computers' capacities have grown equally fast since the beginning of the computer era.

[440bx]

I think that very much depends on a project's goal.

Yes, that is true.  There are programs that require truly sophisticated algorithms and in those cases using a well tested library that implements them is the way to go.

In production environments compilers are never used for the compiler, but for the product. If that product requires a GUI then a RAD is the obvious solution.

I see that as a very "personal computer" oriented way of looking at software development.  Compilers, operating systems and many other "core" type programs are not developed with RADs.  A good compiler, a good debugger and a good editor are the real tools.  The code the compiler generates is crucial to having a final product that meets expectations.

But I agree that RAD tools usually generate (much) bigger executables.

It is true that file sizes and computers' capacities have grown equally fast since the beginning of the computer era.

The problem with big executables isn't the amount of disk space or memory they consume.  The real problem is the presence of a very substantial amount of code that, in a lot of cases, shouldn't be there but, since it's there, it can be a source of bugs and/or annoying problems that are hard to track down. 

Essentially, it is quite often the case that, the time initially saved is spent many times over attempting to adapt or work-around undesirable (or not suitable) behavior in that code.  Software is like a printed circuit board, the more chips there are on the board, the lower its reliability.  Same with software, the more code, the more likely that code will be the cause of a problem.

[Thaddy]

If the size of a binary differs between a RAD environment and the commandline, you are not able to set your release build environment in your RAD ide correctly. Both should render byte for byte the exact same result (as does mine).

In such cases it only helps to read documentation, yes, read the ff'ing manuals.

Lazarus has an option to create debug and release modes, but the release mode (alas not as default, like in Delphi) and that "release mode" needs further setup, atm, by specifying/tuning your compiler options.
I agree it is not straightforward, but it is documented and not very hard to do.

[440bx]

If the size of a binary differs between a RAD environment and the commandline, you are not able to set your release build environment in your RAD ide correctly.

Wake up !! No one has said anything about differences between RAD and command line. 

... yes, read the ff'ing manuals.

yes! and read the ff'ing posts.

Here is some additional text for you to practice on...  smell large amount of highly caffeinated coffee... start neural activity... read post... and... for now... just go get some more coffee.

[Thaddy]

Wake up !! No one has said anything about differences between RAD and command line. 

What's wrong with your eyesight? Look a couple of posts up....
https://forum.lazarus.freepascal.org/index.php/topic,49459.msg360366.html#msg360366

At least that's how I interpret that.

[PascalDragon]

Sven, did you use this?: https://github.com/WOA-Project/WOA-Deployer-Rpi

Ehm, no, cause the last I knew was that the driver support wasn't that great yet. That this project managed to procure some third party USB stack is good news and I think I'll give that a try.

My current approach is an ArchLinuxARM with enabled KVM and Windows 10 on ARM64 running in that. Results in near native performance and I don't have the hassle with hardware drivers...