Different technology options for OXPs?
Moderators: winston, another_commander
Different technology options for OXPs?
Scripting languages have very many obvious benefits: rapid prototyping, no "compile - edit - run" cycle, generally higher level with many convenient builtins (garbage collecting) than C/C++.
But they have a major problem for use in an interactive highly compute sensitive environment: they're SLOW.
Has anybody given thought to how to optimize OXPs? Maybe implement a true loadable DLL interface as well as a scripting interface?
Maybe (much longer term) the prolific OXP authors could note the sort of things they do over and over again in their OXPs and over time the common code could be factored out into the compiled core of oolite and made available to OXP writers to script, but then the meat of the code would run at native speeds....?
But they have a major problem for use in an interactive highly compute sensitive environment: they're SLOW.
Has anybody given thought to how to optimize OXPs? Maybe implement a true loadable DLL interface as well as a scripting interface?
Maybe (much longer term) the prolific OXP authors could note the sort of things they do over and over again in their OXPs and over time the common code could be factored out into the compiled core of oolite and made available to OXP writers to script, but then the meat of the code would run at native speeds....?
-
- Quite Grand Sub-Admiral
- Posts: 6683
- Joined: Wed Feb 28, 2007 7:54 am
In my opinion, JavaScript is quite good in speed terms for what we are using it in Oolite. Much faster than the legacy system, at least. Making the scripting interface a loadable DLL is an idea, but it has two drawbacks that I can immediately think of:
1) It would require a major rewrite of the existing scripting code base. Just when we have managed to establish a flexible and stable scripting system, we would have to start all over again. One would ask "why not design it like this from the beginning?". Which brings me to the second drawback.:
2) This solution cuts down on portability. DLL loading is fine with Windows, but what about Linux and Mac? One of the principal goals of Oolite is to have a common codebase to build for all supported architectures, with as little platform-specific code as possible. Going the way you suggest would probably mean that we would need different code for handling the shared library containing the scripting system, depending on what architecture we run on. And then, if another port comes out in the future, new code would have to be written for it as well. Not very good in terms of maintainable code, I think.
1) It would require a major rewrite of the existing scripting code base. Just when we have managed to establish a flexible and stable scripting system, we would have to start all over again. One would ask "why not design it like this from the beginning?". Which brings me to the second drawback.:
2) This solution cuts down on portability. DLL loading is fine with Windows, but what about Linux and Mac? One of the principal goals of Oolite is to have a common codebase to build for all supported architectures, with as little platform-specific code as possible. Going the way you suggest would probably mean that we would need different code for handling the shared library containing the scripting system, depending on what architecture we run on. And then, if another port comes out in the future, new code would have to be written for it as well. Not very good in terms of maintainable code, I think.
Yeah I forgot about multi platform, I only have intel pcs . So forget DLLs.
But perhaps there is an opportunity for refactoring. JavaScript should not be used in general for very performance or memory intensive tasks. If there are such tasks being used in OXPs repeatedly, maybe that's a good sign that the (portable) core should implement the functionality (with caching so that when one OXPs asks for the data, it's generated only if invalid, then all other OXPs don't pay the cost of generating the data while the data is still valid), and then OXP authors who want better performance could recode to the new, faster interface.
Then again maybe all the performance problems I see are really related to known issues in 1.71.2 and the OXP performance is OK.... but I can forsee that with many OXPs loaded simultaneously, each one wanting to check certain information, that could make things slow.
But perhaps there is an opportunity for refactoring. JavaScript should not be used in general for very performance or memory intensive tasks. If there are such tasks being used in OXPs repeatedly, maybe that's a good sign that the (portable) core should implement the functionality (with caching so that when one OXPs asks for the data, it's generated only if invalid, then all other OXPs don't pay the cost of generating the data while the data is still valid), and then OXP authors who want better performance could recode to the new, faster interface.
Then again maybe all the performance problems I see are really related to known issues in 1.71.2 and the OXP performance is OK.... but I can forsee that with many OXPs loaded simultaneously, each one wanting to check certain information, that could make things slow.
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Not really. Just subclass OOScript and Bob’s your uncle. You’d almost think someone had designed it with this possibility in mind. ;-)another_commander wrote:1) It would require a major rewrite of the existing scripting code base. Just when we have managed to establish a flexible and stable scripting system, we would have to start all over again. One would ask "why not design it like this from the beginning?". Which brings me to the second drawback.:
But no, I don’t intend to go that way. Partly because of portability, partly for security, but to a large extent because there’s just no need. OXP scripts aren’t a major source of slowness, even when they do nasty stuff like call scriptActionOnTarget: (the unpredictable side effects aspect is a bigger problem than the slow aspect, really). Scripts rarely run more than once every few seconds; if they were really a performance issue it’d be noticeable through stuttering rather than low overall performance. (The big opportunities for optimization in Oolite are in graphics, particularly frustum culling and better HUD rendering.)
Besides, implementing high-level game behaviours in scripting languages has been normal for years now. Large parts of Civilization IV and Eve Online are written in Python. Crysis, Vendetta Online and World of Warcraft use Lua for missions and/or UI scripting. If I continue working on Oolite beyond the next stable release, moving more high-level behaviours to JavaScript is a likely direction.
There don’t seem to be many games using JavaScript (apart from all the Flash games written in ActionScript, of course), but it has turned out to work rather nicely. It isn’t amazingly fast, but there is active, competition-driven development there. I expect we’ll be able to upgrade to Tamarin/ActionMonkey (effectively the Flash just-in-time compiler wrapped up in SpiderMonkey APIs) next year. Apple’s/WebKit’s SquirrelFish engine is currently faster than Tamarin, but I don’t expect Adobe and Mozilla will take that lying down.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
I wouldn’t know, I learned my English in Swaziland.JohnnyBoy wrote:You know, it's amazing what Swedish language schools are teaching nowadays... :DAhruman wrote:...and Bob’s your uncle.
It could have been worse (?), I could have said “…and Bjorn Stronginthearm’s your mother’s brother”.
E-mail: [email protected]
- JohnnyBoy
- ---- E L I T E ----
- Posts: 490
- Joined: Mon May 05, 2008 9:41 pm
- Location: West Sussex, UK (rich agricultural)
I really was only joking, Ahruman. Your English is so impeccable, I wasn't sure if it's your mother-tongue. So I fully expected my 'language school' joke to fall flat on its face...Ahruman wrote:I wouldn’t know, I learned my English in Swaziland.
It could have been worse (?), I could have said “…and Bjorn Stronginthearm’s your mother’s brother”.
"That's no vicious Treeoid. That's my wife."
- Captain Hesperus
- Grand High Clock-Tower Poobah
- Posts: 2310
- Joined: Tue Sep 19, 2006 1:10 pm
- Location: Anywhere I can sell Trumbles.....
Bob's dad was somewhat promiscuous in his early years. The Child Support Agency have been trailing him for years.....TGHC wrote:Bob must get around a bit
Captain Hesperus
The truth, revealed!!
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Dad? Sibling, surely?Captain Hesperus wrote:Bob's dad was somewhat promiscuous in his early years. The Child Support Agency have been trailing him for years.....TGHC wrote:Bob must get around a bit
E-mail: [email protected]