AGS Development > Engine Development

Why isn't AGS script much, much faster?

(1/6) > >>

Monsieur OUXX:
Context:
AGS has no problem working with high-resolution games : With hardware acceleration it can display lots of sprites and tint them, etc. The engine is also performant enough for scripting effects when you stick to built-in operations (native sprite scaling, native transparency, etc.).

But AGS becomes slower when you want to make the AGS script handle more intensive algorithms, such as iterating on large arrays of hundreds of thousands of items, or trying to perform per-pixel operations on larger sprites, or when your function calls stack exceeds a certain depth.

This is why when it comes to scripting, especially special effects, AGS is better suited for low-resolution games : 320x200 or 640x480. And that's also why advanced shaders written with the AGS scripting language are out of the question.


I sometimes ask myself why that is. What are the reasons why the AGS scripting language is not lightning fast?

Having very little knowledge of the engine's code, I can't seem to come up with a reason :
- It uses SDL, which is very close to the hardware. If not the fastest possible option, it's pretty close.
- It's written in C/C++
- The virtual machine is running pre-compiled code, literally just byte code.

So, what is slow in all this? Is it that the VM's instructions are not mapped directly to the underlying CPU instructions? Is it that the engine uses simple data structures with a lot of overhead and lookups? Etc.

Crimson Wizard:
Slow in what exactly? Rendering, running script, else? In which circumstances? Separate components will have separate reasons for being slow. Separate game objects will have separate reasons for being slow too (for instance, GUIs update was very unoptimized until 3.5.1).


--- Quote from: Monsieur OUXX on 21 Sep 2021, 12:50 ---Is it that the VM's instructions are not mapped directly to the underlying CPU instructions?

--- End quote ---

AGS script is slower than many other scripting languages, because it's compiled to generally inefficient bytecode; it emulates x86 asm, but have many repeating operations that are redundant in a scripting language. I wrote a post about this many years ago: https://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0

Additionally, the changes made to the opensourced version made it even slower, for few reasons, primarily making it run on 64-bit machines and backward compatibility.
In regards to 64-bit systems, AGS script was unfortunately designed to store real memory addresses in the bytecode, which is 32-bit, therefore current engine works around that by storing them differently, and that made it slower.
There could've been other way to resolve these problems, but we never had a chance to address these again.

eri0o:
Modern CPUs use a lot of advanced techniques to be efficient. I think the code for the script runner and other functions just doesn't use these newer CPU features well.

Generally the code is not written to prevent cache misses - enforce a predictable code path, the CPU drawing/bitmap code doesn't make use of SIMD instructions (allegro4 is before this was a thing...), and object references could be direct but they use a hashmap/btree instead, ... All of these things are not easy to change and also keep compatibility and portability. But these are the main things I kinda noticed... I have made occasional experiences but overall I find the existing performance is alright for my needs so the work required to change is just too much for me to care. Overall, I find it's better to favor portability and flexibility instead of performance.

Monsieur OUXX:
I'm mostly talking about the script language being slow. It's a bit suicidal to iterate a lot on some data in AGS, or implementing processing that does a lot of function calls.  Both the stack and data access are rather slow.
Again, it's enough for a 320x200 game, but I'm only just wondering why it's not going at the speed of light.


--- Quote from: eri0o on 21 Sep 2021, 21:28 ---object references could be direct but they use a hashmap/btree

--- End quote ---
Ouch.


--- Quote ---AGS script is slower than many other scripting languages, because it's compiled to generally inefficient bytecode; it emulates x86 asm, but have many repeating operations that are redundant in a scripting language. I wrote a post about this many years ago: https://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0

--- End quote ---
Interesting read. Thanks!

Crimson Wizard:

--- Quote from: Monsieur OUXX on 22 Sep 2021, 12:12 ---
--- Quote from: eri0o on 21 Sep 2021, 21:28 ---object references could be direct but they use a hashmap/btree

--- End quote ---
Ouch.

--- End quote ---

I do not know if eri0o is refering to what I may suspect he's refering to, but if it's about accessing managed objects in script, primary access operations are done through flat array; hashmap is only used for the backward lookup (object pointer to managed handle) and that is done in limited cases (like disposing an object).
Of course hashmap or btree may be somewhat slower than accessing objects directly, but there has to be an actual research to find out if that is the cause of slowdown, and how much does it slow down anything in relative terms.
There's much more going on there when working with managed objects.

Navigation

[0] Message Index

[#] Next page

Go to full version