On 28/11/2021 12:52, Bart wrote:
> OK, you can understand that internally, a language+implementation can
> do things as it pleases, just so long as the user can do A+B and it
> does what is expected of it.
> Which means /my/ implementation can choose to handle it as it likes
> too.

Of course it can.

> Yet not long ago you seemed to keen to implement things like:
>    A +:= B
> via operator-overload mechanisms expressed within the language
> itself.

??? You again fail to distinguish between how something
is defined, and how it is implemented. "A +:= B" is defined by
the RR, /together with/ [as in many language specifications] a
general rule [end of RR10.1] that the definition describes the
effect, and implementations are free to use more efficient
methods. In the instant case, the RR explains what "A +:= B"
is supposed to do; you can't really expect it to give the
machine code for your computer, that's up to the compiler.

> And more recently that you wanted new comparison operators to
> be defined the same way.

If you have a new operator, how would you propose it be
defined, in general, other than within the language? We can't
go around re-revising the language specification every time
someone thinks of a new useful operator, nor every time someone
invents new hardware with different machine code.

> In that latter case, the benefits of the language allowing such new
> features without bothering the language or changing the compiler,
> seemed to be outweighed by the poor quality and limitations of the
> result (and its non-stardardness!)

Two different things. As noted during the debate, I
personally have no requirement for "A < B < C"; I merely point
out that I can at least /define/ what that means within A68.
If I point out some useful operator that your language is
missing [eg, the ability to write "A + B" where "A" and "B"
are graphs or games or functions], you have to change your
compiler [and its associated documentation]; I just write
and annotate some more A68. "Poor quality" is a matter of
opinion; you're like the man who, seeing his neighbour's
dog playing chess, complained that it wasn't playing very
well. "Limitations" are your lack of imagination. "Non-
standardness" happens every time you write a new function
in your program; it is up to good programmers to give new
functions sufficiently descriptive names [or comments].
The same applies to operators and types.

> But it seems my approach is perfectly valid too.

Of course it is, if that's all you want. But it
doesn't work for standardised languages used by lots of
people, and perhaps across lots of hardware.

> I've just used gcc to build a 4-line hello.c program; it took over 5
> seconds even on my somewhat faster new PC, less than 1 line per
> second!

Perhaps you should switch to plain old "cc"? Oh,
wait, on my machine that is a symlink to "gcc". On my home
PC, thirteen years old and nothing fancy, it compiles and
runs a "hello.c" program in 0.04s, only 3x slower than A68G.

[...]
>>> Except that it isn't a matter of syntax; that's too constraining.
>>          It /is/ a matter of syntax in the RR;  in what sense is
>> it constraining?  If you use undeclared variables, do you not
>> want the compiler to detect the error?
> But it's nothing to do with syntax!

In the RR, it /is/ to do with syntax. ...

> Syntax is just the shape of the
> code. Here is the kind of syntax we've been using:
>    A + B
> That's a perfectly valid expression in most normal languages. Except
> in Algol68, because A and B haven't been declared?

... If there is no declaration for "A" and "B", then it
may be syntactically correct in your language, but it surely is
not valid? In A68, there is no route from the concept "program"
to "... letter a symbol, plus symbol. letter b symbol, ..." if
they are not declared. Whether the compiler reports that as a
syntax error or more helpfully as "identifier A not declared" is
a matter of QoI.

> It's far simpler to separate these different ideas: the shape of the
> code; the resolving of the names (which may detect they are
> undefined); the code generation, execution etc.

So much simpler that the C, C++, Ada, ... standards are
much bigger, much harder to navigate, and leave far too much
ill-defined. Of course, if your language doesn't /have/ a
standard, that is indeed much simpler. But as soon as C moved
away from the one implementation at Bell Labs, and it was no
longer possible for everyone to ask DMR what something meant,
it all became more complicated. /You/ grumble about the result
in practically every exchange here with DB.

Anyway, /you/ see them as "these different ideas". The
RR sees at least the first two as a unified whole; there is a
book, "Grammars for Programming Languages" by Cleaveland and
Uzgalis which explains how to integrate all the rest also into
one single grammar. You might think that's going too far?

> In my dynamic language, it doesn't care they might be undefined until
> runtime.

That's fine; it just means that your language is not
the same as C or Algol or ... in this respect. Leaving things
to runtime has its own pros and cons; you seem very unwilling
to accept that some issues are "on the one hand ..., on the
other ..." so that there is a balance to be struck -- which
sometimes comes down one side, sometimes the other.

> Instead, Algol68 chooses the most complex approach all, that is hard
> to understand and difficult to implement.

You aren't expected to learn A68 from the RR, but from
a suitable textbook. It's not hard to learn, unless you are
claiming that you are substantially more stupid than the many
thousands of students who learned A68 as their first language
in [mainly] the 1970s. It's certainly harder than Pascal to
implement; but you write compilers once and use them many
times, so the difficulty is amortised over thousands of uses.

>> Or do you prefer the
>> early versions of Fortran or C where the compiler assumes that
>> an undeclared "j" [for example] is an integer variable?
> If that's what the language said, then that's what it will be. If I
> execute this complete program of my 'Q' language:
>     print j
> it says:
>     <Void>
> (That's not an error, but most other uses are.)

In a compiled language, it's a disaster waiting to
happen, which is why it was dropped from Fortran and C.
Again, the balance of risk is different in different
environments. Serious [esp life-critical] code should not
depend on things that can easily happen by accident, eg by
a simple typo.

> It's not exactly the end of the world. In Algol68:
>     INT j;
>     print(j)
> gives a runtime error. So j might be defined, but it hasn't done much
> good! I guess the RR doesn't make correct /initialisation/ part of
> the syntax?

It's undefined by the RR, and in general is not
computable at compile time. Requiring initialisation along
with the declaration is inefficient [think eg of a large
array where the required values are derived, eg, from user
input, so that filling in zeroes, for example, would be
wasted]. A68G, as you have found, treats it as a run-time
error; yes, there's a speed penalty, but it also picks up
lots of programming errors.

> [...] What I can confidently say is that, to me,
> [the RR] is almost completely useless for any purpose.

That's fine. You're not writing an A68 compiler.
But it also means that you're equally almost completely
unqualified to comment on any matter of A68.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ravel

On 28/11/2021 23:10, Andy Walker wrote:
> On 28/11/2021 12:52, Bart wrote:

>> I've just used gcc to build a 4-line hello.c program; it took over 5
>> seconds even on my somewhat faster new PC, less than 1 line per
>> second!
>
>     Perhaps you should switch to plain old "cc"?  Oh,
> wait, on my machine that is a symlink to "gcc".  On my home
> PC, thirteen years old and nothing fancy, it compiles and
> runs a "hello.c" program in 0.04s, only 3x slower than A68G.

On my WSL, 'gcc hello.c && ./a.out' takes 0.25 seconds from 'cold', and
then 0.1 seconds.

However, I use Windows. DB will say that Windows is slow at file
operations, so it is not gcc's fault.

I would say it /is/ the app's fault if it has a complex enough structure
that it struggles to start up each time, faults that may be hidden on
forgiving OSes. Hence why I sometimes like to test across both.

>> [...]  What I can confidently say is that, to me,
>> [the RR] is almost completely useless for any purpose.
>
>     That's fine.  You're not writing an A68 compiler.
> But it also means that you're equally almost completely
> unqualified to comment on any matter of A68.
>

So they wanted to be elitist; that's fine. They can keep their language!
But people can voice their opinions about it too.

I just selected some choice bits of syntax and adapted them for my own
purposes. However, thanks to the exchanges here, I have a mind to tweak
my syntax to break any remaining Algol68 connections.

I can already write 'end', 'endif' etc in place of 'fi' 'esac', 'od',
the keywords that tend to give it away.

My language, if I were to produce a reference to it, would definitely
not be gobbledygook; I'd see to that. But that's unlikely to happen
since, as certain people like to point out, it's one-person language;
the benefits would be minimal.

It would be like producing a guide to my own house.

Here however are some benchmarks for 'fannkuch(10)':

Secs Lang Types Exec

A68G 50 A68 Static Interp? Win or WSL
A68G -optimise -- A68 (WSL: Failed)
qq -asmopt 2.2 Q Dynamic Interp (mildly accelerated)
gcc -O3 0.22 C Static Native
mm -opt 0.22 M Static Native

My stuff doesn't do too badly speedwise does it?

I couldn't get a68g -optimise to even, even on WSL, a shame as that
50-second timing to interpret /static/ code is poor.

On 29/11/2021 00:53, Bart wrote:

>
> Here however are some benchmarks for 'fannkuch(10)':
>
>                    Secs  Lang  Types    Exec
>
>   A68G             50    A68   Static   Interp?   Win or WSL
>   A68G -optimise   --    A68                     (WSL: Failed)
>   qq -asmopt        2.2  Q     Dynamic  Interp   (mildly accelerated)
>   gcc -O3           0.22 C     Static   Native
>   mm -opt           0.22 M     Static   Native
>
> My stuff doesn't do too badly speedwise does it?
>
> I couldn't get a68g -optimise to even, even on WSL, a shame as that 50-second
> timing to interpret /static/ code is poor.

$ cat hello.c
#include <stdio.h>
int main() {printf("Hello World!");}
$ time gcc hello.c && ./a.out

real 0m0.038s
user 0m0.034s
sys 0m0.004s
Hello World!$

$ cat hello.a68
BEGIN print("Hello World!") END
$ time a68g hello.a68
Hello World!

real 0m0.016s
user 0m0.008s
sys 0m0.008s
$

That's Ubuntu on a modern Intel 68-bit hardware.

--
Charles H. Lindsey ---------At my New Home, still doing my own thing------
Tel: +44 161 488 1845 Web: https://www.clerew.man.ac.uk
Email: chl@clerew.man.ac.uk Snail-mail: Apt 40, SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

On 29/11/2021 12:30, Charles Lindsey wrote:
> On 29/11/2021 00:53, Bart wrote:
>
>>
>> Here however are some benchmarks for 'fannkuch(10)':
>>
>>                     Secs  Lang  Types    Exec
>>
>>    A68G             50    A68   Static   Interp?   Win or WSL
>>    A68G -optimise   --    A68                     (WSL: Failed)
>>    qq -asmopt        2.2  Q     Dynamic  Interp   (mildly accelerated)
>>    gcc -O3           0.22 C     Static   Native
>>    mm -opt           0.22 M     Static   Native
>>
>> My stuff doesn't do too badly speedwise does it?
>>
>> I couldn't get a68g -optimise to even, even on WSL, a shame as that
>> 50-second timing to interpret /static/ code is poor.
>
> $ cat hello.c
> #include <stdio.h>
> int main() {printf("Hello World!");}
> $ time gcc hello.c && ./a.out
>
> real    0m0.038s
> user    0m0.034s
> sys    0m0.004s
> Hello World!$
>
> $ cat hello.a68
> BEGIN print("Hello World!") END
> $ time a68g hello.a68
> Hello World!
>
> real    0m0.016s
> user    0m0.008s
> sys    0m0.008s
> $
>
> That's Ubuntu on a modern Intel 68-bit hardware.

I'm still stuck on 64 bits unfortunately.

The purpose of the 'hello world' test was to demonstrate the start-up
overheads of a big compiler like gcc.

So even on my SSD-based PC, that overhead will add 0.25 seconds to
building any program.

People like to demonstrate how starting gcc on Linux takes zero time; I
don't know why that is. Maybe large Windows PE/DLL files are slower to
process; maybe much of what is needed for gcc on Linux is already running.

However, I work on Windows, and that timing is real. My C compiler also
runs on Windows, and that doesn't have a problem:

C:\c>tm bcc hello
Compiling hello.c to hello.exe
TM: 0.03

(Note that running even an empty program on this OS will take 0.02
seconds anyway.)

Regarding the above benchmark, the A68 code for that is given below.

So that I can properly fill in my table, I'd be grateful if you could
run this on your machine both with and without -optimise, as that flag
doesn't work on my WSL. Then I can estimate the runtime on my machine.

(I assume it transpiles to C then runs that C. The errors are within the
A68 headers.)

-----------------------------------------------------------------------------------
INT res2;

PROC fannkuch=(INT n)INT: BEGIN
[n]INT p,q,s;
INT sign, maxflips, sum, q1, flips, qq, t, sx, i,j;

sign:=1;
maxflips:=0;
sum:=0;

FOR i TO n DO
p[i]:=i;
q[i]:=i;
s[i]:=i
OD;

DO
q1:=p[1];
IF q1/=1 THEN
FOR i FROM 2 TO n DO q[i]:=p[i] OD;
flips:=1;
DO
qq:=q[q1];
IF qq=1 THEN
sum+:=sign*flips;
IF flips>maxflips THEN
maxflips:=flips
FI;
exit1
FI;

q[q1]:=q1;
IF q1>=4 THEN
i:=2; j:=q1-1;
WHILE
t:=q[i]; q[i]:=q[j]; q[j]:=t;
i+:=1;
j-:=1;
i<j
DO SKIP OD
FI;
q1:=qq;
flips+:=1
OD;
exit1: SKIP
FI;

IF sign=1 THEN
t:=p[2]; p[2]:=p[1]; p[1]:=t;
sign:=-1
ELSE
t:=p[2]; p[2]:=p[3]; p[3]:=t;
sign:=1;
FOR i FROM 3 TO n DO
sx:=s[i];
IF sx/=1 THEN s[i]:=sx-1; exit2 FI;
IF i=n THEN
res2:=maxflips;
return
FI;
s[i]:=i;
t:=p[1];

FOR j TO i DO
p[j]:=p[j+1]
OD;

p[i+1]:=t
OD;
exit2: SKIP
FI
OD;
return:
sum
END;

INT n=10;
INT res;
res:=fannkuch(n);

print(("Fannkuch(",n,") = ",res," ", res2,newline))
-----------------------------------------------------------------------------------

Output should be:

Fannkuch( +10) = +73196 +38

On 29/11/2021 13:33, Bart wrote:
> On 29/11/2021 12:30, Charles Lindsey wrote:
>> On 29/11/2021 00:53, Bart wrote:
>>
>>>
>>> Here however are some benchmarks for 'fannkuch(10)':
>>>
>>>                     Secs  Lang  Types    Exec
>>>
>>>    A68G             50    A68   Static   Interp?   Win or WSL
>>>    A68G -optimise   --    A68                     (WSL: Failed)
>>>    qq -asmopt        2.2  Q     Dynamic  Interp   (mildly accelerated)
>>>    gcc -O3           0.22 C     Static   Native
>>>    mm -opt           0.22 M     Static   Native
>>>
>>> My stuff doesn't do too badly speedwise does it?
>>>
>>> I couldn't get a68g -optimise to even, even on WSL, a shame as that 50-second
>>> timing to interpret /static/ code is poor.
>>
>> $ cat hello.c
>> #include <stdio.h>
>> int main() {printf("Hello World!");}
>> $ time gcc hello.c && ./a.out
>>
>> real    0m0.038s
>> user    0m0.034s
>> sys    0m0.004s
>> Hello World!$
>>
>> $ cat hello.a68
>> BEGIN print("Hello World!") END
>> $ time a68g hello.a68
>> Hello World!
>>
>> real    0m0.016s
>> user    0m0.008s
>> sys    0m0.008s
>> $
>>
>> That's Ubuntu on a modern Intel 68-bit hardware.
>
> I'm still stuck on 64 bits unfortunately.
>

> Regarding the above benchmark, the A68 code for that is given below.
>
> So that I can properly fill in my table, I'd be grateful if you could run this
> on your machine both with and without -optimise, as that flag doesn't work on my
> WSL. Then I can estimate the runtime on my machine.
>
> (I assume it transpiles to C then runs that C. The errors are within the A68
> headers.)
>
> -----------------------------------------------------------------------------------
> INT res2;
>
> PROC fannkuch=(INT n)INT: BEGIN
>     [n]INT p,q,s;
>     INT sign, maxflips, sum, q1, flips, qq, t, sx, i,j;
>
>     sign:=1;
>     maxflips:=0;
>     sum:=0;
>
>     FOR i TO n DO
>         p[i]:=i;
>         q[i]:=i;
>         s[i]:=i
>     OD;
>
>     DO
>         q1:=p[1];
>         IF q1/=1 THEN
>             FOR i FROM 2 TO n DO q[i]:=p[i] OD;
>             flips:=1;
>             DO
>                 qq:=q[q1];
>                 IF qq=1 THEN
>                     sum+:=sign*flips;
>                     IF flips>maxflips THEN
>                             maxflips:=flips
>                     FI;
>                     exit1
>                 FI;
>
>                 q[q1]:=q1;
>                 IF q1>=4 THEN
>                     i:=2; j:=q1-1;
>                     WHILE
>                         t:=q[i]; q[i]:=q[j]; q[j]:=t;
>                         i+:=1;
>                         j-:=1;
>                         i<j
>                     DO SKIP OD
>                 FI;
>                 q1:=qq;
>                 flips+:=1
>             OD;
> exit1: SKIP
>         FI;
>
>         IF sign=1 THEN
>             t:=p[2]; p[2]:=p[1]; p[1]:=t;
>             sign:=-1
>         ELSE
>             t:=p[2]; p[2]:=p[3]; p[3]:=t;
>             sign:=1;
>             FOR i FROM 3 TO n DO
>                 sx:=s[i];
>                 IF sx/=1 THEN s[i]:=sx-1; exit2 FI;
>                 IF i=n THEN
>                     res2:=maxflips;
>                     return
>                 FI;
>                 s[i]:=i;
>                 t:=p[1];
>
>                 FOR j TO i DO
>                     p[j]:=p[j+1]
>                 OD;
>
>                 p[i+1]:=t
>             OD;
> exit2: SKIP
>         FI
>     OD;
> return:
>     sum
> END;
>
> INT n=10;
> INT res;
> res:=fannkuch(n);
>
> print(("Fannkuch(",n,") = ",res," ", res2,newline))
> -----------------------------------------------------------------------------------
>
>
> Output should be:
>
> Fannkuch(        +10) =      +73196         +38

$ time a68g --nooptimise fannkuch.a68
Fannkuch( +10) = +73196 +38

real 0m40.654s
user 0m40.644s
sys 0m0.005s
$ $
$ time a68g --optimise fannkuch.a68
Fannkuch( +10) = +73196 +38

real 0m13.150s
user 0m10.383s
sys 0m0.119s
$

--
Charles H. Lindsey ---------At my New Home, still doing my own thing------
Tel: +44 161 488 1845 Web: https://www.clerew.man.ac.uk
Email: chl@clerew.man.ac.uk Snail-mail: Apt 40, SK8 5BF, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

On 30/11/2021 20:45, Charles Lindsey wrote:
> On 29/11/2021 13:33, Bart wrote:
>> On 29/11/2021 12:30, Charles Lindsey wrote:
>>> On 29/11/2021 00:53, Bart wrote:
>>>
>>>>
>>>> Here however are some benchmarks for 'fannkuch(10)':
>>>>
>>>>                     Secs  Lang  Types    Exec
>>>>
>>>>    A68G             50    A68   Static   Interp?   Win or WSL
>>>>    A68G -optimise   --    A68                     (WSL: Failed)
>>>>    qq -asmopt        2.2  Q     Dynamic  Interp   (mildly accelerated)
>>>>    gcc -O3           0.22 C     Static   Native
>>>>    mm -opt           0.22 M     Static   Native

>> Regarding the above benchmark, the A68 code for that is given below.
>>
>> So that I can properly fill in my table, I'd be grateful if you could
>> run this on your machine both with and without -optimise, as that flag
>> doesn't work on my WSL. Then I can estimate the runtime on my machine.
>>
>> (I assume it transpiles to C then runs that C. The errors are within
>> the A68 headers.)

> $ time a68g --nooptimise fannkuch.a68
> Fannkuch(        +10) =      +73196         +38
>
> real    0m40.654s
> user    0m40.644s
> sys    0m0.005s
> $
> $
> $ time a68g --optimise fannkuch.a68
> Fannkuch(        +10) =      +73196         +38
>
> real    0m13.150s
> user    0m10.383s
> sys    0m0.119s
> $
>

Thanks. My table is now:

Secs Lang Types Code

A68G 50 A68 Static Interp? (WSL; Win=52)
A68G -optimise 16 A68 Static ? (Estimated)
CPython 12.3 Python Dynamic (WSL; Win=19)
qq -asmopt 2.2 Q Dynamic Interp
PyPy 0.65 Python Dynamic JIT
LuaJIT 0.45 Lua Dynamic JIT
gcc -O3 0.22 C Static Native
mm -opt 0.22 M Static Native

The A68G timing suggests it is not generating C code for directly
executing the program, but just generating C code that does the
intepretation more efficently.

That's OK, it just means A68G is not a compiler, but it is still
somewhat sluggish given that the language is statically typed.

I've added timings for CPython plus two JIT programs. Although these do
very well, JIT timings tend to be misleading. They're good at small
benchmarks and but not so good at real programs.

Bart <bc@freeuk.com> wrote:
> On 22/11/2021 20:34, Andy Walker wrote:
> > On 21/11/2021 19:45, Bart wrote:
> >> On 21/11/2021 18:55, James Harris wrote:
> >>> In sum, perhaps it would be better to build common operators into
> >>> type libraries and not make them part of the language itself.
> >
> > ????I agree with Charles!
> >
> >> You need a more complicated implementation, and one that implements
> >> more advanced optimisations, which are going to be slower, to get
> >> code of the same standard as you can get easily when things are
> >> built-in.
> >
> > ????Doesn't follow.? The library can have access to parts of the
> > language that are not available to ordinary users, inc [eg] escapes
> > into assembler, inlining, access to the compiler's internal structures,
> > ..., and can be optimised when the compiler is built.
>
> This is my point: you need:
>
> * Inline assemby
> * Inlining
> * User-defined operator overloads
> * The equivalent of C++'s constexpr
> * A gcc-class optimiser
> ...

I use a language like this. You do need inlining and it is useful
only due to overloading (_not_ limited to operators). However,
other position on your list above are not needed. More precisely,
there is small core language which implements basic types and
corresponding operators. Basic library types simply ofer "view"
of basic types and operators from core language. Due to inlining
there is no runtime loss of efficiency compared to using core
language directly. But there are also fancy library types
which are infeasible to have as part of core language.

> Too many advanced compilers features, just to keep the language 'small'.

You did not get it: purpose is to have managable implementation
of _very large_ language. Low-level error prone parts are
small. Library types can be written by ordinary application
programmers.

Overloading can be implemented with quite small extra code.
Inlining is also easy to implement if you have internal
representation of larger code fragments (as opposed to
generating machine code directly after recognizing given
syntactic construct). Both put limits on maximal possible
compiler speed: with overloading you have more complex
symbol table and need more lookups. Intermediate representation
takes time to build (on top of time needed to generate code).
Also, inlining allows large object code from small sources,
so if you measure time per source line compier speed will
likely be worse than speed of compiler that forces you to
write each source line separately. Still, compiler can
be reasonably fast.

Anyway, increase in compiler complexity is relatively
small. Even for small languages in total balance
approach using overloading may give you saving in
effort spent on implementation. Just as a simple
example let me mention Pascal. In Pascal there is
a buch of "builtin" operations (mostly on files).
Most of them are too complex to do by inline code
so practical compilers have runtime library implementing
them. But compiler still needs to parse those
"builtins" and convert them to runtime calls.
In a sense this is trivial task, but with realistic
compiler structure you need several lines of compiler
code to generate corresponding runtime call. Bunch
of older languages like Cobol, Fortran, PL/I had
special "builtin" operations, some of them much
more than Pascal.

Let me add that there are more radical approaches:
there are languages in which "users" can redefine
scanner and/or parser. So users can add on the
fly new operators and define their meaning. As
a possible example consider you 'stringimage'
extention: in extensible language user simply
declares that 'stringimage' is a new keyword that
should invoke its handler. Handler looks at
following program text, extracts filename,
reads the file and tells compiler to use resulting
string as a string constant. The whole thing is
probably 10 lines for handler and a single
line to register new keyword. In language that
allows syntax extentions instead of overloading
you can just define new operators, so overloading
strictly speaking is not necessary. Similarly
you have some way for syntax handlers to generate
code, which is similar to inlining, but stricly
speaking inlining is not needed.

--
Waldek Hebisch

Andy Walker <anw@cuboid.co.uk> wrote:
> work. AFAIK, no language I have ever used expects "A[i;j;k]" to
> be an array element or "F(a;b;c)" to be the call of a function
> with three parameters.

In a language that I use:

(28) -> sin(1;2;3.0)

(28) 0.1411200080_598672221
Type: Float
(29) -> v := new(1, 1)$Vector(Integer)

(29) [1]
Type: Vector(Integer)
(30) -> v(3;2;1)

(30) 1
Type: PositiveInteger

In the first case 3 expressions are computed, but only last one
provided value of resulting compound expression, which in turn
is used as argument to 'sin'. Similarly 'v(3;2;1)' uses last
value as array index.

> Far from clear. Simpler to describe? People mocked the 236
> pages of the RR [most of it comments, examples or the system
> library] when it first came out -- until they found that proper
> descriptions of other languages were at least as long, and
> nowhere near as precise.

I may have already mentioned it: Extended Pascal standard
(ISO 10206) has 230 pages (so almost as long). It describes
rather large language. I found description to be rather
precise: it uses _slightly_ less formal style than Algol
report, but terms are given precise definitions. A little
sample:

: A module A shall be designated as supplying a module B if A
: supplies the module-heading or moduleblock of B. A module A
: shall be designated as supplying a main-program-block if the
: module supplies the block of the main-program-block. A module
: A shall be designated as supplying a module-heading, module-block,
: or block, B, either if B contains an applied occurrence of an
: interface-identifier having a defining occurrence contained by
: the module-heading of A, or if A supplies a module that supplies
: B.
: : No module shall supply its module-heading.

This may be not very friendly to lay persons, in more plain
language it says that while cyclic imports of module bodies
are allowed, cyclic imports of interface parts ('module-heading'
in standarese) are not allowed. To understand it you need
to read introductory part which explains that semantics is
defined on parse tree and grammar rules have labels allowing
unambigous reference to parts of parse tree. In particular
'module-heading' is part of module defined by syntax rules.
Similarly 'applied occurrence' and 'defining occurrence' are
precisly defined earlier.

This is 22 years after Algol 68 report, but at least in
presentation aspect they did _much_ better work than
Algol group. In particular, words and terms they use
actually make sense, so without firm grasp of the whole
standard you can get resonable approximation to meaning
just taking meaning of words from everyday programming
practice. This allows you to read definitions and refine
your understanding of meaning. After few iterations
you converge and get the whole thing. Not so with
Algol 68...

--
Waldek Hebisch

On 04/12/2021 09:32, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:

>> * Inline assemby
>> * Inlining
>> * User-defined operator overloads
>> * The equivalent of C++'s constexpr
>> * A gcc-class optimiser
>> ...
>
> I use a language like this. You do need inlining and it is useful
> only due to overloading (_not_ limited to operators). However,
> other position on your list above are not needed. More precisely,
> there is small core language which implements basic types and
> corresponding operators. Basic library types simply ofer "view"
> of basic types and operators from core language. Due to inlining
> there is no runtime loss of efficiency compared to using core
> language directly. But there are also fancy library types
> which are infeasible to have as part of core language.
>
>> Too many advanced compilers features, just to keep the language 'small'.
>
> You did not get it: purpose is to have managable implementation
> of _very large_ language.

Source code for gcc was 45,000 source files last I looked. I don't even
know if that's just for C, or for C++ too.

That's a thousand times a larger scale than what I do. So I guess I'm in
less need of such methods.

> Low-level error prone parts are
> small. Library types can be written by ordinary application
> programmers.
>
> Overloading can be implemented with quite small extra code.
> Inlining is also easy to implement if you have internal
> representation of larger code fragments (as opposed to
> generating machine code directly after recognizing given
> syntactic construct). Both put limits on maximal possible
> compiler speed: with overloading you have more complex
> symbol table and need more lookups. Intermediate representation
> takes time to build (on top of time needed to generate code).
> Also, inlining allows large object code from small sources,
> so if you measure time per source line compier speed will
> likely be worse than speed of compiler that forces you to
> write each source line separately. Still, compiler can
> be reasonably fast.
>
> Anyway, increase in compiler complexity is relatively
> small. Even for small languages in total balance
> approach using overloading may give you saving in
> effort spent on implementation.

I could do overloading. I have an approach I've developed, I just
haven't got round to it (there are a dozen more things more useful ahead
of it, which I haven't done yet either!).

But, this purely user-defined overloading of existing operators, with
user-defined types, or applying extra operations to standard types.

It is not for implementing the core language, which I like to handle by
dedicated code in the compiler, keeping it tight, fast and allowing such
enhancements as above to be optional (and on a waiting list).

For example, there is already a backend IL instruction, MUL.I64, to do
signed multiply. The main part, MUL, is attached to the binary * op
during parsing. The .I64 part is assigned two passes further on.

With only mechanisms with user-defined overloads, it's a lot harder to
make those associations. For one thing, those IL instructions are not
exposed in the language.

> Just as a simple
> example let me mention Pascal. In Pascal there is
> a buch of "builtin" operations (mostly on files).
> Most of them are too complex to do by inline code
> so practical compilers have runtime library implementing
> them. But compiler still needs to parse those
> "builtins" and convert them to runtime calls.
> In a sense this is trivial task, but with realistic
> compiler structure you need several lines of compiler
> code to generate corresponding runtime call.

I have a similar set of operations for I/O. They are implemented as a
set of function calls, designed to be called implicitly from code, so
have funny names. So:

print a,b

is equivalent to:

m$print_startcon()
m$print_i64_nf(a) # when a,b are i64
m$print_i64_nf(b)
m$print_end

(The bracketing between start/end calls allows separator logic within
the whole print statement; and allows calls to functions within the
print list that might themselves use print, to files etc.)

So, print is already implemented in user code. I just do not see the
advantage of replacing 110 or 50 lines of code within the compiler's
code generator for print, with a likely more complicated solution.

(110 lines of code for static language which needs to generate different
calls for various types; 50 lines for dynamic language.)

> Bunch
> of older languages like Cobol, Fortran, PL/I had
> special "builtin" operations, some of them much
> more than Pascal.
>
> Let me add that there are more radical approaches:
> there are languages in which "users" can redefine
> scanner and/or parser. So users can add on the
> fly new operators and define their meaning. As
> a possible example consider you 'stringimage'
> extention:

Do you mean my 'strinclude' which incorporates a text file (or
text/binary file in dynamic code), as string data within the program?

> in extensible language user simply
> declares that 'stringimage' is a new keyword that
> should invoke its handler.

That itself is not so easy. Keywords are built-in, scopeless, and known
program-wide. With a user-define keyword, could two modules define that
keyword differently? Could another part of the program use that same
name as an ordinary variable?

If so then it's not known as a new keyword after the next pass after
parsing. So it will need to have a suitable 'shape' to be parsed as
/something/. (My language also has out-of-order definitions.)

Handler looks at
> following program text, extracts filename,
> reads the file and tells compiler to use resulting
> string as a string constant.

How? String literals are detected fairly early, they have a certain AST
node, length etc. At what pass will this be done?

> The whole thing is
> probably 10 lines for handler and a single
> line to register new keyword.

In language that
> allows syntax extentions instead of overloading
> you can just define new operators, so overloading
> strictly speaking is not necessary. Similarly
> you have some way for syntax handlers to generate
> code, which is similar to inlining, but stricly
> speaking inlining is not needed.

Do you have an example of such a language where implementing my
'strimport' is 10 lines of code? For example, C++. Or the one you
mentioned. If so, how does it look?

In my static compiler, 'strinclude' needs a handful of lines to define
enums and names, this these two lines in the parser:

when kstrincludesym then
lex()
p:=createunit1(j_strinclude,readterm2())

Followed by this code later on to create a suitable string literal:

proc tx_strinclude(unit p,a)=
int fileno

tpass(a)
if a.tag<>j_const or not a.isastring then
txerror("strincl/not string")
fi

fileno := moduletable[p.moduleno].fileno
fileno := getfile(a.svalue, path:sourcefilepaths[fileno],
issupport:1)

a.svalue := sourcefiletext[fileno]
a.slength := sourcefilesizes[fileno]

deleteunit(p,a) # replace strincl node with new string
end

The fiddly bit is deciding where to look for that file (unless an
absolute path is given, it will be relative to this module).

The file involved counts as a support file, which means that when an
application is combined into an amalgamated file, such files are
included. (But need to be marked because sometimes, a support file will
have the same name as an actual source module.)

Also, when reading from an amalgamated file, it will look inside that
for the support file.

I think that 20 lines of code for 'strinclude' inside a compiler is
reasonable.

On 01/12/2021 00:07, Bart wrote:
[various benchmark timings:]
> The A68G timing suggests it is not generating C code for directly
> executing the program, but just generating C code that does the
> intepretation more efficently.

AIUI, A68G doesn't "generate C code" at all, unless you go
down the "--optimise" route [in which case you might do better with
an actual compiler, such as "algol68toc" or Charles's "a68s"], but
builds a tree and then "walks" it, doing a /lot/ of checking as it
goes.

Anyway, this got me looking at the supplied "fannkuch"
program, which looks as though it's imported from some other
language, as the Algol is very unidiomatic. Simply tidying
the code speeds it up by around 10%. I saved a further ~15%
by replacing "sign" by a Boolean, replacing explicit array
elements by declaring and using "ref int"s to point to them
and similar, copying arrays in toto rather than element by
element, and so on. That got the time down from just under
40s to just under 30s. I didn't touch the actual algorithm.
Testing also uncovered a buglet; the [original] code fails
if "n < 3"; easy enough to correct, but Algol makes it easier
to spot in the first place.

This got me testing different versions of A68G, as
some of them have the garbage-collection bug that causes
repeated array copying to fill up store, necessitating a
"sweep heap" from time to time. The results weren't quite
what I expected. Fastest was not the current A68G [2.8.4],
but 1.16 [the most recent Mk 1 on my computer, April 2009],
which clocked 21s. Other versions of Mk 1 are mostly a
little slower than 2.8.4, though a couple are a little faster.
Slowest of all was 2.0.3, which weighed in at 64s [Bart's
original at 88s]. The timings seem to bear little relation
to the changelog, so I have no explanation for either the
factor 3 in speed between 1.16 and 2.0.3, nor the factor 2
improvement since then. We'd have to ask Marcel!

I haven't noticed such changes in my own programs,
and suspect that the "instruction mix" in "fannkuch" is
completely different from the norm [eg, only a couple of
procedure calls, almost no actual calculation yet tens of
millions of array accesses, ...]. If I can work up the
enthusiasm [unlikely!], I might try running the Whetstone
benchmark through the different versions.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Heller

On 04/12/2021 21:38, Andy Walker wrote:
> On 01/12/2021 00:07, Bart wrote:
> [various benchmark timings:]
>> The A68G timing suggests it is not generating C code for directly
>> executing the program, but just generating C code that does the
>> intepretation more efficently.
>
>     AIUI, A68G doesn't "generate C code" at all, unless you go
> down the "--optimise" route

That's what --optimise does, but I assumed it was generating direct C code.

> [in which case you might do better with
> an actual compiler, such as "algol68toc"

I tried to run that but it's a 16-bit executable that no long runs under
Win64.

or Charles's "a68s"], but
> builds a tree and then "walks" it, doing a /lot/ of checking as it
> goes.
>
>     Anyway, this got me looking at the supplied "fannkuch"
> program, which looks as though it's imported from some other
> language, as the Algol is very unidiomatic.  Simply tidying
> the code speeds it up by around 10%.  I saved a further ~15%
> by replacing "sign" by a Boolean, replacing explicit array
> elements by declaring and using "ref int"s to point to them
> and similar, copying arrays in toto rather than element by
> element, and so on.  That got the time down from just under
> 40s to just under 30s.  I didn't touch the actual algorithm.

All my fannkuch versions are derived from an original in Lua.

I'm using it as a benchmark for testing compilers (with up to 10,000
copies in one file).

Partly for that reason, they need to comprise largely the same code.

The actual performance is less important, but it is useful for comparing
the results of trade-offs between compilers and compile options. So
again, they need to execute the same algorithm.

On 05/12/2021 12:22, Bart wrote:
[I wrote:]
>> ... [in which case you might do better with
>> an actual compiler, such as "algol68toc"
> I tried to run that but it's a 16-bit executable that no long runs
> under Win64.

Ah, unlucky. If you're that interested, perhaps you need
to download the source and build a 64-bit executable.

[...]
> All my fannkuch versions are derived from an original in Lua.
> I'm using it as a benchmark for testing compilers [...].
> Partly for that reason, they need to comprise largely the same code.

Well, that's a rather grey area. Is "a := b" largely
the same code as "for i to n do a[i] := b[i] od"? The former
is simply not possible in many languages, but it [or a standard
"copyarray" procedure] is likely to be implemented significantly
more efficiently than the loop [without sufficiently aggressive
optimisation]. Similarly, for the use of a built-in Boolean
type vs an integer to be tested for sign. Similarly, when there
are issues of "return;" vs "run off the end of the procedure"
or of "loop and a half" constructs. As noted in my PP, simply
tidying the "fannkuch" code into idiomatic Algol saved around
25% of the time [without changing the underlying algorithm].
No doubt if you started with some Algol and translated that
directly into C or Lua, you would find that you could save a
similar amount by switching some of the resulting ugly C/Lua
into more idiomatic code.

[Similarly, and relevant to a nearby thread, the
difference between 0-based and 1-based arrays is more than
is often supposed. It affects which comparison operator you
use, and whether you pre- or post-increment or decrement, and
then you find yourself pulling the code around to suit.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bull

On 07/12/2021 16:52, Andy Walker wrote:
> On 05/12/2021 12:22, Bart wrote:
> [I wrote:]
>>> ... [in which case you might do better with
>>> an actual compiler, such as "algol68toc"
>> I tried to run that but it's a 16-bit executable that no long runs
>> under Win64.
>
>     Ah, unlucky.  If you're that interested, perhaps you need
> to download the source and build a 64-bit executable.
>

You could also try Wine on Linux if it is a Windows 3.x program, or
DOSBox if it is a DOS program.

You could even use VirtualBox and start a FreeDOS virtual machine, and
enjoy the nostalgia :-)

(I'm not guaranteeing these will work, but they might be worth a shot.)

On 2021-12-07 18:41, David Brown wrote:

> You could even use VirtualBox and start a FreeDOS virtual machine, and
> enjoy the nostalgia :-)

I managed to run Windows 98 in VirtualBox. It requires special drivers
for the display, though.

Firefox 2.0.0.20 is such a fun. Comparing to the latest versions it is
blindingly fast. OK, it does not show most of the pages, but should I
visit them anyway? (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 15:52, Andy Walker wrote:
> On 05/12/2021 12:22, Bart wrote:
> [I wrote:]
>>> ... [in which case you might do better with
>>> an actual compiler, such as "algol68toc"
>> I tried to run that but it's a 16-bit executable that no long runs
>> under Win64.
>
>     Ah, unlucky.  If you're that interested, perhaps you need
> to download the source and build a 64-bit executable.
>
> [...]
>> All my fannkuch versions are derived from an original in Lua.
>> I'm using it as a benchmark for testing compilers [...].
>> Partly for that reason, they need to comprise largely the same code.
>
>     Well, that's a rather grey area.  Is "a := b" largely
> the same code as "for i to n do a[i] := b[i] od"?

I would allow that, if the copying is by value (making a distinct copy
not sharing), which is what the element-by-element does, except there is
no array assignment in the program, only of a slice, which is little
more advanced.

The original benchmark site allowed any mix of algorithms provided they
still gave the same results, although blatant cheating (just printing a
string with the expected results) would be forbidden.

So if you wanted to compare implementations, you were out of luck.

(A reminder that my own tests were to do with compilation, which needed
a substantial source file.)

>  The former
> is simply not possible in many languages, but it [or a standard
> "copyarray" procedure] is likely to be implemented significantly
> more efficiently than the loop [without sufficiently aggressive
> optimisation].  Similarly, for the use of a built-in Boolean
> type vs an integer to be tested for sign.  Similarly, when there
> are issues of "return;" vs "run off the end of the procedure"
> or of "loop and a half" constructs.  As noted in my PP, simply
> tidying the "fannkuch" code into idiomatic Algol saved around
> 25% of the time [without changing the underlying algorithm].
> No doubt if you started with some Algol and translated that
> directly into C or Lua, you would find that you could save a
> similar amount by switching some of the resulting ugly C/Lua
> into more idiomatic code.

Yes, these are useful tweaks, but there's such a huge gap between A68G
and the next language, that the basic problem still exists: it is slow!

The only comparable language I have installed is Seed7, also statically
typed, also usually interpreted. That one takes 44 seconds for this
task, compared with 52 seconds for A68G (on Windows; it's a bit faster
on WSL).

However Seed7 also has a transpiler to C, one that works and works
transparently to produce a .exe file. Then the runtime reduces to 0.7
seconds, which is more like it.

(Note that the fastest implementation is still 3 times faster than this.)

A68 really needs someone to produce an equivalent transpiler, an update
of that algol68toc program.

(If I liked it more, and understood it a LOT more, then I'd have a go
myself.)

>     [Similarly, and relevant to a nearby thread, the
> difference between 0-based and 1-based arrays is more than
> is often supposed.  It affects which comparison operator you
> use, and whether you pre- or post-increment or decrement, and
> then you find yourself pulling the code around to suit.]

Yes, the original algorithm was 1-based, and all versions I made are
1-based even when the language was 0-based (by allocating an extra
element and ignoring element 0).

I would expect an optimising compiler to iron out such minor differences.

On 24/11/2021 18:19, Bart wrote:
> On 24/11/2021 00:04, Andy Walker wrote:

>>      If you're going to have these things, you need them anyway.
>> There is no clear-cut boundary between what compilers do and what
>> goes into a standard library.  It doesn't matter whether it's the
>> compiler that decides that "A + B" turns into "load A, load B, add"
>> or the library that decides that.
>
> It matters very much. My static language is self-hosted, and can build
> itself entirely from source fast enough that I could do so ten times
> every second if I was so inclined.
>
> To me that is important; not that I need to do that 600 times a minute,
> but it means an effectively zero edit-build-run cycle for similar-sized
> applications.
>
> That would be harder to achieve using the wrong language choices; it
> would also take longer, and the result would build apps more slowly.

A discussion on Reddit happened to mention that someone's 20Kloc C++
language project shouldn't take more than '5 minutes' on a modern
machine using -O3.

Why so slow? Apparently it was all to do with templates.

Someone else mentioned a 25Kloc compiler taking 5 minutes, with 8
cores/16 threads.

And now someone had a 100Kloc project using a Sun C++ compiler than took
*16 hours* to build.

Effective compile-speeds of 65lps, 80 lps (with 8 cores!) and ... 1.7
lines per second.

When I said the wrong language design choices could slow things down, I
didn't even know it could be by that much.

I think I'm happy with my own choices at the minute (a 40Kloc project
takes 0.1 seconds on one core).

On 08/12/2021 00:01, Bart wrote:
> Yes, these are useful tweaks, but there's such a huge gap between
> A68G and the next language, that the basic problem still exists: it
> is slow!

Yes, it's an interpreter. But not as slow as you claim,
even for this very artificial test, as long as the code is written
[or transcribed from Lua/C/whatever] by someone familiar with
Algol [without changing the underlying algorithm, before you ask].
In other tests, it benchmarks on my [ancient] PC at around 200x
faster than the ICL 1906A [comparable with the fastest mainframes
around in the mid-'70s] by the Whetstone benchmark -- a decent
approximation to useful scientific computing -- even without the
optimiser. That's plenty fast enough for all the real computing
I do, where development time is much more important than the few
extra seconds needed for live runs [esp interactive ones, where
the real bottleneck is my typing]. I'm not [these days -- I used
to do a lot of benchmarking in the last century!] as obsessed by
speed as some people.

Meanwhile, my I suggest a little test for you? Instead
of "fannkuch(10)", please get your collection of programs and
compilers to produce "fannkuch(2)". Any compilers that return
"2, 2" [without comment and from code equivalent to what you
supplied] should be kept well away from any serious computation.

[...]
> A68 really needs someone to produce an equivalent transpiler, an
> update of that algol68toc program.
> (If I liked it more, and understood it a LOT more, then I'd have a go
> myself.)

Both A68G and "algol68toc" are available as source, so the
hard work is already done. But if you don't understand them, you're
not well placed either to edit that source or to complain about the
[perceived] deficiencies thereof.

[...]
> Yes, the original algorithm was 1-based, and all versions I made are
> 1-based even when the language was 0-based (by allocating an extra
> element and ignoring element 0).
> I would expect an optimising compiler to iron out such minor
> differences.

I suspect you're being optimistic if you expect even a good
optimiser to detect that [in a reasonably large and complicated
program] element 0 is never accessed, or systemically to reduce all
indexes by 1. But you never know. Small differences in code
accumulate as dozens of programming decisions are taken on the
basis of where arrays start and finish.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Handel

On 08/12/2021 21:40, Andy Walker wrote:
> On 08/12/2021 00:01, Bart wrote:
>> Yes, these are useful tweaks, but there's such a huge gap between
>> A68G and the next language, that the basic problem still exists: it
>> is slow!

>     Meanwhile, my I suggest a little test for you?  Instead
> of "fannkuch(10)", please get your collection of programs and
> compilers to produce "fannkuch(2)".  Any compilers that return
> "2, 2" [without comment and from code equivalent to what you
> supplied] should be kept well away from any serious computation.

What should it produce for fannkuch(2)?

I downloaded versions in 4 languages from the original benchmarks site.

Three of them (Lua, Python, Julia) go wrong in giving a program error.

The fourth, in C, completes, but fannkuch(2) returns -1. I don't know if
that is correct or not, but it sounds like it might be undefined.

The presence of these lines:

swap(p[2],p[3])
signx:=1
for i:=3 to n do

plus perm1[2] in the 0-based Python, and p[3] in Julia, suggests n needs
to be at least 3.

>> I would expect an optimising compiler to iron out such minor
>> differences.
>
>     I suspect you're being optimistic if you expect even a good
> optimiser to detect that [in a reasonably large and complicated
> program] element 0 is never accessed, or systemically to reduce all
> indexes by 1.  But you never know.

Element 0 can stay there; it's not doing any harm with just 3 arrays.

Being 1-based may simply mean an extra offset on some address modes; is
that what you think is causing a slow-down? With local arrays, that
offset should just be absorbed into the stack offset of the array.

On 2021-12-08 22:29, Bart wrote:

> Why so slow? Apparently it was all to do with templates.

Likely, GCC is very poor with them. But your language has nothing to
express polymorphism in either form. So are not in position to criticize.

> When I said the wrong language design choices could slow things down, I
> didn't even know it could be by that much.

Yes, a modern medium-sized project is extremely large. In a language
without polymorphism it would take years to design and the code would be
tenfold bigger and complex.

> I think I'm happy with my own choices at the minute (a 40Kloc project
> takes 0.1 seconds on one core).

It is a false equivalence. You simply cannot write equivalent code of
same size.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 09/12/2021 08:46, Dmitry A. Kazakov wrote:
> On 2021-12-08 22:29, Bart wrote:
>
>> Why so slow? Apparently it was all to do with templates.
>
> Likely, GCC is very poor with them. But your language has nothing to
> express polymorphism in either form. So are not in position to criticize.
>

In general, gcc is fast at compiling templates. But there is always
scope for improvement, and gcc has definitely been getting better there
in recent versions. (More importantly, it has also been getting better
at error messages from heavily templated code.)

But with templates, there is no limit to the complexity you can have.
Indeed, templates can be seen as a Turing-complete programming language
at compile-time. (Individual compilers, of course, have limits to
tempate recursion depth and the like, usually as tunable parameters for
people doing weird stuff.)

Improvements and enhancements to C++ have been added to combat this,
including constexpr and consteval functions to get compile-time
evaluation without inefficient complicated recursive template
meta-programming, and concepts to make requirements clearer, error
messages more useful and template compilation faster. Then there are
modules which can hugely improve compilation of large template libraries.

None of the new features limits the use of templates, however - they
just offer alternatives. So it is quite easy to make code that might
/look/ like 20 Kloc, but is effectively compiling millions of lines.
(To get the same results, the alternative in statically compiled
languages that don't have templates would, of course, be macros,
pre-processors, generators, or manual coding also resulting in millions
of lines.)

Then there is the issue of optimisation. Asking for -O3 is telling the
compiler to try /really/ hard to look for optimisation opportunities,
and not to worry about the time or ram usage in doing so.
Inter-procedural optimisations scale approximately quadratically with
the number of functions in a compilation unit. Some others scale even
worse in the size of functions, and use of templates can allow a lot of
inlining and therefore very big functions. (There are legitimate
use-cases for huge functions, and work in progress in gcc for handling
them better.)

All these things can add up to faster results, but obviously there are
diminishing returns for the effort. It is rare that it makes sense to
use -O3 rather than -O2. Think of it like using liquid nitrogen to cool
your cpu rather than water - is the extra 10% overclocking really worth
it? Most people would usually only do a massively templated -O3 compile
for testing, benchmarking or bragging rights, not because they tried -O2
and measured that the resulting binaries are too slow for their needs.

>> When I said the wrong language design choices could slow things down,
>> I didn't even know it could be by that much.
>
> Yes, a modern medium-sized project is extremely large. In a language
> without polymorphism it would take years to design and the code would be
> tenfold bigger and complex.

Exactly. Developer time is more important than computer time.

>
>> I think I'm happy with my own choices at the minute (a 40Kloc project
>> takes 0.1 seconds on one core).
>
> It is a false equivalence. You simply cannot write equivalent code of
> same size.
>

Indeed.

You could also look at these example and be impressed with how much
functionality you can get from a mere 20 Kloc of code with C++, where
the same useful work in C or BOL (Bart's Own Language) might take 50
times as much.

Statistically speaking, based on real studies, error rates in software
are proportional to the number of lines of code, and relatively
independent of the language used. A language that lets you write fewer
lines of code because you can make more general code and libraries or
re-use more existing (tested) code for other sources, will let you write
code with fewer errors - all other things being equal.

(This is, of course, a big reason why languages like Python are popular.)

On 09/12/2021 07:46, Dmitry A. Kazakov wrote:
> On 2021-12-08 22:29, Bart wrote:
>
>> Why so slow? Apparently it was all to do with templates.
>
> Likely, GCC is very poor with them. But your language has nothing to
> express polymorphism in either form. So are not in position to criticize.

I expect my dynamic language can do polymorphism. That would would
between 1 and 2 magnitudes slower, but it would still be 1-2 magnitudes
faster than that C++ compiler!

But is it really that necessary inside a compiler?

>> When I said the wrong language design choices could slow things down,
>> I didn't even know it could be by that much.
>
> Yes, a modern medium-sized project is extremely large. In a language
> without polymorphism it would take years to design and the code would be
> tenfold bigger and complex.

If I did such a project (say 100-1000Kloc) I would probably use dynamic
scripting code for most of it.

Since most code is not speed-critical. Especially when you just want a
test run.

>> I think I'm happy with my own choices at the minute (a 40Kloc project
>> takes 0.1 seconds on one core).
>
> It is a false equivalence. You simply cannot write equivalent code of
> same size.

We don't know what are the capabilities of the language in question for
which that compiler, written in C++, took so long to build.

You need ask a different question: do you really expect a compiler for
any kind of language, which is only 20-25,000 lines of user-code, to
take MINUTES to build on today's machines? (And on multiple cores!)
Somebody is doing something wrong.

Yes, the C++ compiler could also be more inefficient than need be, but
people can only use the C++ compilers that exist.

On 09/12/2021 08:28, David Brown wrote:
> On 09/12/2021 08:46, Dmitry A. Kazakov wrote:

>> Yes, a modern medium-sized project is extremely large. In a language
>> without polymorphism it would take years to design and the code would be
>> tenfold bigger and complex.
>
> Exactly. Developer time is more important than computer time.

Exactly. That is why having developers twiddle their thumbs for five
minutes every time they compile is a joke.

>> It is a false equivalence. You simply cannot write equivalent code of
>> same size.
>>
>
> Indeed.
>
> You could also look at these example and be impressed with how much
> functionality you can get from a mere 20 Kloc of code with C++, where
> the same useful work in C or BOL (Bart's Own Language) might take 50
> times as much.

> (This is, of course, a big reason why languages like Python are popular.)

Scripting languages have all the benefits of C++ and then some. Except
for execution speed.

But the C++ in these examples is so slow to build, that a scripting
language is likely to be faster.

On 2021-12-09 11:50, Bart wrote:
> On 09/12/2021 07:46, Dmitry A. Kazakov wrote:
>> On 2021-12-08 22:29, Bart wrote:
>>
>>> Why so slow? Apparently it was all to do with templates.
>>
>> Likely, GCC is very poor with them. But your language has nothing to
>> express polymorphism in either form. So are not in position to criticize.
>
> I expect my dynamic language can do polymorphism.

I expect it does not, because...

> But is it really that necessary inside a compiler?

you obviously do not understand it.

> If I did such a project (say 100-1000Kloc) I would probably use dynamic
> scripting code for most of it.

Again a failure to see actual challenges of medium to large software
collaboration projects.

> Since most code is not speed-critical. Especially when you just want a
> test run.

Yep, a test run of a production line automation system, a banking
system, a luggage delivery system written in BOL, would love to see it,
from a safe distance of course...

> You need ask a different question: do you really expect a compiler for
> any kind of language, which is only 20-25,000 lines of user-code, to
> take MINUTES to build on today's machines? (And on multiple cores!)
> Somebody is doing something wrong.

Yes, lack of experience/education on modern language-assisted software
design.

> Yes, the C++ compiler could also be more inefficient than need be, but
> people can only use the C++ compilers that exist.

C++ has a lot of problems, but not lack of understanding and
anticipating software developing issues. At least they tried and have
achieved far more than many.

On your part we see an active denial of very existence of such problems.
Things you see important are just silly from the point of view of a
practicing software developer. Things you reject are key tools for
managing complexity of modern software.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 09/12/2021 12:01, Bart wrote:
> On 09/12/2021 08:28, David Brown wrote:
>> On 09/12/2021 08:46, Dmitry A. Kazakov wrote:
>
>>> Yes, a modern medium-sized project is extremely large. In a language
>>> without polymorphism it would take years to design and the code would be
>>> tenfold bigger and complex.
>>
>> Exactly.  Developer time is more important than computer time.
>
> Exactly. That is why having developers twiddle their thumbs for five
> minutes every time they compile is a joke.

When the alternative is spending weeks or months writing the code by
hand rather than using templates?

>
>>> It is a false equivalence. You simply cannot write equivalent code of
>>> same size.
>>>
>>
>> Indeed.
>>
>> You could also look at these example and be impressed with how much
>> functionality you can get from a mere 20 Kloc of code with C++, where
>> the same useful work in C or BOL (Bart's Own Language) might take 50
>> times as much.
>
>> (This is, of course, a big reason why languages like Python are popular.)
>
> Scripting languages have all the benefits of C++ and then some. Except
> for execution speed.
>

Spoken like someone who does not know C++, or have any concept of
scripting languages. Or someone who /does/ know, but is trolling.

There are different languages with different balances of features and
emphasises, and that's good. But you'd have to be completely ignorant
to think that there are any scripting languages with /all/ the benefits
of C++ (or to think that C++ has /all/ the benefits of all scripting
languages).

> But the C++ in these examples is so slow to build, that a scripting
> language is likely to be faster.
>

That would seem highly unlikely. Even if such a compile time was
realistic (and it rarely is - these examples are rather special cases),
a scripting language is only going to be faster for short and simple
scripts, or scripts only used occasionally.

But since we know nothing about the C++ examples other than that someone
managed to make a compilation that took a long time, it is fairly
pointless to speculate what alternatives could have been better.

On 09/12/2021 12:00, Dmitry A. Kazakov wrote:
> On 2021-12-09 11:50, Bart wrote:
>> On 09/12/2021 07:46, Dmitry A. Kazakov wrote:
>>> On 2021-12-08 22:29, Bart wrote:
>>>
>>>> Why so slow? Apparently it was all to do with templates.
>>>
>>> Likely, GCC is very poor with them. But your language has nothing to
>>> express polymorphism in either form. So are not in position to
>>> criticize.
>>
>> I expect my dynamic language can do polymorphism.
>
> I expect it does not, because...

Get me an example of polymorphism, as there seem to be various kinds,
and I'll see if I can express that in my language.

>> But is it really that necessary inside a compiler?
>
> you obviously do not understand it.

I understand /my/ compilers and they're obviously not suffering from any
lack of whatever you think they're lacking.

>> If I did such a project (say 100-1000Kloc) I would probably use
>> dynamic scripting code for most of it.
>
> Again a failure to see actual challenges of medium to large software
> collaboration projects.

I haven't done commercial apps for a long time. But when I did:

* I wrote the core application with 75% of modules written as script
code, about 150Kloc total
* OEM developers created add-on functionality via my scripting language
* End users also had the ability to customise and automate via macros,
command-line scripts and that same scripting language

Yes, this is a fairly small project with few collaborators.

But, on top of all the various issues involved in bigger projects, you
don't want build times to be unnecessarily slow for no good reason.

For that, you need someone whose job it is to oversee that part, to
identify such problems, and to do something to fix it if possible.

What you don't want is for someone like you to just shrug their
shoulders and say, Well, what do you expect? It is what it is.

>> Since most code is not speed-critical. Especially when you just want a
>> test run.
>
> Yep, a test run of a production line automation system, a banking
> system,

Python is used extensively in banking. Python is a scripting language.

> a luggage delivery system written in BOL, would love to see it,
> from a safe distance of course...

Actually some airport baggage handling installations were designed with
the help of my CAD application.

(Whether they used the script language to help, I don't know.)

>> You need ask a different question: do you really expect a compiler for
>> any kind of language, which is only 20-25,000 lines of user-code, to
>> take MINUTES to build on today's machines? (And on multiple cores!)
>> Somebody is doing something wrong.
>
> Yes, lack of experience/education on modern language-assisted software
> design.

My first two examples were from people /implementing their own languages/.

> On your part we see an active denial of very existence of such problems.
> Things you see important are just silly from the point of view of a
> practicing software developer. Things you reject are key tools for
> managing complexity of modern software.

OK. Carry on waiting 5 minutes between each run. Hopefully it will be
for a more worthwhile reason than over-eager, inappropriate use of
templates.

Or, for that 100Kloc Sun program, wait 16 hours to build it. Because it
is perfectly reasonable to compile at 1.7 lines per second.

It's really no skin off my nose.