elexis Posted April 23, 2019 Report Share Posted April 23, 2019 54 minutes ago, stanislas69 said: I am sorry I am wasting your precious time. (Wasn't speaking about mine) 1 1 Quote Link to comment Share on other sites More sharing options...
elexis Posted April 24, 2019 Report Share Posted April 24, 2019 14 hours ago, (-_-) said: (It really doesnt matter even if the reasoning was the name js being one character shorter. We are stuck with it.) The presentation linked in the first post makes 0 A.D. really appear like it needs systematic renovation. I suspect JS isn't so bad (my experience was overall quite good), but perhaps the data-oriented design could help fix many bottlenecks, the GetEntityState one for example. Something big is needed, either somewhere or everywhere. 14 hours ago, nani said: @elexis all your links are private or redirect to play0ad.com Yes, they're internal links, at least now. I posted them to answers Stans request for material for his presentation, he has access to these links. (The links are also broken by various server migrations and forum updates throughout the last 15 years, but can still be translated to modern URLs.) Quote Link to comment Share on other sites More sharing options...
Guest Posted April 24, 2019 Report Share Posted April 24, 2019 (edited) While I haven’t done any benchmarking, I really think luaJIT is still faster than SM or even V8. Looking at some old benchmarks, by a significant margin. But then again, the browser war has resulted in a lot of innovation these past years. Edited April 24, 2019 by Guest Quote Link to comment Share on other sites More sharing options...
Stan` Posted April 24, 2019 Report Share Posted April 24, 2019 From all the resources I now read, I still have the feeling that we chose convenience over performance. LUA was better Nearly twice as fast as JavaScript Older than JavaScript (so likely to be more mature) The industry standard for games in all aspects save for Scripter's personnal tastes Syntax (People wanted the language to be more user friendly for non programmers) A special OOP paradigm using metatables JavaScript had Like LUA it matched the frontend and backend functionnality A nicer syntax closer to C OOP through prototypes and now through classes Preference from devs who weren't into LUA at all. Was supported by Mozilla 1 Quote Link to comment Share on other sites More sharing options...
Guest Posted April 24, 2019 Report Share Posted April 24, 2019 Well, LuaJIT was released in 2010 IIRC. So the performance wasn't that bad when the decision was made. The former uses a tracing jit which is arguably better than the one JS engines followed with. (I don't know much about this last statement so take it with a grain of salt). I might try some benchmarking to see if the nice c like syntax was really worth it. Quote Link to comment Share on other sites More sharing options...
Stan` Posted April 24, 2019 Report Share Posted April 24, 2019 Language Ackermann's Function Nested Loop (16M) Hash Tables (80k) Method Calls (2M) LUA 110ms 1,462ms 1,061ms 5,397ms JavaScript 310ms 10,124ms 1,922ms 8,5552 Here is the benchmark that was done at the time. The person did not give the parameters for the Ackerman function. My browser only accept (3,11) and the lua online thingy https://www.lua.org/demo.html I used to test was like (3,8) The js was faster too. Quote Link to comment Share on other sites More sharing options...
Guest Posted April 24, 2019 Report Share Posted April 24, 2019 Lua != luaJIT. The latter is *much* faster. Quote Link to comment Share on other sites More sharing options...
Stan` Posted April 24, 2019 Report Share Posted April 24, 2019 13 minutes ago, (-_-) said: Lua != luaJIT. The latter is *much* faster. Those aren't my numbers. But yeah very different. I wonder if we would have made the switch had we chosen LUA. Quote Link to comment Share on other sites More sharing options...
WhiteTreePaladin Posted April 24, 2019 Report Share Posted April 24, 2019 Added converted links. (They are not public, so this is mainly a convenience for the team.) https://wildfiregames.com/forum/index.php?/topic/717-Meeting Summary for the Final Scripting Debate https://wildfiregames.com/forum/index.php?/topic/725-Announcement of final scripting decision https://wildfiregames.com/forum/index.php?/topic/639-Scripting Backend Functionality https://wildfiregames.com/forum/index.php?/topic/638-Scripting Frontend Functionality https://wildfiregames.com/forum/index.php?/topic/715-Lua & Javacript Performance Tests https://wildfiregames.com/forum/index.php?/topic/712-Javascript Proposal https://wildfiregames.com/forum/index.php?/topic/557-The Great Scripting War https://wildfiregames.com/forum/index.php?/topic/622-The Scripting Flame War https://wildfiregames.com/forum/index.php?/topic/644-Macros for Lua Inheritance https://wildfiregames.com/forum/index.php?/topic/629-The Preprocessor Alternative https://wildfiregames.com/forum/index.php?/topic/606-Initial Language Vote 2 Quote Link to comment Share on other sites More sharing options...
nani Posted April 24, 2019 Report Share Posted April 24, 2019 Would be noice to make them public or is there some secret reason not to? Quote Link to comment Share on other sites More sharing options...
Guest Posted April 24, 2019 Report Share Posted April 24, 2019 (edited) Legal reasons I guess. Edited April 24, 2019 by Guest Quote Link to comment Share on other sites More sharing options...
GunChleoc Posted April 24, 2019 Report Share Posted April 24, 2019 Yep. Basically, everybody who posted to these threads would need to agree to publish them. 1 Quote Link to comment Share on other sites More sharing options...
WhiteTreePaladin Posted April 24, 2019 Report Share Posted April 24, 2019 (edited) 31 minutes ago, nani said: Would be noice to make them public or is there some secret reason not to? Well, some of the discussions are really old (2003-2004) and the people involved may not have ever considered that their discussions could become public. We would want to contact them as a courtesy. At a minimum, we have to look very carefully through each post for anything we release. However, a lot of relevant content from some of those meetings has actually been copied to a public post. It was linked earlier in this thread, but here's another link for convenience: https://wildfiregames.com/forum/index.php?/topic/15068-why-chose-javascript-for-scripting/ [Edit] The "public" posts are actually the beginning of this very thread. @stanislas69 I'm sure the decision was at least somewhat logical at the time, since performance is just one metric. Ideally, for performance we would stick most code in C++ and only have a few items (like AI) implemented in scripts as they did in Age of Empires. The original plan was for 0 A.D. to be closed source freeware, but still much more highly modifiable than Age of Empires. With closed source code, this requires more implementation to be moved to scripts which is itself a major performance trade-off. With the goal of allowing easy modification by hobbyists, rather than professionals, it's much easier to see why syntax would be such a major consideration. Edited April 24, 2019 by WhiteTreePaladin 1 Quote Link to comment Share on other sites More sharing options...
Stan` Posted April 24, 2019 Report Share Posted April 24, 2019 Yeah it was said that JS could handle 230 calls in a turn LUA 550 and c++ 8000 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.