TorqueScript VM question...
by Stephen Nichols · in Torque Game Builder · 03/20/2009 (9:53 am) · 4 replies
As stated in another thread, I've been looking at the TorqueScript internals to help understand performance implications of various code.
This brings me to the opcode OP_SETCUROBJECT. From my limited perspective, it seems that this opcode is used to set the current object for use by other opcodes like OP_LOADFIELD_STR.
OP_SETCUROBJECT seems to do a Sim::findObject each time it executes. This seems undesirable in repeated assignments. Consider this:
Does this end up generating multiple OP_SETCUROBJECT opcodes to load %this? I'd expect there to be a quick local variable access method to avoid the repeated lookups.
On further thought, it seems unlikely that OP_SETCUROBJECT is used to access local variables at all (because Sim::findObject seems to need a name and local variable objects are unnamed). Although, it seems that an override of Sim::findObject also takes an object ID... so I could be full of crap on that.
Ultimately, here's my question:
Which of these two code blocks generates "faster" TorqueScript bytecode:
My common sense tells me that storing the evaluation of "%this.Object" into a local variable would be faster in cases where you're using it more than once. Is that right?
steve
This brings me to the opcode OP_SETCUROBJECT. From my limited perspective, it seems that this opcode is used to set the current object for use by other opcodes like OP_LOADFIELD_STR.
OP_SETCUROBJECT seems to do a Sim::findObject each time it executes. This seems undesirable in repeated assignments. Consider this:
%this.Foo = "Test"; %this.Bar = 100; %this.Cat = "Dog";
Does this end up generating multiple OP_SETCUROBJECT opcodes to load %this? I'd expect there to be a quick local variable access method to avoid the repeated lookups.
On further thought, it seems unlikely that OP_SETCUROBJECT is used to access local variables at all (because Sim::findObject seems to need a name and local variable objects are unnamed). Although, it seems that an override of Sim::findObject also takes an object ID... so I could be full of crap on that.
Ultimately, here's my question:
Which of these two code blocks generates "faster" TorqueScript bytecode:
%this.Object.Variable = value; %this.Object.VariableA = value; ...or
%temp = %this.Object; %temp.Variable = value; %temp.VariableA = value; ...
My common sense tells me that storing the evaluation of "%this.Object" into a local variable would be faster in cases where you're using it more than once. Is that right?
steve
#2
Thanks for the compliment. :)
I've been making games professionally for about 17 years now. So, if I'm focusing on something then it's because I believe it may be an issue in the future.
I'm currently working on a prototype for a 2D MMO game. This will make about the fifth MMO game I've worked on. I'm getting old, no doubt. lol In this game, we're gonna have lots of entities running about.
I'd like to use TorqueScript to manage most of the game logic as it's more accessible to the game designers I'm working with -- and allows the programmers to focus on other heavier lifting needed to be done in the engine.
The issue of how efficient accessing fields and methods is important to me because it's one of the main things done by script code. If I can avoid costly Sim::findObjects calls by removing indirection then that's a win!
Surely, we could wait until the project is closer to complete and then optimize such things... but my experience tells me this isn't so. Making a set of reaonable "best practices" up front is far cheaper than rewriting tons of script to fix things in the future. Far more likely is that working code will be left alone in the fear that changes will break the game.
In any case, it's my hope that someone more knowledgeable with the TorqueScript VM will be able to give some guidance on this point. If not, then I'll need to spend a few hours to deeply understand the fundamentals of the VM.
Anyone? :)
steve
03/20/2009 (3:20 pm)
Joe:Thanks for the compliment. :)
I've been making games professionally for about 17 years now. So, if I'm focusing on something then it's because I believe it may be an issue in the future.
I'm currently working on a prototype for a 2D MMO game. This will make about the fifth MMO game I've worked on. I'm getting old, no doubt. lol In this game, we're gonna have lots of entities running about.
I'd like to use TorqueScript to manage most of the game logic as it's more accessible to the game designers I'm working with -- and allows the programmers to focus on other heavier lifting needed to be done in the engine.
The issue of how efficient accessing fields and methods is important to me because it's one of the main things done by script code. If I can avoid costly Sim::findObjects calls by removing indirection then that's a win!
Surely, we could wait until the project is closer to complete and then optimize such things... but my experience tells me this isn't so. Making a set of reaonable "best practices" up front is far cheaper than rewriting tons of script to fix things in the future. Far more likely is that working code will be left alone in the fear that changes will break the game.
In any case, it's my hope that someone more knowledgeable with the TorqueScript VM will be able to give some guidance on this point. If not, then I'll need to spend a few hours to deeply understand the fundamentals of the VM.
Anyone? :)
steve
#3
but if you're thinking of investing some time in making the scripting performant, have you considered bolting another script language altogether ? JavaScript has seen an awful lot of optimization lately, and continues to get performance attention. ActionScript as well is really fast these days. the demo that really made me raise my eyebrows w/r/t the performance of AS is this page which demonstrates simple line & polygon rasterization written in AS itself. it smokes. and as i understand things, AS3 and JavaScript share the same VM. okay, </offtopic>
03/20/2009 (3:29 pm)
hey Stephen, not to dwell on off-topic stuff,but if you're thinking of investing some time in making the scripting performant, have you considered bolting another script language altogether ? JavaScript has seen an awful lot of optimization lately, and continues to get performance attention. ActionScript as well is really fast these days. the demo that really made me raise my eyebrows w/r/t the performance of AS is this page which demonstrates simple line & polygon rasterization written in AS itself. it smokes. and as i understand things, AS3 and JavaScript share the same VM. okay, </offtopic>
#4
I haven't really considered that as a viable option because we'd have to integrate the new compiler / interpreter / debugger into the Torque codebase and workflow. Torsion is a great option and the level of support and code behind TorqueScript is large. I'm not interested in reinventing the wheel here...
I'm more interested in understanding the performance characteristics of the TorqueScript VM so that I can advise my teammates on how to write fast script. :)
steve
03/20/2009 (3:40 pm)
Orion:I haven't really considered that as a viable option because we'd have to integrate the new compiler / interpreter / debugger into the Torque codebase and workflow. Torsion is a great option and the level of support and code behind TorqueScript is large. I'm not interested in reinventing the wheel here...
I'm more interested in understanding the performance characteristics of the TorqueScript VM so that I can advise my teammates on how to write fast script. :)
steve
Torque Owner Joe Rossi
Indri Games