From: janis_papanagnou+ng@hotmail.com   
      
   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. - 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. And let me add that you usually don't   
   do that regularly but typically maybe only once or twice a year. Even   
   your imaginary "5 minutes" would be okay for that.   
      
   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).   
      
   I know your goals are space and speed. And that's fine in principle   
   (unless you're ignoring other relevant factors).   
      
   >>> [...]   
   >   
   > A68G is poor on this benchmark. Other interpreted solutions are faster.   
   >   
   > It is disappointing after taking all that effort to build.   
      
   Why do you care? You're anyway using your own languages, don't you?   
   And others do what fit their needs.   
      
   >   
   >   
   >> So you're again advertising your personal language and tools. - I'm not   
   >> interested in non-standard language (or Windows-) tools, as you've been   
   >> told so many times (also by others).   
   >   
   > Here's an example not related to my stuff:   
   >   
   >   c:\cx>tim tcc lua.c   
   >   Time: 0.120   
   >   
   > This builds the Lua intepreter in 1/8th of a second. Now, Tiny C   
   > generally produces indifferent code (ie. slow). Still, I get this result   
   > from my benchmark:   
   >   
   >    Lua 5.4         0.65        (lua.exe built using Tiny C)   
   >   
   > It's still at least FIVE TIMES FASTER than A68G!   
      
   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.)   
      
   >   
   >   
   >> 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.   
      
   If you'd take a minimum time to think about that we could spare a lot   
   of posts.   
      
   >   
   > But if you're happy with the performance of your tools, then that's fine.   
      
   Generally that depends.   
      
   If execution performance of a binary is crucial (and critical with   
   a safer language) I'd switch to something else, like C++, or "C".   
      
   Janis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)