From: bc@freeuk.com   
      
   On 27/10/2025 13:39, Janis Papanagnou wrote:   
   > On 27.10.2025 13:50, bart wrote:   
   >> On 27/10/2025 02:08, Janis Papanagnou wrote:   
   >>> On 26.10.2025 12:26, bart wrote:   
   >>   
   > [...]   
   >>   
   >>>> Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark:   
   >>>>   
   >>>>      a68g fann.a68  5 seconds   
   >>>>      ./fann       3+3 seconds (via a68g --compile -O3 fann.a68)   
   >>>>   
   >>>> I then tried it under my scripting language (not statically typed):   
   >>>>   
   >>>>      qq fann  0.4 seconds (qq built with my non-optimising compiler)   
   >>>   
   >>> Your 'qq' is an Algol 68 implementation?   
   >>   
   >>> (If not then you're comparing apples to oranges!)   
   >>   
   >> You've never, ever seen benchmarks comparing one language implementation   
   >> with another?   
   >   
   > First of all, in communication with you here in Usenet I've seen you   
   > constantly switching goal posts. - Here again.   
   >   
   >>   
   >> 'qq' implements a pure interpreter for a dynamically typed language.   
   >   
   > (Obviously completely useless to me.)   
   >   
   >>   
   >> Algol68 is statically typed, which ought to give it the edge. It can be   
   >> interpreted (the 5s figure) or compiled to native code (the 3s figure,   
   >> and it takes 3s to compile this 60-line program), which here makes   
   >> little difference.   
   >>   
   >> So for all that trouble, A68G's performance is indifferent. If you don't   
   >> care for my language, then here some other timings:   
   >>   
   >>     A68G -O3/comp   6    seconds   (3s to compile + 3s runtime)   
   >>     A68G            5   
   >>     CPython 3.14:   1.2   
   >>     Lua 5.4         0.65   
   >>     qq              0.4   
   >>     (qq/opt         0.3        Optimised via C transpilation and gcc-O2)   
   >>     PyPy 3.8:       0.2   
   >>     LuaJIT:         0.12   
   >>   
   >> The 0.2/0.12 timings are from JIT-accelerated versions.   
   >   
   > You are again switching goal posts. Here even twice; once for comparing   
   > a68g compile times of some program, and second for comparing arbitrary   
   > other languages.   
      
   Have a look at, for example:   
      
   https://benchmarksgame-team.pages.debian.net/benchmarksgame/perf   
   rmance/fannkuchredux.html   
      
   I guess you would call that all a waste of time. To me, it is useful,   
   but flawed, since different implementations are allowed.   
      
      
   >- The topic of the sub-thread was my correction of   
   > your misinformation was how long it takes to create a complete Genie   
   > runtime from scratch; 45 seconds.   
      
   I gave you actual measurements from my machine.   
      
   > Speed is not an end in itself. It must be valued in comparison with   
   > all the other often more relevant factors (that you seem to completely   
   > miss, even when explained to you).   
   Speed seems to be important enough that huge efforts have gone into   
   creating the best optimising compilers over decades.   
      
   Fantastically complex products like LLVM exist, which take 100 times   
   longer to compile code than a naive compiler, in order to eke out the   
   last bit of performance.   
      
   Similarly, massive investment has gone into making dynamic languages   
   fast, like the state-of-the-art products used in running JavaScript, or   
   the numerous JIT approaches used to accelerate languages like Python and   
   Ruby.   
      
   Build-speed is taken seriously enough, and most 'serious' compilers are   
   slow enough, that complex build systems exist, which use dependencies in   
   order to avoid compilation as much as possible.   
      
   Or failing that, by parallelising builds across multiple cores, possibly   
   even across distributed machines.   
      
   So, fortunately some people take this stuff more seriously than you do.   
      
   I am also involved in this field, and my experimental work takes the   
   approach of simplicity to achieve results.   
      
      
   >   
   > I know your goals are space and speed. And that's fine in principle   
   > (unless you're ignoring other relevant factors).   
      
   LLVM is a backend project which is massively bigger, more complex and   
   slower (in build speed) than my stuff, by a number of magnitudes in each   
   case.   
      
   The resulting code however, might only be a fraction of a magnitude   
   faster (for example the 0.3 vs 0.4 timings above, achieved via gcc, but   
   LLVM would be similar).   
      
   And that's if you apply the optimiser, which I would only use for   
   production builds, or for benchmarking. Otherwise its code is just as   
   poor as mine, or worse, but it still takes longer to build stuff!   
      
   For me the trade-offs of a big, cumbersome product don't work. I like my   
   near-zero builds and can work more spontaneously!   
      
   >> It's still at least FIVE TIMES FASTER than A68G! [2-3 TIMES FASTER]   
   >   
   > So what? - I don't need a Lua system. So why should I care.   
   >   
   > You are the one who seems to think that the speed factor is the most   
   > important factor to choose a language for a project. - You are wrong   
   > for the general case. (But it may be right for your personal universe,   
   > of course.)   
      
   You are wrong. What language do you use most? Let's say it is C   
   (although you usually post about every other language except C!).   
      
   Then, suppose your C compiler was written in Python rather than C++ or   
   whatever and run under CPython. What you think would happen to your   
   build-times?   
      
   Now imagine further if the CPython interpreter was inself written and   
   executed with CPython.   
      
   So, the 'speed' of a language (ie. of its typical implementation, which   
   also depends on the language design) does matter.   
      
   If speed wasn't an issue then we'd all be using easy dynamic languages   
   for productivity. In reality those easy languages are far too slow in   
   most cases.   
      
      
      
   >   
   >>   
   >>   
   >>> The tools I'm using for my personal purposes, and those that I had been   
   >>> using for professional purposes, all served the necessary requirements.   
   >>> Your's don't.   
   >>   
   >> I'm just showing just how astonishingly fast modern hardware can be.   
   >> Like at least a thousand times faster than a 1970s mainframe, and yet   
   >> people are still waiting on compilers!   
   >   
   > You've been explained before many times already by many people that   
   > differences in compile time may not beat other more relevant factors.   
      
   I've also explained that I work by very freqent edit-run cycles. Then   
   compile-times matter. This is why many like to use scripting languages   
   as those don't have a discernible build step.   
      
   But I can use my system language, *or* C via my compiler, just like a   
   scripting language.   
      
   You will find now various projects that apply JIT-techniques to such   
   languages in an effort to provide a similar experience. (I don't need   
   such techniques as my AOT compilers already work near-instantly.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)