IMHO, the video and the related GitHub project have a slightly different purpose and the title is misleading. They are rather a lecture on different programming languages. Just look at it all and you will understand what it is about. Not bad at overall.
In that case please consider my imprecation to be directed at OP who seemed to think that the numbers were significant.
/usr/local/src/seed7$ s7c -O2 -oc3 sinx2area.s7
SEED7 COMPILER Version 3.1.510 Copyright (c) 1990-2021 Thomas Mertes
Source: sinx2area.s7
Compiling the program ...
Generating code ...
after walk_const_list
740 declarations processed
219 optimizations done
277 evaluations done
14 range checks inserted
107 index checks inserted
96 overflow checks inserted
Calling the C compiler ...
gcc -w -O2 -ffunction-sections -fdata-sections -c tmp_sinx2area.s7.c 2>tmp_sinx2area.s7.cerrs >/dev/null
Calling the linker ...
gcc -Wl\,--strip-debug -Wl\,--gc-sections -o sinx2area.s7_exe tmp_sinx2area.s7.o /usr/local/src/seed7/seed7/bin/s7_data.a /usr/local/src/seed7/seed7/bin/seed7_05.a -lm -ldl 2>tmp_sinx2area.s7.lerrs >/dev/null
/usr/local/src/seed7$ time ./sinx2area.s7_exe
0.8953136
real 0m0.627s
user 0m0.622s
sys 0m0.005s
/usr/local/src/seed7$ fpc sinx2area.pas
Free Pascal Compiler version 3.2.0 [2020/11/20] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sinx2area.pas
Linking sinx2area
20 lines compiled, 0.2 sec
/usr/local/src/seed7$ time ./sinx2area
8.952804208E-01
real 0m1.026s
user 0m1.025s
sys 0m0.000s
/usr/local/src/seed7$ fpc -O1 sinx2area.pas
Free Pascal Compiler version 3.2.0 [2020/11/20] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sinx2area.pas
Linking sinx2area
20 lines compiled, 0.2 sec
/usr/local/src/seed7$ time ./sinx2area
8.946775794E-01
real 0m1.064s
user 0m1.013s
sys 0m0.000s
/usr/local/src/seed7$ fpc -O2 sinx2area.pas
Free Pascal Compiler version 3.2.0 [2020/11/20] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sinx2area.pas
Linking sinx2area
20 lines compiled, 0.2 sec
/usr/local/src/seed7$ time ./sinx2area
8.946207762E-01
real 0m1.094s
user 0m1.090s
sys 0m0.001s
/usr/local/src/seed7$ fpc -O3 sinx2area.pas
Free Pascal Compiler version 3.2.0 [2020/11/20] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sinx2area.pas
Linking sinx2area
20 lines compiled, 0.2 sec
/usr/local/src/seed7$ time ./sinx2area
8.946905732E-01
real 0m1.087s
user 0m1.079s
sys 0m0.004s
/usr/local/src/seed7$ fpc -O4 sinx2area.pas
Free Pascal Compiler version 3.2.0 [2020/11/20] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sinx2area.pas
Linking sinx2area
20 lines compiled, 0.3 sec
/usr/local/src/seed7$ time ./sinx2area
8.948547840E-01
real 0m1.067s
user 0m1.067s
sys 0m0.001s
If you are a speed geek, you will probably be interested in this.
What is the FASTEST Computer Language? 45 Languages Tested! (E01)
Old rule of thumb is that benchmarks that have a small amount of code in a single source file are pointless for the general case.
They might model e.g. codecs or other very localized code, but hardly sizeable applications.
Comparisons are odious, and benchmarks doubly so. However they can at the very least highlight a perception problem.with version 3.2.2 (and 3.2.0) num+=1 is not allowed.
. . .
. . .
while with the comparable Pascal program
program sinx2area; const n= 10000000; var x, y: double; i: longint; num: longint= 0; begin Randomize; for i := 0 to n - 1 do begin x := 2.0 * Random(); y := Random(); if y < Sin(x * x) then num += 1 end; WriteLn(2.0 * num / n) end.
Undoubtedly. But we're not talking about a mere couple of percent here, and with the demise of Delphi as a standard bearer this is enough to affect the perception of Pascal as a whole.
Comparisons are odious, and benchmarks doubly so. However they can at the very least highlight a perception problem.with version 3.2.2 (and 3.2.0) num+=1 is not allowed.
. . .
. . .
while with the comparable Pascal program
program sinx2area; const n= 10000000; var x, y: double; i: longint; num: longint= 0; begin Randomize; for i := 0 to n - 1 do begin x := 2.0 * Random(); y := Random(); if y < Sin(x * x) then num += 1 end; WriteLn(2.0 * num / n) end.
You should use num:=num+1;
perhaps there is a switch to enable +=, but you have not provided it.
This needs mode objfpc or objdelphi to work.
This needs mode objfpc or objdelphi to work.
Or passing -Sc option to the compiler.
This needs mode objfpc or objdelphi to work.
Or passing -Sc option to the compiler.
That's strange, since the program as I gave it didn't originally need anything like that... and I did supply the commandlines etc. that I was using.
Does 3.2 change the default?
MarkMLl
So sorry for my post, it is not relevant.
@ BobDog, here on Linux 64 with fpc 3.2.0 it works without any change.
[…]Yes, there is a compiler switch called {$cOperators} (https://freepascal.org/docs-html/current/prog/progsu10.html). By default it’s off, but in the standard fpc.cfg(5) located at /etc/fpc.cfg there is a line
with version 3.2.2 (and 3.2.0) num+=1 is not allowed.
You should use num:=num+1;
perhaps there is a switch to enable +=, but you have not provided it.
No. Confer another thread on C-style assignments from earlier this month:[…] Or passing -Sc option to the compiler.That's strange, since the program as I gave it didn't originally need anything like that... and I did supply the commandlines etc. that I was using.
Does 3.2 change the default? […]
COperators Off is the default as far as the compiler is concerned. The fpc.cfg includes the -Sc. Also this will not change due to backwards compatibility.
No. Confer another thread on C-style assignments from earlier this month:COperators Off is the default as far as the compiler is concerned. The fpc.cfg includes the -Sc. Also this will not change due to backwards compatibility.
By default it’s off, but in the standard fpc.cfg(5) located at /etc/fpc.cfg there is a line:
Now I am sure that somebody will point out that there are compiler directives or command-line options that will speed that up, but that's hardly the point.
Here we have two languages, of comparable functionality, and in terms of performance FPC is perceived as inferior.
with version 3.2.2 (and 3.2.0) num+=1 is not allowed.
You should use num:=num+1;
perhaps there is a switch to enable +=, but you have not provided it.
something i've experienced with fpc but didn't know how to report it
i've done alots of benchmarks with defernet levels of optimization (-O1..4), the weird thig is all gives the same result
while on other compilers like gcc / vc you'll find for example -O3 produce much faster code than -O1
And do they document which PRNG they use? FPC's Random is documented to be a Mersenne Twister (though the generated sequence is not guaranteed to be that of a raw MT) and MTs are known to be on the slower side of things. So maybe right here you're comparing the performance of one PRNG to another instead of compiler A to compiler B.
$ include "seed7_05.s7i";
include "bigint.s7i";
const proc: main is func
local
var bigInteger: fiveToThePowerOf262144 is 5_ ** 4 ** 3 ** 2;
var string: numberAsString is str(fiveToThePowerOf262144);
begin
writeln("5**4**3**2 = " <& numberAsString[..20] <&
"..." <& numberAsString[length(numberAsString) - 19 ..]);
writeln("decimal digits: " <& length(numberAsString));
end func;
~$ time ./GMP_Demo.s7_exe
5**4**3**2 = 62060698786608744707...92256259918212890625
decimal digits: 183231
real 0m0.003s
user 0m0.000s
sys 0m0.004s
I know seed from 10-15 years back when Mertens was a regular in comp.lang.misc. It was really the meta programming and not fixating any rule for a language that seemed to be interesting to him.
Note that the seed7 "compiler" compiles to C, so you are probably effectively comparing codegeneration to gcc.
Yes. Hence I was wondering whether when GCC recompiled a program plus all imports it was managing to eliminate stackframes etc. to a far greater extent than FPC can manage with precompiled libraries and units.
Or this: https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf
Looks like all the fastest languages have an LLVM version
Even Intel just moved their compiler to LLVM. If Intel does not have the resources to maintain the optimizations necessary for a fast compiler, it is hopeless for FPC. If FPC wants to be the fastest language, the LLVM mode should be the default
Or this: https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf
Looks like all the fastest languages have an LLVM version
Even Intel just moved their compiler to LLVM. If Intel does not have the resources to maintain the optimizations necessary for a fast compiler, it is hopeless for FPC. If FPC wants to be the fastest language, the LLVM mode should be the default
Or this: https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf
Looks like all the fastest languages have an LLVM version
Even Intel just moved their compiler to LLVM. If Intel does not have the resources to maintain the optimizations necessary for a fast compiler, it is hopeless for FPC. If FPC wants to be the fastest language, the LLVM mode should be the default
If FPC wants to be the fastest language, the LLVM mode should be the defaultNot something the core team will ever do, reading at this wiki article (https://wiki.lazarus.freepascal.org/LLVM#Frequently_Asked_Questions), even if they do admit on certain programs (that typically benchmarks focus on) LLVM does generate a faster code.
Looks like all the fastest languages have an LLVM version.
If FPC wants to be the fastest language, the LLVM mode should be the default
If FPC wants to be the fastest language, the LLVM mode should be the defaultЯ не думаю, что это хорошая идея! Заглядывать и оптимизировать код - это да. Но менять одно на другое? Зачем? Что нельзя сделать, что уже сделано в LLVM?
Hello @Fre;D,
I have a question about mseide-msegui (https://github.com/mse-org/mseide-msegui). If I understand correctly, there are visual controls (of msegui) that are drawn by calls to X11 (like fpGUI (https://github.com/graemeg/fpgui/)).
I know that fpGUI has an independent package (fpgui_ide.lpk) that I just need to be required in a Lazarus project in order to create an X11 application (I also know that you have written an IDE-designer in order to create X11 RAD forms).
My question - general culture - is: is there a msegui package (*.lpk) that can be also required from a Lazarus project (really sorry, I'm just an application builder knowing nothing about compilers; no more time to disperse myself towards something else, different from Lazarus [^])?
If so, are the msegui and fpGUI controls compatible, adaptable (in a same X-11 application, rather targeted at the base for a true graphic server having no desktop installed on it, AFAIK the boundary between Wayland and X11)?
If FPC wants to be the fastest language, the LLVM mode should be the default
No one said that this is our goal. Yes, we want FPC to generate good, fast code, but speed is not everything.
Comparisons are odious, and benchmarks doubly so. However they can at the very least highlight a perception problem.Interesting idea. I also had such idea, when wanted to implement closures by myself. They're just syntax sugar around interfaces, so they should be easy to implement. But I don't have enough experience with FPC sources to do everything right and not brake anything. And then I realized, that it would be great to have extendable syntax. Even whole language could be build from scratch around compile-time extendable syntax. I would call it MetaPascal.
I've occasionally taken a look at Seed7, which is Pascal-like but simplifies a number of concepts and increases the language flexibility enormously. Using the Montecarlo benchmark at http://seed7.sourceforge.net/benchmks/montecarlo.htm I get a runtime like
Interesting idea. I also had such idea, when wanted to implement closures by myself. They're just syntax sugar around interfaces, so they should be easy to implement. But I don't have enough experience with FPC sources to do everything right and not brake anything. And then I realized, that it would be great to have extendable syntax. Even whole language could be build from scratch around compile-time extendable syntax. I would call it MetaPascal.
FPC does not implement anonymous methods yet. It has been in the works for years by 3rd party devels, but somehow it doesn't get finished (or submitted)May be that's because they think, that it's hard to implement? It's just another way of defining classes, that doesn't require class definition itself and therefore saves many code lines. Overall whole closure structure is something like this:
FPC does not implement anonymous methods yet. It has been in the works for years by 3rd party devels, but somehow it doesn't get finished (or submitted)May be that's because they think, that it's hard to implement? It's just another way of defining classes, that doesn't require class definition itself
So, it's just matter of turning one code into another code. That's why having extendable syntax would be great for this task.
All I need - is to replace this:with this:
type TIterator = reference to function:Integer; var Iterator:TIterator; function CreateIterator:TClosure; var I:Integer; begin I := 0; Result := function:Integer begin Result := I; Inc(I); end; end; Iterator := CreateIterator; WriteLn(Iterator); Now I need to learn how to change FPC sources for this. It would take too much time, would be too hard and counter-productive. But what if I would be able to add some Closures.pas unit to my project, where I would be able to describe closure extended syntax? It would be compiled to some sort of compiler runtime module, that would be able to handle closures at compile time.
type IIteratorInterface = interface; TIteratorMethod1 = function(Self:IIteratorInterface):Integer; IIteratorInterface = interface function IteratorMethod1:Integer; end; TIterator = record Method:TIteratorMethod1; Interface:IIteratorInterface; end; TIteratorClass = Class(TInterfacedObject, IIteratorInterface) I:Integer; function IteratorMethod1:Integer; end; var Iterator:TIterator; function TIteratorClass.IteratorMethod1:Integer; begin Result := I; Inc(I); end; function CreateIterator:TIterator; var IteratorVar:TIteratorClass; begin IteratorVar := TIteratorClass.Create; IteratorVar.I := 0; Result.Method := @IteratorVar.IteratorMethod1;//I know, it's wrong Result.Interface := IteratorVar; end; Iterator := CreateIterator; WriteLn(Iterator.Method(Iterator.Interface));
It is primarily added for Delphi compatibility and there it is primarily used to schedule tasks in other threads. But yes, it must dynamically capture state. (though that is horribly wonky in Delphi too, as it often captures references to state rather than the state itself). And it must all be memory safe in the end (though that builds on top of existing interfaces infra).They're usable in any callbacks, that require state passing. While classes are data with code attached to them, closures are opposite - they're code with data attached to them. Test cases are implemented via closures in my project. There are thousands of them. It has taken many months to write this code. That's why their code should be kept as minimum, as possible. Rewriting this code using classes/interfaces would be massive job. But overall my goal is to fully migrate to Linux and get rid of Windows/Delphi dependency. I would want to help with it, but starting to dig into FPC sources from scratch - is too big thing for me and I really think, that it would be counter-productive.
Why it takes so long I don't know, and since there is little info to base speculation on.
Why it takes so long I don't know, and since there is little info to base speculation on.
Really any ALGOL 60 (68?) descendant would have the same speed potential. It would only be a compiler matter. C, Pascal, Ada, teoretically can achieve same speed.
In certain (broad) way, C<->Pascal translation is nearly automatic.
And even i would say that pascal should do even better speed because compiler has more information (strong typed, and things like that).
On the other hand, it's difficult today thinking in a big app made with only one languaje. OS (platform) are in Cs* and even same compiler with same languaje (even C) could perform different from one OS to another...
'm sorry, I disagree. As a specific example, a language which relies heavily on termination code at the end of every block to unwind temporary allocations and exception handlers will always be slower than one that doesn't provide that facility, and that is generally made worse if separate compilation prevents that from being optimised away (due to callbacks expecting the same stack layout).
Apart from that, just about everything is derived from ALGOL these days. Classic FORTRAN and COBOL have (thankfully) withered as have environments such as Lisp, Prolog, Smalltalk and Forth, and their descendants are quick to point out how much they've borrowed from ALGOL/Pascal/Ada: control blocks, data structures and the rest. But some of those descendants couldn't be implemented without heavy use of either reference counting or garbage collection, and again those are inherent time-wasters.
I've had people in the past trying to convince me that UNIX-based systems could /only/ be programmed in C.
Well, nothing to say, your point is valid, i agree. I was thinking more on c/pascal/ada tree of algol68.
I've thinking a lot of times that i would love that history will make pascal - again- used as OS languaje. Any knows if there is being tried a OS coded in pascal or something like that?. It would be funny repeating the story of Linus Torvalds redoing kernel in FreePascal.
Sometimes i have thought (but i have no time) of making a mini OS made only in pascal as a start point for doing something bigger. Dreams...
Yes, there've been many: as a specific example, Cray's OSes were coded in Pascal (although the anti-Pascal purists would attempt to save face by saying that because it was enhanced beyond the standard definitions it wasn't really Pascal). I've used Modula-2 for a microkernel plus network etc.
BUT robust type checking becomes a problem as soon as you're passing variable-sized packets around which negates a lot of Pascal's advantage.I don't know why. Even in the worst case one can take these as raw data, have fun with pointers and then process that like a C code. Well, i'm talking lightly without seeing the real problem. In worst scenario one will be like C and a nice reading code :)
QuoteYes, there've been many: as a specific example, Cray's OSes were coded in Pascal (although the anti-Pascal purists would attempt to save face by saying that because it was enhanced beyond the standard definitions it wasn't really Pascal). I've used Modula-2 for a microkernel plus network etc.
I would search for these (itches my curiosity). Are there modern ones?.
QuoteBUT robust type checking becomes a problem as soon as you're passing variable-sized packets around which negates a lot of Pascal's advantage.I don't know why. Even in the worst case one can take these as raw data, have fun with pointers and then process that like a C code. Well, i'm talking lightly without seeing the real problem. In worst scenario one will be like C and a nice reading code :)
But the last thing you want if considering a robust language is to be passing pointers around without the compiler having the opportunity to check and enforce the size of the associated data... which is exactly what you get with stream-based protocols like TCP.Yes, but i do not know a robust solution for this. Only say that FreePascal con do with same or better readibility than C and same performance. Designing a new protocol in...3..2..1.. >:D
Thanks MarkMLI
I will see the http://www.projectoberon.com/home i allways love read WirthQuoteBut the last thing you want if considering a robust language is to be passing pointers around without the compiler having the opportunity to check and enforce the size of the associated data... which is exactly what you get with stream-based protocols like TCP.Yes, but i do not know a robust solution for this. Only say that FreePascal con do with same or better readibility than C and same performance. Designing a new protocol in...3..2..1.. >:D