According to this article

Quote

As a scripting language Lua is calling a bunch of stuff that already exists at the C++ level, not providing unique functionality in and of itself

So I wonder if using Lua in Lumberyard can gain the same performance benefit as C++.

I'd like to discuss when using Lua and when using C++ in Lumberyard (or can see as Pros and Cons of Lua and C++ in Lumberyard)

On 12/29/2017 at 3:55 AM, 123iamking said:

if using Lua in Lumberyard can gain the same performance benefit as C++.

The biggest strength in C++ remains the compiler model which incorporates enormous optimizations. Other languages often try to implement the optimizations but usually they're not as good. Offline compilation with profile-guided optimizations are extremely difficult to beat. Lua offers some compilation options to reduce the nature of it being an interpreted language, but nothing on par with compiled C++.

So no, you don't get "the same performance".  

On 12/29/2017 at 3:55 AM, 123iamking said:

As a scripting language Lua is calling a bunch of stuff that already exists at the C++ level, not providing unique functionality in and of itself

That is correct. All the functions and data that you want to use in the Lua system must be exposed using their API.  There are tools like Luabind that can bind the values easily, but it still must be done.

That does not mean there are no benefits.

They could have just as easily written, "As a high level language, C++ is calling a bunch of stuff that already exists at the assembly level, not providing unique functionality in and of itself."  Even though assembly level provides the same core functionality from the machine's perspective, the language choice provides many benefits to the humans involved.

On 12/29/2017 at 3:55 AM, 123iamking said:

can see as Pros and Cons of Lua

In most games, the typical biggest benefit is that Lua supports easier changes during runtime, including (when implemented in the code) the ability to refresh the script mid-game.  The second biggest benefit is that enables people to do some development with a limited subset and customized interface even if they aren't using the main source code.

The first major benefit, the dynamic reloading of code, can allow for extremely rapid iteration. Try a system with one value, it doesn't work, so you modify it and retry immediately. No need to reload the level, no need to restart the executable. You can potentially modify the code repeatedly without exiting the game, without exiting a server, without exiting a multiplayer session. 

The second major benefit, providing a limited game interface for others to program in, enables many interesting features.  Designers who were once programmers and still know how to code but aren't familiar with the entire code base.  Other designers who are less familiar with the code, tech artists, and potentially even some QA and other discipline workers who also know the basics of code, all can modify scripts.  Whatever you expose can be used by the modding community if the game is opened up to modding. 

The biggest drawback is that Lua is still a programming language. Adding it means adding a second language to your code base.  It still has bugs and needs debugging, which means you need both a Lua debugger and a C++ debugger. It still has performance issues which means you need additional profiling tools.  It needs bindings with your C++ code so the Lua functions and data can interact with the C++ functions and data, and programmers need to write those bindings.

Each of those costs and benefits multiply, and that is where the business decision comes in.

If you're doing development for 18 months, and you've got 10 people who can make changes directly in Lua rather than bothering the programmers for those changes, using Lua may save around 4000 work-hours, or two full-time work years. In that case it makes sense to spend several work-months or even a full work-year getting the Lua integration working.  There is an even stronger case if you add more duration to the project, more people using it, and more time saved on average from the most expensive workers moved to less expensive workers.  There is a good cost advantage.

On the flip side, if you've got a short project, if you have few people who would use the project, and if the same people that would have used Lua can also use C++ to implement the features with similar or equal skill, then integrating Lua to the project offers very few benefits.  The time spent integrating a second language, preparing the environments, implementing debuggers and performance tools, the overhead will never be recovered in terms of cost savings. It is a net loss in costs.

The same analysis can be made of most tools when applied to large teams. For a large project needing custom tools, it makes sense to spend many work-years on high quality tools when they will collectively save work-decades across all the people.  When you begin multiplying by ten or twenty or a hundred workers, and you multiply by months or years, even something as small as saving 5 minutes per day can have an enormous impact. 

But if you're doing work by yourself, those same tools and changes will not have the benefit of all the multiplication. The time you spend building the tools and improving the process will never be recovered, and unless you plan on selling the tools to others or gaining some other benefit, you'll be better off without implementing them.