How is compared for Lazarus from speed to C programming ? lazarus / 21-General ---------------------------------------------------------------------- threedslider · 2025-08-11 14:06 Hi, Lazarus is speed as C programming ? Or more fast than C? Or more less than C? Thank you. ---------------------------------------------------------------------- marcov · 2025-08-11 14:44 Depends on the C . ---------------------------------------------------------------------- Warfley · 2025-08-11 15:47 Generally speaking the mainline C compilers (gcc, clang, msvc) are much better at optimizations than the fpc is. A very simple example is if we compare the output of clang with -O3 on the following function: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unsigned fib(unsigned i) {    if (i<2) return i;    return fib(i-2) + fib(i-1);}Which results in the following assembly: Code: ASM  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fib:      push    rbp        push    rbx        push    rax        mov     ebx, edi        xor     ebp, ebp        cmp     edi, 2        jb      .LBB0_4        inc     ebx        xor     ebp, ebp.LBB0_2:        lea     edi, [rbx - 3]        call    fib        add     ebp, eax        dec     ebx        cmp     ebx, 2        ja      .LBB0_2        mov   ebx, 1.LBB0_4:        add     ebp, ebx        mov     eax, ebp      add     rsp, 8        pop     rbx        pop     rbp        ret With the same function in Pascal: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function fib(i: SizeUInt): SizeUInt;begin  if i<2 then Exit(i);  Result:=fib(i-2)+fib(i-1);end;Also compiled on -O3 resulting in: Code: ASM  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fib(qword):        pushq   %rbx        pushq   %r12        pushq   %r13        movq    %rdi,%rbx        cmpq    $2,%rbx        jnb     .Lj6        movq    %rbx,%r12        jmp     .Lj3.Lj6:        leaq    -2(%rbx),%rdi        call    fib(qword)        movq    %rax,%r13      leaq    -1(%rbx),%rdi        call    fib(qword)        leaq    (%rax,%r13),%r12.Lj3:        movq    %r12,%rax        popq    %r13      popq    %r12        popq    %rbx        retWhile clang does a lot of smaller optimizations, the most obvious is that clang resolved the tail recursion, compared to the fpc code that kept both recursive calls. Additionally C as a language is simpler with less features and requires less runtime code to execute, while pascal has some higher level language concepts where the compiler does more stuff in the background. This means C code is often simpler doing less stuff (but also being less flexible and more error prone), but because it's simpler it's also faster and better optimizable. But on the other hand, some things are harder in C, so for example making dynamic arrays in C is kinda annoying, so most C developers resort to linked lists, which are generally slower than array based lists, so you can have a program written in C where the compiler does much more optimization, but the program in the end will still be slower than a comparable pascal program because in Pascal you'd use an array list where in C you'd use a linked list ---------------------------------------------------------------------- marcov · 2025-08-11 18:01 Also such compiler benchmarks are often math problems in a single source file, which might not actually not be what you would typically do in an application. Things like cross-unit inlining are for many applications much more important. ---------------------------------------------------------------------- domasz · 2025-08-11 19:01 Lazarus (FPC) is faster than most languages. Not necessarily C or C++ but faster than all those popular ones: PHP, Python, JavaScript, Java. ---------------------------------------------------------------------- Warfley · 2025-08-11 20:46 Quote from: domasz on August 11, 2025, 09:01:43 pmLazarus (FPC) is faster than most languages. Not necessarily C or C++ but faster than all those popular ones: PHP, Python, JavaScript, Java. Thats not necessarily true, I guess you base that on the idea that pascal is natively compiled while these others are interpreted/emulated? But thats not really true, first these languages use JIT compilation, so code that is run frequently is as much compiled to machine code as your pascal code is, often with better optimization because it's based on observed behavior. Second those languages use different architectures with different design decisions that make certain things faster and others slower. Take the following two equivalent programs, one in Java: Code: Java  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i public class Main {     private final int adder;     Main(int a) {        adder = a;    }     int add(int i) {        return i+adder;    }     public static void main(String args[]) {        long startTime = System.currentTimeMillis();        int accum = 0;        for (long i=0;i<1000000000l; ++i) {            Main m = new Main((int)i);          accum=m.add(accum);        }        long endTime = System.currentTimeMillis();        System.out.println("Total execution time: " + (endTime-startTime) + "ms");     }} And one in Pascal: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; {$mode objfpc}{$H+}uses SysUtils; type  TTest = class  private    adder: Integer;  public    function Add(i: Integer): Integer;    constructor Create(a: Integer);  end; function TTest.Add(i: Integer): Integer;begin  Result:=i+adder;end; constructor TTest.Create(a: Integer);begin  adder:=a;end; var  i: Int64;  accum: Integer;  start: QWord;  t: TTest;begin  start:=GetTickCount64;  accum:=0;  i:=0;  while i<1000000000 do  begin    t:=TTest.Create(Integer(i));    accum:=t.Add(accum);    t.Free;    Inc(i);  end;  WriteLn('Total execution time: ', GetTickCount64-start, 'ms');  ReadLn;end. Let's run them: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Java:       Total execution time: 200msPascal (-O3): Total execution time: 22657ms So java is around a factor 100 faster. The reason for that is the garbage collector. Java uses a generational mark and sweep garbage collection, so (VERY OVERSIMPLIFIED) when a new object is created it is just pushed on a stack, which is just a single pointer operation (add stackptr, sizeof(object)). Then the function is called on that object and the object is left alone. When the stack is full, the garbage collector will jump in and do a quick reachability analysis, which in the example above is trivial because they all were local variables. The garbage collector will move all the objects that are still reachable to the next generation stack, which in this example are none, and then clear the gen1 stack, which also is just a single operation (set stackptr, 0). So for each iteration there is one add and after a certain number of iterations there will be a single reset. Thats really fast. Take the pascal code on the other hand. With each allocation the memory manager is called, which performs some rather complex allocation lookup. It's not like crazy much effort, but it's certainly orders of magnitude more operations than 1. Then the instantiation code needs to be executed (See TObject.InitInstace) which besides this function also contains a few virtual function calls with need to chase pointers, potentialy have cache invalidation and all that fun stuff. After the method is called on the object, it is freed, which contains a call to the destructor, then the deinitalization code (see TObject.CleanupInstance) before calling the memory manager again. When it comes to creating a lot of small objects Java is much faster than Pascal, if we assume that in this very simple example above the JIT kicks in reasonably early, so the code executed is natively compiled as the FPC code, we can see that initiating and freeing a class in Pascal is roughly 100 times slower than it is in Java. Does this mean Java is in general faster than Pascal? Well it highly depends on the code you write, as I wrote above with the example of linked lists in C, if you create a bunch of throwaway classes in Pascal it's gonna be slow, not because the compiler is slow, but because your code is slow. A disadvantage to this is btw that Idiomatic Pascal code often involves creating temporary objects. If we look for example at the EncodeStringBase64 function in the base64 unit: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function EncodeStringBase64(const s:string):String; var  Outstream : TStringStream;  Encoder   : TBase64EncodingStream;begin  if Length(s)=0 then     Exit('');  Outstream:=TStringStream.Create('');  try    Encoder:=TBase64EncodingStream.create(outstream);    try       Encoder.Write(s[1],Length(s));    finally       Encoder.Free;      end;    Result:=Outstream.DataString;  finally    Outstream.free;    end;end;You can see that it creates two temporary objects just to immediately throw them away. So if you call this function in an inner loop, it's gonna be really slow. Meanwhile if you'd do the same in Java it would be blazingly fast. Lastly, I made a tiny adjustment to the pascal code: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; {$mode objfpc}{$H+}{$ModeSwitch advancedrecords}uses SysUtils; type  TTest = record    {...}    function Add(i: Integer): Integer;inline;    class function Create(a: Integer):TTest;static;inline;  end; {...}class function TTest.Create(a: Integer): TTest;begin  Result.adder:=a;end; {...}    t:=TTest.Create(Integer(i));    accum:=t.Add(accum);    //t.free <-- not needed anymore    Inc(i);{...} I get: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Total execution time: 359msWhich is nearly as fast as Java. By changing the class to a record, most of that overhead is now gone. Additionally I made both functions inline because the JIT compiler of Java does this as an optimization as well, so it's just fair if we want to compare those two. It's still not as fast as Java which is simply because Javas JIT compiler is crazy good, like seriously on repetetive tasks it usually produces much more optimized assembly than even most current C compilers, let alone the FPC. So yeah, Java can easily be faster than FPC ---------------------------------------------------------------------- marcov · 2025-08-11 21:00 Quote from: Warfley on August 11, 2025, 10:46:47 pmThats not necessarily true, I guess you base that on the idea that pascal is natively compiled while these others are interpreted/emulated? But thats not really true, first these languages use JIT compilation, so code that is run frequently is as much compiled to machine code as your pascal code is, often with better optimization because it's based on observed behavior. That is not my experience.  Yes, JITted code can come close and even exceed statically compiled code, specially with crafted benchmark code, but on average in programs that really do something, it doesn't. It is very hard to measure though, since usually it is not the way of code that is dragging those languages down, but the automatic memory management. ---------------------------------------------------------------------- Warfley · 2025-08-11 21:08 Quote from: marcov on August 11, 2025, 11:00:40 pmIt is very hard to measure though, since usually it is not the way of code that is dragging those languages down, but the automatic memory management. It is also very hard to measure because JIT tends to favor simple code thats used for benchmarks, which is why for the example above I even just assumed that the code will be basically as fast if not faster than FPC generated native code, because it is so simple. Also something from this experiment, when I was using int instead of long for the computation, the jit optimizer just threw the whole loop out of the window making it run in like 3ms independently of the number of iterations because without the cast from int to long which involves runtime overflow handling, it just analythically solves the problem putting this whole example ad absurdum. So getting an example that fairly compares just the overhead of creating and freeing objects was actually much harder than one might think. So my point that it's really hard to make statements like "x is faster than y" is really really difficult because theres so much coming together when it comes to how those fare in the field. ---------------------------------------------------------------------- marcov · 2025-08-11 21:40 Quote from: Warfley on August 11, 2025, 11:08:06 pmQuote from: marcov on August 11, 2025, 11:00:40 pmIt is very hard to measure though, since usually it is not the way of code that is dragging those languages down, but the automatic memory management. It is also very hard to measure because JIT tends to favor simple code thats used for benchmarks, which is why for the example above I even just assumed that the code will be basically as fast if not faster than FPC generated native code, because it is so simple. It probably will, but such border conditions (oversimplified, crafted code, dynamic memory use can be optimised away due to fairly basic locality ) need to be annotated with your statements about JIT. Somebody might assume that it is a general rule otherwise. For non trivial usage, personally I'm more interested in Java/C#'s lower threshold to optimise over source file borders. Fairly linear call chains could be integrated and optimised, also in code that does something.  QuoteSo my point that it's really hard to make statements like "x is faster than y" is really really difficult because theres so much coming together when it comes to how those fare in the field. It is difficult. But in my experience in average code, C#/Java don't generally break even, even less so in threaded applications. Startup benchmarks are often atrocious. But that all is more the memory management related than the way of compilation. ---------------------------------------------------------------------- d2010 · 2025-08-11 22:14 The speed of program.exe.,is  cross-linked with the Budget of developers. For low-cost (and mid costs) of program.exe, the Lazarus speed is more-better C++ ++more stability for long terms (after the years ) of programe.lpr.exe. --but for high price of program.exe in C++*.cpp *.c, *.h , the Speed VC++ is more better than Lazarus., work very good of speed , but the price ? ? ---------------------------------------------------------------------- Fred vS · 2025-08-11 23:38 It also depends on the memory manager. For example, for fpc, with the mORMot2 memory manager, I get x6 speed for accessing data in multithreaded applications. ---------------------------------------------------------------------- ALLIGATOR · 2025-08-12 02:46 Quote from: Fred vS on August 12, 2025, 01:38:29 am...with the mORMot2 memory manager, I get x6 speed... Oh, that's very interesting! Have you tried the new versions of FPC? Rika has reworked the memory manager in them, and it seems that it is now better than or on par with mORMot2, but if you could test it on your application, it would be very interesting to see the results. ---------------------------------------------------------------------- ALLIGATOR · 2025-08-12 02:49 The argument in favor of FPC - is compilation speed And optimization is gradually improving the situation. In any case, there is still the LLVM backend, and I hope that it will eventually allow compilation for Windows as well ---------------------------------------------------------------------- domasz · 2025-08-12 04:37 Quote from: Warfley on August 11, 2025, 10:46:47 pmThats not necessarily true, I guess you base that on the idea that pascal is natively compiled while these others are interpreted/emulated? But thats not really true, first these languages use JIT compilation, so code that is run frequently is as much compiled to machine code Okay but now let's add startup time. When I want a program to, for example, convert an image to grayscale I want that program to run once, not a milion times. So I am, as a user, interested in how much will it take from the moment I started the program to the moment it closes. In case of a compiled .EXE the startup is super fast while all those interpreters need to first load themselves, then compile a script to JIT. ---------------------------------------------------------------------- ALLIGATOR · 2025-08-12 04:50 Quote from: domasz on August 12, 2025, 06:37:00 amOkay but now let's add startup time. As far as I know, there is GraalVM, which allows you to compile Java bytecode into native code. And the startup time will be minimal, just like with regular native applications. But I haven't worked with this technology, just information, judging by the website - it looks pretty serious, i.e. it's not some kind of amateurish hack. ---------------------------------------------------------------------- LV · 2025-08-12 07:43 Here are two important points to consider: 1. Flagship C or C++ compilers offer more built-in optimization capabilities than FPC. 2. Highly optimized libraries, such as MKL and OpenBLAS, are written in C or assembly language. Using FPC requires additional effort to achieve performance comparable to C, C++. Despite this, there are compelling reasons to use FPC and Lazarus. ---------------------------------------------------------------------- 440bx · 2025-08-12 09:00 Quote from: LV on August 12, 2025, 09:43:10 amDespite this, there are compelling reasons to use FPC and Lazarus.  As ALLIGATOR mentioned, compilation speed is one of the primordial reasons. I'd add that FPC's implementation of Pascal makes it reasonably easy to implement complex algorithms that are still understandable.  This is something that very often cannot be said about other "optimizing compilers" OTH, a language that doesn't get an update in over 4 years is going to have real problems attracting new blood. ---------------------------------------------------------------------- ALLIGATOR · 2025-08-12 09:18 Well, I don't consider FPC separately from Lazarus. Of course, they are separate projects, but my choice of Pascal was initially due to the fact (since Delphi 7) that it was very easy to create GUI applications in it, and now it is also easy to do in Lazarus. If there were no GUI part, it would probably make Pascal much less attractive to me, and it might be easier to switch to mainstream languages... ---------------------------------------------------------------------- Thaddy · 2025-08-12 09:40 In the past I worked with GCJ but that seems abandoned. ---------------------------------------------------------------------- korba812 · 2025-08-12 10:02 Quote from: threedslider on August 11, 2025, 04:06:08 pmLazarus is speed as C programming ? Or more fast than C? Or more less than C? I would say it depends on the program. For example, I can write an "address book" program faster in Lazarus/FPC than in C. ---------------------------------------------------------------------- threedslider · 2025-08-12 11:24 Quote from: marcov on August 11, 2025, 04:44:58 pmDepends on the C . Yes it depends on C, if it is poorly built it is a penalty for speed I also think it is the same for Lazarus I, right ?. ---------------------------------------------------------------------- marcov · 2025-08-12 11:27 Quote from: threedslider on August 12, 2025, 01:24:43 pmQuote from: marcov on August 11, 2025, 04:44:58 pmDepends on the C . Yes it depends on C, if it is poorly built it is a penalty for speed I also think it is the same for Lazarus I, right ?. Yes, but it is not black-white. Those last bits of performance are the hardest to get in any language, and just because it is theoretically possible, it won't mean that you will be able to unlock them in an application of your own. (and even less so in a finite time) ---------------------------------------------------------------------- threedslider · 2025-08-12 11:30 Quote from: Warfley on August 11, 2025, 10:46:47 pmCode: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Java:       Total execution time: 200msPascal (-O3): Total execution time: 22657ms So java is around a factor 100 faster. I hear that Java from speed is compared to C++ and in some certain case  it is more faster than C++ too...  Quote from: Warfley on August 11, 2025, 10:46:47 pmSo yeah, Java can easily be faster than FPC ---------------------------------------------------------------------- LV · 2025-08-12 13:07 Quote from: threedslider on August 12, 2025, 01:30:50 pmQuote from: Warfley on August 11, 2025, 10:46:47 pmCode: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Java:       Total execution time: 200msPascal (-O3): Total execution time: 22657ms So java is around a factor 100 faster. I hear that Java from speed is compared to C++ and in some certain case  it is more faster than C++ too...  It seems like we are playing a game of how to write the slowest code. Code: C++  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #include #include  class TTest {private:    int adder;public:    TTest(int a) : adder(a) {}    int Add(int i) {      return i + adder;    }}; int main() {    using namespace std::chrono;     auto start = duration_cast(        steady_clock::now().time_since_epoch()    ).count();     long long i = 0;    int accum = 0;     while (i < 1000000000LL) {        TTest* t = new TTest(static_cast(i));        accum = t->Add(accum);        delete t;        ++i;    }     auto end = duration_cast(        steady_clock::now().time_since_epoch()    ).count();     std::cout << "Total execution time: " << (end - start) << "ms\n";    std::cin.get();    return 0;}  Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Total execution time: 41150ms ---------------------------------------------------------------------- threedslider · 2025-08-12 13:41 Mine is more faster in C++  Code: C++  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #include #include #include  using namespace std;using namespace std::chrono; const int N = 10'000'000; void benchmark_array() {    int* arr = new int[N];     for (int i = 0; i < N; ++i)        arr[i] = i;     auto start = high_resolution_clock::now();     for (int i = 0; i < N; ++i)        arr[i] = arr[i] * 2 + 1;     auto end = high_resolution_clock::now();    cout << "Tableau classique : "        << duration_cast(end - start).count()        << " ms" << endl;     delete[] arr;} void benchmark_vector() {    vector vec(N);     for (int i = 0; i < N; ++i)        vec[i] = i;     auto start = high_resolution_clock::now();     for (int i = 0; i < N; ++i)        vec[i] = vec[i] * 2 + 1;     auto end = high_resolution_clock::now();    cout << "std::vector       : "      << duration_cast(end - start).count()        << " ms" << endl;} int main() {    benchmark_array();    benchmark_vector();    return 0;}  Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Tableau classique : 3 msstd::vector       : 2 ms ---------------------------------------------------------------------- threedslider · 2025-08-12 13:58 If I make the change to  1'000'000'000 it gives us that as it : Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Tableau classique : 286 msstd::vector       : 277 ms  Really fast though ---------------------------------------------------------------------- Warfley · 2025-08-12 15:27 Quote from: LV on August 12, 2025, 03:07:22 pmI hear that Java from speed is compared to C++ and in some certain case  it is more faster than C++ too...  ... Yes that's my point, some things are really fast in java, much faster than in other languages. That said the C++ example is a bit off here, because in C++ classes can be allocated on the stack, in pascal you can't (except with hacks). While advanced records and objects exist (see last example in that post) its fair to say that usage of classes in fpc is more common than the alternatives. In comparison in C++ usage of heap allocations is relatively rare (except on enterprise C++ maybe) and most classes are constructed on the stack. So in that regard Pascal code you'd spot in the wild is much closer to Java than it is to C++ ---------------------------------------------------------------------- LV · 2025-08-12 15:35 Quote from: threedslider on August 12, 2025, 03:58:34 pmIf I make the change to  1'000'000'000 it gives us that as it : Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Tableau classique : 286 msstd::vector       : 277 ms  Really fast though  C++ & OpenMP Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Tableau classique : 160 msstd::vector       : 161 ms  FPC & TThread Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Dynamic Array: 156 ms~ std::vector  : 172 ms ---------------------------------------------------------------------- LV · 2025-08-12 15:49 @Warfley, Thanks for your comment. ---------------------------------------------------------------------- Thaddy · 2025-08-12 16:20 @Warfley Old school objects are. like records, stack allocated and that is one of the reasons I still use them. E.g.: for stock exchange tickers you need that to keep up, either that or records. There are no hacks required. That's only when you use classes. In such cases, Freepascal is very close to Java or stack based C++ classes. They still maintain OOP behaviour, contrary to records. ---------------------------------------------------------------------- Warfley · 2025-08-12 16:28 Yeah I personally also prefer to use advanced records or oldschool objects whenever possible. What I don't like about objects is that you have to manually call the Destructor and constructor (if a VMT needs to be initialized). But yeah, if performance is a main concern, classes should be avoided. And with management operators records are more comfortable most of the time. There are cases where classes are neat, but they come with some issues. ---------------------------------------------------------------------- Dzandaa · 2025-08-12 19:10 Hi, for me comparing speed of different language is not very useful if you want speed, use assembly. I started programming in the 1970s, first in Motorola 6800 assembly, then in Motorola 68000. Then in Zilog Z80, 8080, 8086 80386. And I slowly moved on to programming based on languages like Basic, Cobol, Forth, Fortran, Action, Pascal (which was a learning language and I didn't like it very much), Modula, python, etc., etc. then I moved on to C, Borland C++ and finally C#, not to mention PHP for web applications. But what I missed most was the portability of being able to easily transfer my codes to Linux or Mac. I discovered Pascal Lazarus much too late, because I was retired at that time. And I was very surprised, not so much by the execution speed, but by the ease of creating windowed programs. Currently, the programming trend is Python, but it's important to remember that Python was originally an interface language. Most of its libraries are written in C or C++. As for portability, if you need to use Python in a student classroom, you need to remember to install all the libraries and their dependencies on each computer! The Lazarus Pascal IDE has the advantage of being open source, not depending on GAFFAM's and their spyware, AI, etc., and providing executable that can run on any platform. And I think it should have been a better-known teaching tool. But that's just the opinion of an old geek. B-> ---------------------------------------------------------------------- jamie · 2025-08-12 21:47 I think you left out the 8051, 6502, 6510.  How about the 4004 intel processor which I have a frew.  and no, I am not giving any of them up, not even the pulled ones! Jamie ---------------------------------------------------------------------- Dzandaa · 2025-08-13 09:30 Hi, @Jamie: You're right, I forgot about that good old 6502, I think I still have one in my basement B-> ---------------------------------------------------------------------- Thaddy · 2025-08-13 16:20 6510 (Commodore64) still running, floppydisk station is beyond repair as are the flops. On topic: Well written Pascal code is faster than average written C code. Compiler optimizations aside. ( which has nothing to do with a language.  , such optimizations CAN be applied to Pascal compilers ) And nobody in this discussion seems to use WPO anyway....which is a shame. Language, syntax, itself does not imply speed. ---------------------------------------------------------------------- threedslider · 2025-08-13 19:17 Quote from: Thaddy on August 13, 2025, 06:20:25 pmOn topic: Well written Pascal code is faster than average written C code. Compiler optimizations aside. ( which has nothing to do with a language.  , such optimizations CAN be applied to Pascal compilers ) And nobody in this discussion seems to use WPO anyway....which is a shame. Language, syntax, itself does not imply speed. I agreed on what you say, only the good algorithm can make faster in program and it is independent from programming language.  It works in any programming language as well.