Quelles étincelles surgiront lorsque Golang et Lua se rencontreront ?

Cet article est introduit par la rubrique tutoriel go language pour présenter Golang et Lua à tout le monde. J'espère qu'il sera utile aux amis dans le besoin !

En jouant sur GitHub, j'ai accidentellement découvert gopher-lua, qui est une machine virtuelle Lua implémentée en Golang pur. Nous savons que Golang est un langage statique, tandis que Lua est un langage dynamique. Les performances et l'efficacité de Golang sont très bonnes parmi les autres langages, mais en termes de capacités dynamiques, il n'est certainement pas comparable à Lua. Donc si on peut combiner les deux, on peut combiner leurs points forts respectifs (manuel amusant.

Dans le Wiki du projet, on peut savoir que l'efficacité d'exécution et les performances de gopher-lua ne sont que pires que les liaisons implémentées en C. Donc De du point de vue des performances, cela devrait être une très bonne solution de machine virtuelle.

Hello World

Voici un programme Hello World simple. Nous avons d'abord créé une nouvelle machine virtuelle, puis avons exécuté DoString dessus (...) Expliquez. l'opération d'exécution du code lua, et enfin arrêter la machine virtuelle. Après avoir exécuté le programme, nous verrons la chaîne "Hello World" sur la ligne de commande

package main
import (
"github.com/yuin/gopher-lua"
)
func main() {
l := lua.NewState()
defer l.Close()
if err := l.DoString(`print("Hello World")`); err != nil {
panic(err)
}
}
// Hello World

Compilez à l'avance

Voir le DoString ci-dessus (. ...) chaîne d'appel de méthode, nous constatons que chaque fois que DoString(...) ou DoFile(...) est exécuté, l'analyse et la compilation seront exécutées une fois

func (ls *LState) DoString(source string) error {
if fn, err := ls.LoadString(source); err != nil {
return err
} else {
ls.Push(fn)
return ls.PCall(0, MultRet, nil)
}
}
func (ls *LState) LoadString(source string) (*LFunction, error) {
return ls.Load(strings.NewReader(source), "<string>")
}
func (ls *LState) Load(reader io.Reader, name string) (*LFunction, error) {
chunk, err := parse.Parse(reader, name)
// ...
proto, err := Compile(chunk, name)
// ...
}

Considérant cela, dans le même code Lua. un scénario qui sera exécuté plusieurs fois (par exemple, sur un serveur http, le même code Lua sera exécuté pour chaque requête), si nous pouvons compiler le code à l'avance, nous devrions pouvoir réduire la surcharge d'analyse et de compilation (s'il s'agit d'un code hotpath) . Selon les résultats du Benchmark, la compilation avancée peut en effet réduire les frais généraux inutiles

package glua_test
import (
"bufio"
"os"
"strings"
lua "github.com/yuin/gopher-lua"
"github.com/yuin/gopher-lua/parse"
)
// 编译 lua 代码字段
func CompileString(source string) (*lua.FunctionProto, error) {
reader := strings.NewReader(source)
chunk, err := parse.Parse(reader, source)
if err != nil {
return nil, err
}
proto, err := lua.Compile(chunk, source)
if err != nil {
return nil, err
}
return proto, nil
}
// 编译 lua 代码文件
func CompileFile(filePath string) (*lua.FunctionProto, error) {
file, err := os.Open(filePath)
defer file.Close()
if err != nil {
return nil, err
}
reader := bufio.NewReader(file)
chunk, err := parse.Parse(reader, filePath)
if err != nil {
return nil, err
}
proto, err := lua.Compile(chunk, filePath)
if err != nil {
return nil, err
}
return proto, nil
}
func BenchmarkRunWithoutPreCompiling(b *testing.B) {
l := lua.NewState()
for i := 0; i < b.N; i++ {
_ = l.DoString(`a = 1 + 1`)
}
l.Close()
}
func BenchmarkRunWithPreCompiling(b *testing.B) {
l := lua.NewState()
proto, _ := CompileString(`a = 1 + 1`)
lfunc := l.NewFunctionFromProto(proto)
for i := 0; i < b.N; i++ {
l.Push(lfunc)
_ = l.PCall(0, lua.MultRet, nil)
}
l.Close()
}
// goos: darwin
// goarch: amd64
// pkg: glua
// BenchmarkRunWithoutPreCompiling-8         100000             19392 ns/op           85626 B/op         67 allocs/op
// BenchmarkRunWithPreCompiling-8           1000000              1162 ns/op            2752 B/op          8 allocs/op
// PASS
// ok      glua    3.328s

Pool d'instances de machine virtuelle

Dans le scénario où le même code Lua est exécuté, en plus d'utiliser Advance. compilation pour optimiser les performances, nous pouvons également introduire un pool d'instances de machine virtuelle.

Parce que la création d'une nouvelle machine virtuelle Lua implique de nombreuses opérations d'allocation de mémoire, si vous utilisez la méthode de la recréer et de la détruire à chaque fois, elle consommera un beaucoup de ressources et peuvent être réutilisées. Machines virtuelles, réduisant ainsi les frais inutiles.

func BenchmarkRunWithoutPool(b *testing.B) {
for i := 0; i < b.N; i++ {
l := lua.NewState()
_ = l.DoString(`a = 1 + 1`)
l.Close()
}
}
func BenchmarkRunWithPool(b *testing.B) {
pool := newVMPool(nil, 100)
for i := 0; i < b.N; i++ {
l := pool.get()
_ = l.DoString(`a = 1 + 1`)
pool.put(l)
}
}
// goos: darwin
// goarch: amd64
// pkg: glua
// BenchmarkRunWithoutPool-8          10000            129557 ns/op          262599 B/op        826 allocs/op
// BenchmarkRunWithPool-8            100000             19320 ns/op           85626 B/op         67 allocs/op
// PASS
// ok      glua    3.467s

Les résultats du benchmark montrent que les pools d'instances de machines virtuelles peuvent en effet réduire de nombreuses opérations d'allocation de mémoire.

L'implémentation du pool d'instances fournie par le README est donnée ci-dessous, mais notez que l'implémentation est dans l'état initial. , pas assez d'instances de machines virtuelles sont créées (initialement, le nombre d'instances est de 0), et il y a un problème d'expansion dynamique des tranches. Ce sont des domaines qui méritent d'être améliorés. Appel de module

gopher-lua prend en charge les modules Calling Go, je pense personnellement que c'est une fonctionnalité très intéressante, car dans le développement de programmes Golang, nous pouvons concevoir de nombreux modules couramment utilisés. Ce mécanisme d'appel multilingue nous permet de créer. modifications des codes et des outils.

Bien sûr, en plus, il existe également le module Go Call Lua, mais je pense personnellement que ce dernier n'est pas nécessaire, donc ce dernier n'est pas couvert ici.

type lStatePool struct {
    m     sync.Mutex
    saved []*lua.LState
}
func (pl *lStatePool) Get() *lua.LState {
    pl.m.Lock()
    defer pl.m.Unlock()
    n := len(pl.saved)
    if n == 0 {
        return pl.New()
    }
    x := pl.saved[n-1]
    pl.saved = pl.saved[0 : n-1]
    return x
}
func (pl *lStatePool) New() *lua.LState {
    L := lua.NewState()
    // setting the L up here.
    // load scripts, set global variables, share channels, etc...
    return L
}
func (pl *lStatePool) Put(L *lua.LState) {
    pl.m.Lock()
    defer pl.m.Unlock()
    pl.saved = append(pl.saved, L)
}
func (pl *lStatePool) Shutdown() {
    for _, L := range pl.saved {
        L.Close()
    }
}
// Global LState pool
var luaPool = &lStatePool{
    saved: make([]*lua.LState, 0, 4),
}

Pollution variable

Lorsque nous utilisons des pools d'instances pour réduire les frais généraux, un autre problème épineux sera introduit : car la même machine virtuelle peut être exécutée plusieurs fois avec le même code Lua, modifiant ainsi les variables globales qu'elle contient. Si la logique du code repose sur des variables globales, des résultats d'exécution imprévisibles peuvent se produire (cela ressemble un peu à des « lectures non répétables » dans l'isolement de la base de données).

Variables globales

Si nous devons restreindre le code Lua pour n'utiliser que des variables locales, alors à partir de ce point de départ, nous devons restreindre les variables globales. La question est donc de savoir comment y parvenir ?

Nous savons que Lua est compilé en bytecode puis interprété et exécuté. Ensuite, nous pouvons restreindre l'utilisation de variables globales lors de l'étape de compilation du bytecode. Après avoir vérifié les instructions de la machine virtuelle Lua, j'ai découvert qu'il existe deux instructions impliquant des variables globales : GETGLOBAL (Opcode 5) et SETGLOBAL (Opcode 7).

À ce stade, nous avons déjà une idée générale : nous pouvons limiter l'utilisation de variables globales dans le code en jugeant si le bytecode contient GETGLOBAL et SETGLOBAL. Quant à l'obtention du bytecode, vous pouvez obtenir le FunctionProto du code Lua en appelant CompileString(...) et CompileFile(...), et l'attribut Code est la tranche de bytecode, de type []uint32.

Dans le code d'implémentation de la machine virtuelle, nous pouvons trouver une fonction outil qui génère l'OpCode correspondant en fonction du bytecode.

package main
import (
"fmt"
lua "github.com/yuin/gopher-lua"
)
const source = `
local m = require("gomodule")
m.goFunc()
print(m.name)
`
func main() {
L := lua.NewState()
defer L.Close()
L.PreloadModule("gomodule", load)
if err := L.DoString(source); err != nil {
panic(err)
}
}
func load(L *lua.LState) int {
mod := L.SetFuncs(L.NewTable(), exports)
L.SetField(mod, "name", lua.LString("gomodule"))
L.Push(mod)
return 1
}
var exports = map[string]lua.LGFunction{
"goFunc": goFunc,
}
func goFunc(L *lua.LState) int {
fmt.Println("golang")
return 0
}
// golang
// gomodule

Avec cette fonction outil, nous pouvons vérifier les variables globales.

// 获取对应指令的 OpCode
func opGetOpCode(inst uint32) int {
return int(inst >> 26)
}

Modules

En plus des variables qui peuvent être contaminées, les modules Go importés peuvent également être falsifiés pendant l'exécution. Par conséquent, nous avons besoin d'un mécanisme pour garantir que les modules importés dans la machine virtuelle ne sont pas falsifiés, c'est-à-dire que les objets importés sont en lecture seule.

Après avoir vérifié les blogs concernés, nous pouvons modifier la méthode __newindex de Table et définir le module en mode lecture seule.

package main
// ...
func CheckGlobal(proto *lua.FunctionProto) error {
for _, code := range proto.Code {
switch opGetOpCode(code) {
case lua.OP_GETGLOBAL:
return errors.New("not allow to access global")
case lua.OP_SETGLOBAL:
return errors.New("not allow to set global")
}
}
// 对嵌套函数进行全局变量的检查
for _, nestedProto := range proto.FunctionPrototypes {
if err := CheckGlobal(nestedProto); err != nil {
return err
}
}
return nil
}
func TestCheckGetGlobal(t *testing.T) {
l := lua.NewState()
proto, _ := CompileString(`print(_G)`)
if err := CheckGlobal(proto); err == nil {
t.Fail()
}
l.Close()
}
func TestCheckSetGlobal(t *testing.T) {
l := lua.NewState()
proto, _ := CompileString(`_G = {}`)
if err := CheckGlobal(proto); err == nil {
t.Fail()
}
l.Close()
}

Écrit à la fin

L'intégration de Golang et Lua a élargi mes horizons : il s'avère que le langage statique et le langage dynamique peuvent être intégrés de cette manière. Le fonctionnement du langage statique est d'une grande efficacité, et le développement. du langage dynamique est d'une grande efficacité. Pensez-y Tout excité (évasion.

Après une longue recherche en ligne, j'ai découvert qu'il n'y avait aucun partage technique sur Go-Lua. Je n'ai trouvé qu'un article légèrement lié (Optimisation de l'architecture continue de la page de liste de niveau 3 de JD.com — Meilleures pratiques Golang + Lua (OpenResty). ), et dans cet article, Lua fonctionne toujours sur C. En raison du manque d'informations et de mon manque (d'étudiant) d'expérience en développement, je ne peux pas bien évaluer la faisabilité de cette solution en production réelle. Par conséquent, cet article ne peut être considéré que comme un « article occasionnel », haha.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!