TorqueScript has suboptimal performance

#1 continuing the conversation here for torquescript these are the current problems that I've seen and others have been over as well:

Cache Misses (like crazy)
over reliance on adhoc data conversions to and from string

call frame management and the frame allocator... there was a post on the forums about this one and I can't seem to find it anymore, but when I get the link back out of my bookmarks, I'll add it here for reference to this.

EDIT: AHA Found it.. ;)
www.garagegames.com/community/resource/view/18045/


general memory management - or lack of a good memory strategy

I'm not bashing on anything here, as I've chosen the engine for a reason, so, obviously I see merit to it. Though, in my local version it couldn't be further from the current state of t3d at this point because of some of the changes I've made to my own codebase. I would much rather contribute some of this where I can, but I chose the LLVM route and I'm not sure others really want that kind of system, but for me it's worked amazingly. It's the EASIEST way I've ever written any form of compiler, EVER and it keeps the code very understandable and manageable, which for a compiler is a FEAT to say the least.


@Eric
I don't think Marmalade used LLVM initially. Most of their code was a framework set of C++ classes forming their framework base, and just running the platform compiler from there linking where needed. Didn't spend much time with it specifically myself, but gave it a once over for a project I was on.

#2 Would LLVM rule out Android and iPhone?

#3 LLVM wouldn't be ruled out for iphone because it's the compiler apple is pushing to be it's #1, so it's based on that stack (LLVM/Clang). GCC is optional, and there is also an LLVM-GCC front-end as well..

For android or any ARM device the only thing we would be missing is JIT (Just in time) features, but LLVM would still be able to function.. We would just miss some of the realtime optimizations for JIT.. but the standard pass optimizations that could be put into the compiler would still function. Since using LLVM Means we would have our own front end anyway, it's up to us, but there is already a generic LLVM-ARM makefile and cmake setup for this for android specifically. Not having JIT features on android is one of those "big whoop" things to me anyway but until ARM actually gets JIT capabilities in a more standard way or on a broader install base we just don't use JIT features on android or any ARM device.

I suggested LLVM Because it's easy to use and extend, it's cross platform on windows, Mac OSX and Linux even iphone and android.

#4 I think you are over-engineering the solution here. All TorqueScript really needs is:

* No variable name lookups for local variables
* Optimized allocation for globals (none for local variables)
* Slightly saner type conversions
* Native types instead of strings for native console function callbacks
* Simplified numeric type

Those things alone would reduce execution overheads to more saner levels.

LLVM sure is great, but if you are doing that you might as well just save time and use another dynamic language from the start since it's going to be a complete rewrite anyway.

#5 I know what torquescript IS at the moment, and it's not meant as an attempt to over engineer anything. I'm just saying if we are going to look at something like V8 or Lua We might as well KEEP TS and just fix that whole layer in the engine anyway. Using LLVM Would allows us to make other language front ends for the vm in a sane way. Would allow to abstract the torquescript portions out of the engine, so the basic core of T3D would worry about C++ and not TS anywhere. This alone would speed up the engine let alone clean up the codebase. We bind T3D to the VM exposing specific functionality and anything you put into your LLVM for a language on the front end would be able to operate against those bindings natively as well as be bound the same way without any work on your end to do it. You just worry about the intermediate assembly language which you ALREADY have that worry right now because T3D has it's own intermediate assembly language for TS anyway. Just found a way to kill 3 or 4 birds with one stone a while ago and thought I'd share.

#6 DotNetTorque is being submitted to GG this week or beginning of next week for approval. If you have any questions as to what it is or does, look up the blog posts from Vince Gee.

For a quick overview, it allows the users to use either TS if they perfer or to program everything in any .NET language. We are using this to write all of our tools and the code behind the MMO that we are creating and we have gotten tremendous performance gains by using this.

#7 I have been working with DNT beta for a while now and I can agree that it is definitely very powerful. The fact that I can simply make Torque a rendering engine increases the performance exponentially. There are already products being created for it that will extend the functionality to a point that will exceed standard Torques capability.

#8 The discussion is from a thread started about improving TS. It has led to discussions about what to do about TS and should it be optimized or replaced. This is about improving the basic tech in T3D that will be included with the engine and released with the engine under MIT. Anything proposed as a potential solution should be able to be released under the MIT license and/or has a license that is compatible. Eric Preisz already mentioned that there are issues even with LGPL so keep that in mind as well.

It is an overall consensus that TS needs to change. It is to what that we are discussing.
Overview:

1. Optimize TS
2. Replace TS
3. Improve the API for external language bindings.
4. Somewhere in between or a combination.

#9 @smally,
I think you need to show us step by step how LLVM will work in your scenario. I don't know enough about LLVM to even understand where you are coming from. I thought it was just a JIT library. Apparently I don't understand it very well. Also, I do not understand where GCC comes into this.

#10 ah! teaches me not to go back and read outta the thread!

well then, good luck w that guys.

#11 @Paul,
Don't worry about it. If you read back far enough you will see I did plug you guys as a near term solution. You know, for the people who want to make a game in this decade. Your code IS a good solution addressing a lot of these issues. Also, the interface part could help improve your code integration so you may want to pay closer attention.

#12 @Frank
Ive pointed this out to Vince. It seemed like an interesting read although im not 100% sure what he had in mind for DNTv3.

#13 The trampoline needs some attention. The biggest problem with the trampoline is that it creates externs (or entry points) which require T3D objects versus Int's or strings for simobjects, strings for transforms etc.

I've been messing around inside the trampoline to try and add this functionality, but it usually ends up with me deleting the directory and taking my brain to the dry cleaners......

Vince

#14 @smally just offering my opinion. I'm just saying unless you already have an implementation which works and maintains full compatibility it might be overkill. If you already have an implementation that's great, it would be neat to see.

Also personally i'm more interested in making TorqueScript faster without adding too much complication.

The engineAPI itself goes a long way to allow for native enumeration and callbacks for engine objects. I think in this area a lot of the work has already been done, it just needs to be put to good use. Right now you could probably rip out the interpreter and still have a functional engine interface pretty easily.

@vince from what I gathered the trampoline stuff is just a helper to expose the function parameter information and provide a binding for the legacy console stuff. e.g. I was able to bind functions from external code without touching it. Unless you are binding to the engine functions some other way...?

#15 @James,

For example, when a function expects a player object pointer, how did you get the pointer from the outside function w/out going though some hoopla?

#16 @James, I actually agree. I'm all for helping out where we can.

@Frank
You just include the LLVM api as a library just like you would zlib or libjpeg or libpng. You create your own flow of how you want things to work. Your software would then get LLVM's intermediate assembly as a target. You can then either execute that in a VM, directly, or take it from there and retarget directly to x86 code, arm code or whatever wish. This gives you a framework to do with as you wish.

It was just a suggestion. I'm good with just optimizing TS but a good cleanup of the engine and unbinding TS from the engine directly would help T3D a lot.

My thoughts on this were that you have to account for these things:
the language AST / definition and syntax,
it's internal assembly/binary code and optimizations of that code,
memory management,
internal engine objects and linkages to the engine itself

It is a bear.

I'll take my codebase and rip the LLVM portion out of it, and port it to the MIT codebase as a proof of concept. I have to do this anyway, since I'm interested in the new path as well.

I didn't want this to be a lecture on the good of LLVM as I'm actually not an advocate specifically of it or .net

I just had good success with it, and removing all the cruft associated with TS and the engine's current way of binding to it made a massive impact. I still had TS in the final version, so I didn't loose it at all. It was just reimplemented.

#17 @vince

I made a GIST detailing my efforts in understanding the best use for the engineAPI. It's currently internal but there's nothing there which can't be done externally from the exe for example. I've not tried creating Player objects yet so maybe i'll fall flat on my face later. :( https://gist.github.com/3780691

The API could do with more useful functions of course. For example after a quick search I can't seem to see a method for finding SimObjects by name or id or even to find the root SimGroup, so at the moment one appears to be largely limited to creating stuff in a separate island.

#18 Most of the stuff I have done has been to use the cinterface code as an example. I ended up creating my own wrappers to the code that cinterface calls and made those available to an external VM. Maybe if I get my head around the engineAPI I can contribute to the discussion.

#19 @smally,
I would love to see that. Seeing the code would help me understand a lot better than I do now.

@all,
What I don't understand is what happens to the callbacks to TS from the game objects (onAdd,onRemove,etc) and what happens to the object creation code that creates a SimObject using the console and then accesses a global console variable to get the ID of the object? Will it be straightforward to convert those calls to calls into a new VM? What happens if there is no VM to call? No SimObjects would get created.

#20 @James
one problem with anything like cinterface and the engineApi is that if there is no way to create certain objects in the environment as the program is running, those fall flat.

@Frank

I wouldn't get rid of the VM, ever actually. It's too useful to throw away.

One thing to note is that with so many newcomers wanting to make games, script languages get their use and are definitely put through their paces. The original point of TS wasn't to code an entire game in it, not 100%. It's not geared for that. It's geared for glue code where need be. If the game starts to take a hit on performance because of too much script the idea used to be to convert the code eating the most performance and move on.

Times change and with that requirements change. Though I would still urge that it's kept in mind to switch over non performing script.