Complexity and speed

[ErosOlmi]

After every new release of thinBasic programming language I stop for a while (2/3 days) to work on thinBasic and work on some other projects, especially work projects. But after that I restart working on thinBasic and usually, every time, I find myself thinking about: how to make thinBasic faster?

I think thinBasic is already quite fast also considering it has no intermediate byte code. But execution speed is never enough so my first thought (when I restart programming at the next version) is speed.

As far as we go on using thinBasic, scripts complexity is increasing. If at first we used thinBasic to create just few lines script and have fun, we are now using thinBasic to make big loops (images or 3D worlds handling), big data handling (we use at work to automate DB tasks an data conversions). In general I see a trend in having scripts more complex than it was before. At the end, more complexity means more code to be executed or the same code executed much more times. All this needs speed and a faster thinBasic Core engine.

I do not want to transform thinBasic into a compiler to have more speed, this mainly for 2 reasons:
I do not have enough capacity, in terms of knowledge and time, to develop a compiler. While I could study more to cover my compiler ignorance, I cannot buy more time at the shop ;)
I love the freedom an interpreted language leave to the programmers and the easy to develop new features and user requests/suggestions.

Back to speed. After version 1.7.7.0 I was checking where, during a script execution, thinBasic was loosing time and I have discovered that most of the execution time is lost during script function execution. And what surprised me was that time is not lost during function code execution but during initial function setup and release. So, in few words, time is mainly lost in allocating memory to adjust variables (local stack used to store local variables and function parameters) and when function execution ends its life (time to take to de-allocate the just created local stack).

What thinBasic Core is doing in the initial and final stage of a script function execution is quite complex and involves the creation of many dynamic structures all connected by pointer in many nested levels. I was thinking on how to avoid all those many allocations every time a function is executed considering that the first time a function is executed I have all the pieces of the puzzle so I could think of a way to do such a time consuming steps only the very first time a function is executed. At the end, instead of releasing all the memory I need to reset used memory.
The biggest problem I can think about is when a user function is executed recursively. In this case I need to allocate further local stack levels for every recursive function execution and release them at the end.

I already started to work on this strategical change and I have to say that initial results are very very promising: around 80% execution speed improvement but I didn’t apply all the optimizations I have in mind.
But I also have a lot of GPF to fix :D Honestly I expected those GPF because this change touch many lines of code and complex memory structures. So my next “week thinBasic time” will be dedicated to this.

Ciao
Eros

[Michael Hartlef]

Interesting thing that you will work on. That means we will have a lot of testing to do.

One time you told me that TB allways interprets the source of the script during runtime. Will your changes mean also that you will first generate a byte code and then execute that?

[ErosOlmi]

No I will not change on this point because it is already fast enough.
But I could change idea on this point ;)

[peter]

Hi Eros,

such things as ' more speed' are fair and beautiful thoughts.
The speed was slower in the last version.
The Emeralds Game had more elements as that puzzle game.
It had a good speed for so a difficult game.
But this puzzle game was much slower than this Emeralds Game !
That was annoying because i had to kill much ideas which i would
to have in my puzzle game.

[Michael Hartlef]

Hi Eros,

such things as ' more speed' are fair and beautiful thoughts.
The speed was slower in the last version.
The Emeralds Game had more elements as that puzzle game.
It had a good speed for so a difficult game.
But this puzzle game was much slower than this Emeralds Game !
That was annoying because i had to kill much ideas which i would
to have in my puzzle game.



Can anyone, who doesn't run thinBasic on a virtual machine like I do, run our famous benchmark tests with the last releases? Peter keeps saying that thinBasic got slower, so much that he notices it. As he doesn't show any code and as he said, uses his own game engine and interfacing with external DLL's, I would like to know if his words are not just his personal oppinion.

[ErosOlmi]

Well,

user feelings are always important for me. Of course feelings can be a result of many different reasons: real language problems, some specific areas not optimized, programming techniques used, algorithms used, ...

This post was about optimization but optimization in one specific area: memory allocation in script functions.
We cannot see petr code so we cannot give any exact suggestions if some areas of his code can be optimized.
We saw in the past that scripts that at first were running very slowly with some suggestions and tricks they got incredible boost. I remember a horizontal scrolling initial game that moved from 40~50 FPS to 700 FPS after help and suggestions of many users here in forum.

Anyhow, Peter gave us an indication if I do not remember wrongly: he said he is using API functions so it means he is interfacing a lot with external libs using DECLARE statements. Honestly that area is not much optimized because parameters passing if firstly calculated and moved into internal structures. Than from that structures they are passed to external functions. So a lot of operations that can be optimized.

Ciao
Eros

[MouseTrap]

Hi,
This is a very interesting topic. forgive me if my responses are bit naive. i've never written an interpretrer.
Is there opportunities for sacrifice script startup time in favor an increase in execution performance?

you say you don't tokenize the script for execution. But what about after execution? Is there anything learned during the first pass that can be retained?
If a pre-parser stage could scan the script and identify any userfunctions
that don't have conditionals(If/Else/etc), could that userfunction be turned into a heap of fixed memory operations after its first execution?
In that way, your 'kind of' tokenizing a userfunction after its first interpretation.

time is mainly lost in allocating memory to adjust variables (local stack used to store local variables and function parameters) and when function execution ends its life (time to take to de-allocate the just created local stack).
Is it possible to scan user functions at script startup just for the purpose of pre-allocating this space? This wouldn't help in the situation recursion though.

If the user has O2H/Oxygen available, that can make a big improvement. Most user functions where speed is critical can be done in O2H.
Its difficult to get an understanding of how much currently TB and O2H can communicate (share data), but for me, This would deal with any performance concerns I had. You have a flexiable and dynamic scripting language(TB) Combined with a fast Jit with a limited basic syntax to be used as needed. IMO, the combination of those 2 things would be great.

[ErosOlmi]

MouseTrap, you are quite right here. There is no negativity at all in your post!

Those who followed thinBasic development can testify how we improved speed in all thinBasic versions.
thinBasic is more that 5 times faster than other similar interpreters (AutoIt for example). So we do not have to forget that we already start from a good speed base. But we do not stands here looking, we want more. And here we are with this post.

In reality thinBasic could not have the speed it has if only continuous parsing would take place.
Some (well, many) optimizations takes place under the curtains. A double parsing pass is already in place, in fact you can declare your functions wherever you prefer in your script and thinBasic will be able to find them. Functions are already parsed and parameters stored during the first pass. Tokens are already identified and classified again during the first pass.

What I mentioned in my first post of this thread is that now we are moving into an optimization phase (we had many in the past) and we will work specifically in something we discovered: local function stack allocation and de-allocation.

As soon as I will have something usable to test I will post new intermediate thinBasic versions.

Ciao
Eros

[peter]

I think , it was no good idea to write about thinBasic speed.
That was really my opinion therefor.
You are right eros, i am using The API partially, but also " CORE" and
"FILE" And "TBGL".
In the future , i will not write more about thinBasic Speed or about its behaviour !
When a thing can be negative, then is it not good to write about it.
Sorry.

[ErosOlmi]

Why Peter? I can only talk for myself but your post was not negative for me.
I 100% prefer honesty if expressed politely like you did rather than silence.

And to be honest ;) I was the first to talk about speed problems creating this post.
So, please, tell us your feelings even if they are negative. Be sure I will check all indications and do my best to give all of you a best thinBasic I can.
Better would be to extract some part of your games, maybe the one you think there is a bottle neck in execution and I'm sure we can give some indications or advice on how to improve execution speed or meaybe I can check Core for that specific part and find possible solutions. Up to you.

Ciao
Eros

[Michael Hartlef]

Eros, you always say Petr, but it is Peter :)

Peter, I have no problem with you describing what is a problem for you. As I didn't experience this slowdown I just asked for help. Everyone is free to say what is on their mind. Nobody says that thinBasic is perfect. It is a damn good language and I never saw so much development on a freeware product than thinBasic. I'm totally happy with but that doesn't mean that everyone is.

Please be constructive and also if you see a problem, try to show a little script that can help to to trace the problem and then the developers can improve thinBasic. You are as welcome as anyone else here.

Michael

[Petr Schreiber]

Eros,

thank you very much for look inside to current TB developement, I really appreciate your optimizing efforts, they always brought big jumps forward.

When I will have more time I will try to install first ThinBasic released and compare its speed to current, I guess the improvement will be in hundreds of percents.

Peter - I am TBGL optimization maniac, if you can reveal at least part of your code, I will be very happy to help you optimize.


Petr

[ErosOlmi]

Eros, you always say Petr, but it is Peter :)


oops, sorry Peter :oops: