Small Basic super slow ??

[litdev]

Apart from Small Basic that is VERY slow, I wouldn't worry about speed when choose a language - look at portability, maintaiinability, available libraries, the architecture it is run on and other aspects.  Hand crafted machine code will usually be fastest, but totally unreadable and only used in very special instances within a library.  All modern language libraries are well optimised by experts - so always use them, hence choose a language that has the libraries that you want.

This is a link on speed https://benchmarksgame-team.pages.debian...redux.html

The comments at the top are critical.

Always look at the source code.
(Lumpers and Splitters.)
Some of these programs are single-thread and some are multi-thread: compare "secs" and "cpu secs". Some of these programs are un-optimised and some are heavily optimised: sort-by "gz" source code size.
Some of these programs are "naked ffi" and some put that in a library. Some of these programs are high-level and some are hand-written vector instructions.
Always look at the source code

[Elzaimer]

Hello,

Today I tried QB64.
After learning QB64 a bit, I converted my "Conway's Game of Life" that I programmed in SB a few times ago (XXMZ135.000).

To make 500 generations with a 50x50 grid :
- small Basic : 227 sec
- QB64 : 1.1 sec 

This is a hudge difference !?

[litdev]

Yes it is, SB is slow especially arrays and even more so 2D arrays.  There are LD alternatives for arrays, but SB is slow for the reasons described and comparisons with 'normal' typed languages with indexed arrays are somewhat pointless.  

SB arrays are Primitive indexed and valued maps which are often recursively internally converted to a string representation and back, stuff like A[X]=Y is converted to A="X=Y;" - try printing the values of your 2D arrays to see what this looks like for them.  I am explaining why it is slow - it is so that it can have the simplistic features it has originally designed for total programming beginners as an alternative to things like Scratch.

But... with care, it can do good things and certainly train good programming habits - however if speed is the primary objective, then ANY 'normal' language will be more appropriate, even something like Python which is widely used but very slow compared to native C (super fast compared to SB) but has fantastic libraries not written in Python is speed is important.

[AbsoluteBeginner]

...
- small Basic : 227 sec
- QB64 : 1.1 sec 

This is a hudge difference !?

(translated by Google translator)

Hello, Elzaimer 

Yes, it is a huge difference.
But starting to learn programming using Small Basic is many times easier than using QB64.
The "Aliases" that can be used in SB-Prime allow a person to write code using THEIR NATIVE LANGUAGE (!!!).
The value of this ability is far greater than any difference in performance.
Many people on the planet are forced to make their choice: either they program EASILY and slowly, or they do NOT program at all.

There are many fast and complex programming languages.
But Small Basic, enhanced by the advantages of the SB-Prime editor and extensions - people have only one!

Glory to this Small Basic and its creators!!!

Hooray!.. 

[litdev]

This version (XXMZ135.000-0) uses LDFastArray - which is still not an optimal container with overheads.

On my PC using 50x50 and 10% initial fill, your original model takes about 106s, the modification above is about 55s, and if I comment out AffichageTableau then it takes about 12s.  Still very slow compared to a native program that doesn't have the inherent overheads of SB, but we start to learn where the performance can be gained.  Would we have learned this if we just accepted the run time of 1s - maybe I could write some carefully optimised GPU code and do it in 1ms, or with fancy GPU 1us.

PS - My basic code in C++ runs in about 12 ms for the same 50*50 , 10% case using your algorithm with no parallelisation or special vectorisations (also no visualisation), which is maybe comparable to the QB64 that I believe converts the source to C++ source and compiles that.

In the C++ parallelisation overheads don't help for such a small problem, if I do a 1000x1000 10% for 500 steps with and without parallelisation on my PC it is 0.5s and 4.2sec.

[z-s]

Yeah this all happened because of Microsoft if it never leaved this fantastic Lang in between the way this would never happened because I guess 4 or 5 employees at ms can make this Lang to cpp or c or cpp cli based(cpp in .Net) but they only cares about money and nothing else...
If in my life I learned c or cpp I will definitely try to port this Lang to c or cpp so that kids can make super fast high level programs with simple basic syntax even we can create graphics window by using qt or sdl and text window with console.

---

This is a link on speed https://benchmarksgame-team.pages.debian...redux.html

Litdev
The article shows CSharp at second. 
Is CSharp's native ahead of time compilation faster than cpp

[litdev]

Its not really that one language is faster than another - its how they are coded (look at their code) and what libraries they use.  Really what this article says is speed depends on how you white stuff, not what language you use.  Someone spent a lot of effort to write those bits of code to solve a very specific propblem.  Generally all compiled languages making use of good libraries will be similar speed, but with hard work any of them can be made faster for specific task, even C# wich does use JIT IL which is now extremely well optimised.  Interpreted languages will generally be slower, stuff like Python, but it has a fantastic set of libraries.

SB does stand alone as very slow, but it is a learning language - having said that if we compare it with other 'introductory languages initially targetted at children like Scratch' it is fantastically powerful, fast and the skills learned are way more relevant.  Ultimately though, if you want speed then move to almost any other language with suitable libraries for the architecture you want to run it on.

In most cases on modern PCs speed is irrelevant.  For complex 3D games you have to write code with the GPU - there are very good libraries, but for the very best performance you would write your own taylored to specifics of your game which is very time consuming specialised work that is expensive.  For weather forcasting you need enormous memory and massive parallelisation and massive amounts of money.  To tease the most performance it is often about contiguous memory access and pipelining commands and data efficiently to the processors - optimisers are pretty good at this, but an expert will do better.

Do NOT choose a language because someone says it's fast, choose it because it is best for the task, which may simply be you are experienced using it.  For you and me the biggest difference is not the language, but the algorithm and how it is coded which is one reason SB is fun - it forces you to work hard at making it efficient.  So in many cases SB is 'best' because it's slow it's fun!

To make SB faster we would have to move away from single type (Primitive) and impose variable types on beginners, all extensions written would not work, its not really about MS not supporting it - sure they could fix the bugs, but we get round most of them.  SB users who crave better performance should look at taking their SB programming skills and playing with perhaps C# - the Graduation or other decompiling methods help, but they decompile to .Net VB/C# using the Primitive type and SmallBasicLibrary.dll, which when compiled in C# will be no faster than the original SB.  I think the best approach is to decompile SmallBasicLibrary.dll and start to see how it does things, maybe write their own extension as a starting point just as you and I have done.  There are also loads of getting started stuff out there, including CoPilot or similar.

[litdev]

And a way to massively speed up the visualisation in Game of Life.

Code:

Sub AffichageTableau          ' displays current Gen grid  (av 550ms with grid 80)
  GraphicsWindow.Title = tailletableau + "x" + tailletableau + "  Génération = " + n
  GraphicsWindow.brushColor = "White"
  GraphicsWindow.FillRectangle(0,0,GraphicsWindow.Width,GraphicsWindow.Height)
  GraphicsWindow.brushColor = "Green"
  For x = 1 To tailletableau
    For y = 1 To tailletableau
      'If tableau[x][y] = 1 then
      If LDFastArray.Get2D(tableau,x,y) = 1 Then
        GraphicsWindow.FillRectangle(x*taillecase,y*taillecase,taillecase,taillecase)
      EndIf
    EndFor
  EndFor
EndSub

[Elzaimer]

okay,
Thanks a lot for all these explanations !
I will look for the way to install the LD lib

[litdev]

I did wander off topic a bit using extension when this was in the Standard Small Basic section.

To summarise - LDFastArray helps with the slowness of SB Arrays that are indexed by integers, but the code optimisation suggestion in post 18 is applicable to the original code as well (i.e. only draw the Green alive squares, not all the dead White ones).

PS

I had some fun optimising this and with carefull thought and use of LD extension methods I have it down to a couple of seconds with graphics on my PC for the 50x50 10% 500 steps case, DKJX394.000-0.

The code is harder to follow, uses extension methods and more memory (but these 3 are often the tradeoffs for speed).