"Questions that don't deserve their own thread" thread

[bartbes]

Whatever you do, don't use slashes. Require expects module names. These are not paths. They are turned into paths by substituting all dots with slashes, then adding ".lua" to the end, alternatively, "/init.lua" can be appended.

EDIT: As a quick note of why it's important that they are indeed module names, c libraries simply will not work with slashes (barring massive hacks). Similarly, the dots are substituted with the correct slash if they are converted to file paths. Another problem with seeing them as file paths is that they simply aren't, "../stuff" doesn't become "../stuff.lua", but instead becomes "///stuff.lua".

[Bindie]

Exactly, I wanted to answer his question that "/" worked, I see your point only using "." since it is always correct, I already use "."

[Grubby]

Some really dumb newbie questions I doubt need a separate thread:

1:
So I've seen in a few programs something like "local lg = love.graphics". Besides reducing how much one has to type, does this serve any other purpose?

2:
Static vs Dynamic. Which is better or faster. For example:

love.graphic.print("text", 100, 100)

local offset = 50
love.graphic.print("text", 50+offset, 50+offset)

3:
In some languages, really small loops can be faster by NOT creating a loop at all.

for i = 1, 3 do
Value = Other + 1
end

local i = 1
Value = Other + 1
i = i + 1
Value = Other + 1
i = i + 1
Value = Other + 1

Would the love2d/lua combo benefit from this as well?

4:
Which of these is better and/or faster? Assume local love.flag = false

love.flag = true

love.flag = not love.flag

[Robin]

1:
So I've seen in a few programs something like "local lg = love.graphics". Besides reducing how much one has to type, does this serve any other purpose?

Technically, it's faster (1 local access instead of 1 global access + 1 indexing), but doing that for the speed is like Tolkien removing all periods from the Lord of the Rings to make it shorter.

2:
Static vs Dynamic. Which is better or faster. For example:

love.graphic.print("text", 100, 100)

local offset = 50
love.graphic.print("text", 50+offset, 50+offset)

The first is faster as the computer has to do less work, but it's far better to let the computer do the calculating when necessary, especially if you want the text to move about. Same as above, LOTR without periods.

3:
In some languages, really small loops can be faster by NOT creating a loop at all.

[...]

Would the love2d/lua combo benefit from this as well?

Again, LOTR without periods.

4:
Which of these is better and/or faster? Assume local love.flag = false

love.flag = true

love.flag = not love.flag

It depends. In terms of speed, LOTR without periods. In terms of which you'd want to use: well, does the same code need to change the flag back?

(Also, I wouldn't put custom properties on the love module. That's asking for trouble.

[undef]

Technically, it's faster (1 local access instead of 1 global access + 1 indexing), but doing that for the speed is like Tolkien removing all periods from the Lord of the Rings to make it shorter.

Hahaha, great analogy!

[szensk]

Another thing to note: many of the optimizations you mention can be done automatically by LuaJIT. It tries to do loop unrolling (#3), constant folding (#2) and code hoisting (#1 but only in loops IIRC). I do #1 frequently myself because love.graphics is a mouthful but also LuaJIT doesn't always kill all these look ups.

While it is true the compiler can't always apply these optimizations, I feel it is best to keep the "un-optimized" form if it makes the code more readable.

[Grubby]

Thanks for the reply(s) Robin and szensk.

So szensk:

Another thing to note: many of the optimizations you mention can be done automatically by LuaJIT.

What exactly does that mean? Isn't LuaJIT a part of the love package? Your use of the word "can" implies these things are NOT turned on by default. Why not? And how would these optimizations actually be manipulated?

[szensk]

Thanks for the reply(s) Robin and szensk.

So szensk:
What exactly does that mean? Isn't LuaJIT a part of the love package? Your use of the word "can" implies these things are NOT turned on by default. Why not? And how would these optimizations actually be manipulated?

By default, LuaJIT (and these optimizations) are enabled in Love (since version 0.9.0?). You're probably already benefiting from them. I said "can" because sometimes these optimizations will not be applied even if hypothetically they could. The cases that cause this are not worth worrying about unless you're paying for time on a supercomputer.

Regarding the optimization #1, LuaJIT's documentation has this to say:

It's a common Lua idiom to cache library functions in local variables or upvalues, e.g.:

Code: Select all

local byte, char = string.byte, string.char
local function foo(x)
  return char(byte(x)+1)
end

This replaces several hash-table lookups with a (faster) direct use of a local or an upvalue. This is less important with LuaJIT, since the JIT compiler optimizes hash-table lookups a lot and is even able to hoist most of them out of the inner loops. It can't eliminate all of them, though, and it saves some typing for often-used functions. So there's still a place for this, even with LuaJIT.

That's really the only one you might want to do manually and even then it's iffy.

[Positive07]

You're probably already benefiting from them. I said "can" because sometimes these optimizations will not be applied even if hypothetically they could. The cases that cause this are not worth worrying about unless you're paying for time on a supercomputer.

Not even then, because it's a super computer so it will run super ultra fast anyway right?

Well basically the JIT compiler can go back to interpreter mode (default Lua) if it finds a function it can't compile (because it's in C, or SOME of the Lua function), you shouldn't worry about this.

Other thing that may happen is LÖVE not using LuaJIT, which may also happen, for example in old computers, computers with architectures not supported by LuaJIT or operating systems that don't allow compilers to run on them (iOS I'm looking at you, but iOS still uses LuaJIT just disables the JIT compiler so that it wont infringe Apple's rules)

So yeah there you have some reason why LÖVE would be running in interpreter mode, but this are rare cases so you should assume it always runs in JIT mode (or don't care at all... if you optimize your code it will be optimized JITted or not)

Yet remember premature optimizations are the root of all evil!

[parallax7d]

is there a way to look at locals when in debug mode? it's like the reference doesn't exist. i can find it in debug.getlocal(3,1), but how do i use the reference, like if I wanted to pop into a local table and print out values?

Code: Select all

do
g = 1
local l = 2
debug.debug()
end

lua_debug> print(g)
lua_debug> 1
lua_debug> print(l)
lua_debug> nil