Beginner friendly book about Lua?

[milon]

@Nelvin Thanks a lot for the recommendation, I really liked the sample about performance tips. Looks very promising, I'll make sure to put this book on my list to read. Even if not everything is going to be applicable to LuaJIT and Love2D, it could offer some context.

A word of caution about the use locals! tip on page 17 - that's only actually helpful when you're making a truly huge number of function calls (1 million in the example given). Creating local variables comes with its own overhead, and in most cases there is absolutely no noticeable performance difference. And done incorrectly, it can actually hamper performance. Hence Rules 1 & 2 of optimization.

[grump]

A word of caution about the use locals! tip on page 17 - that's only actually helpful when you're making a truly huge number of function calls (1 million in the example given). Creating local variables comes with its own overhead, and in most cases there is absolutely no noticeable performance difference. And done incorrectly, it can actually hamper performance. Hence Rules 1 & 2 of optimization.

Can you show some examples where locals hamper performance, or how to use them incorrectly?

I'm inclined to believe the word of the author/creator of Lua, but you never know what crazy shit people might come up with.

[milon]

Can you show some examples where locals hamper performance, or how to use them incorrectly?

I'm inclined to believe the word of the author/creator of Lua, but you never know what crazy shit people might come up with.

I believe the author too - it's just easy to ignore Rules 1 & 2 and jump into premature optimization. That's all I was trying to caution against, and I believe I was saying the same thing as the author.

Having said that, interestingly, no I can't show any examples right now. When I was first learning Lua years ago, I stumbled across a PDF warning about premature optimization and it gave some compelling examples of how premature optimization (in this case, creating a Local out of every (math?) function call) not only didn't help, but actually slowed things down. I tested it myself in various scenarios and came to the same conclusion. Then I went back to Rules 1 & 2 and took them to heart. Don't optimize unless there's a thing that actually needs optimizing!

I can't find that PDF now, and I can't find my old test code - I most likely deleted it years ago. I created a small test case just now, and found that by not creating needless locals, my code ran 2-3 times faster. Yay! And then I switched the order I ran the tests in, and got the exact opposite results - meaning the time difference was related to something else altogether.

So no, I can't provide any examples currently, and I'm scratching my head again. I'm also questioning my old testing and wondering if I made similar errors there. It seems wrong to start every function with "local math_sin = math.sin" as an optimization, and yet I can't prove it either.

Okay grump, time for you - or anyone - to educate me again!

And for anyone who cares, here's my failed test code. Switch the badLocals() and goodLocals() calls to see it fail. The first print statement will always have a time that's 2-3 times longer than the second print statement, regardless of which function was called. Either way, there's absolutely no human-discernable difference in execution.

Code: Select all

local function badLocals()
    local math_sin = math.sin
    local x = 0
    for i = 1, 1000 do
        x = x + math_sin(i)
    end
    return x
end

local function goodLocals()
    local x = 0
    for i = 1, 1000 do
        x = x + math.sin(i)
    end
    return x
end

local timer = 0.0

timer = os.clock()
badLocals()
print(os.clock() - timer)

timer = os.clock()
goodLocals()
print(os.clock() - timer)

EDIT - Sorry for this going so far off topic now!

[pgimeno]

So no, I can't provide any examples currently, and I'm scratching my head again. I'm also questioning my old testing and wondering if I made similar errors there. It seems wrong to start every function file with "local math_sin = math.sin" as an optimization, and yet I can't prove it either.

Fixed it for you.

You actually do "local math_sin = math.sin" at the top of the file, then use math_sin in all functions.

Either way, there's absolutely no human-discernable difference in execution.

Since you've written it in JIT-compilable form, you're assuming that the code surrounding math.sin will be JIT-compiled, which won't always be the case. The tracing JIT eliminates the math.sin function call in both cases, replacing it with a fsin instruction, therefore no difference is expected. Try adding jit.off() at the beginning to see the timing difference without compiled code.

[milon]

Thanks for the reply pgimeno!

... you're assuming that the code surrounding math.sin will be JIT-compiled, which won't always be the case...

Tell me more about this. In what cases wouldn't it be JIT-compiled?

[pgimeno]

See http://wiki.luajit.org/NYI

[grump]

When I was first learning Lua years ago, I stumbled across a PDF warning about premature optimization and it gave some compelling examples of how premature optimization (in this case, creating a Local out of every (math?) function call) not only didn't help, but actually slowed things down. I tested it myself in various scenarios and came to the same conclusion. Then I went back to Rules 1 & 2 and took them to heart. Don't optimize unless there's a thing that actually needs optimizing!

That's not really "premature optimization". Optimizations are premature when they make code more difficult to maintain, because you sacrificed readability and maintainability for assumed performance gains too early in the project, even though you don't even know if it's going to make a noticable difference in the end. That is something you should only do when you have enough data to make an informed decision, and that is almost always when the project or the module is feature-complete, not before.

It's just a dramatic way of saying "don't make your code hard to change until you know it's worth it".

Using best practices, and doing it correctly, is not an optimization, and is never premature. I would even argue that retroactively changing globals to locals is not optimization. That's just fixing past mistakes. If your game runs like dog shit, this kind of "optimization" won't make a difference anyway.

[dubbist]

I'm currently reading "LOVE for Lua Game Programming" and "Lua Quick Start Guide." They're both from Packt publishing and are on sale now for $5 a piece. I'm an artist, currently trying to learn programming to make games.

The "LOVE for Lua" book is from 2013 and the code is outdated, but I like the way the information is organized and I've been able to fix the code to work so far.

"Lua Quick Start Guide" is from 2018 and I'm finding it very beginner friendly. It does a good job of explaining concepts in an accessible and organized way. Lua has a kind of quirky and minimalist way of doing things, it seems. This is the book I would recommend to you.

[ddabrahim]

@dubbist Thank you for the recommendations, looks like a very good opportunity to get my hands on some of those books for just $5. Even if they are out of date, could include some useful information.

[milon]

The sale is over now apparently (darn, just missed it!), and it's pricey for the 2013 book. I poked around for other Lua programming titles and came across one called "Developing Games on the Raspberry Pi: App Programming with Lua and LÖVE", published 2019. The Look Inside preview seems promising, and I'm pretty certain the principles aren't limited to the Pi. Currently sold out, but might be useful if you can get a copy.

EDIT - I located a digital copy preview, and I'm disappointed with what I saw. It's definitely beginner level (which will be great for some folks), but some code examples given contain various errors: mostly indentation, some logic flow and one or two missing 'end' statements. Not a book I'd want to invest in, sadly.