Welche Funken werden entstehen, wenn Golang und Lua sich treffen?

Dieser Artikel wird von der go-SpracheTutorial-Kolumne eingeführt, um Golang und Lua allen vorzustellen. Ich hoffe, dass er Freunden in Not hilfreich sein wird!

Beim Herumspielen auf GitHub habe ich zufällig Gopher-Lua entdeckt, eine virtuelle Lua-Maschine, die in reinem Golang implementiert ist. Wir wissen, dass Golang eine statische Sprache ist, während Lua eine dynamische Sprache ist. Die Leistung und Effizienz von Golang ist im Vergleich zu anderen Sprachen sehr gut, aber in Bezug auf die dynamischen Fähigkeiten ist sie definitiv nicht mit Lua vergleichbar. Wenn wir also die beiden kombinieren können, können wir ihre jeweiligen Stärken kombinieren (manuell lustig.

Im Projekt-Wiki können wir wissen, dass die Ausführungseffizienz und Leistung von Gopher-Lua nur schlechter sind als die der in C implementierten Bindungen. Daher From Aus Leistungssicht sollte dies eine sehr gute virtuelle Maschinenlösung sein.

Hello World

Hier ist ein einfaches Hello World-Programm und führte dann DoString darauf aus Der Vorgang zum Ausführen des Lua-Codes und schließlich zum Herunterfahren der virtuellen Maschine wird in der Befehlszeile die Zeichenfolge „Hallo Welt“ angezeigt. ...) Methodenaufrufkette, wir haben festgestellt, dass jedes Mal, wenn DoString(...) oder DoFile(...) ausgeführt wird, das Parsen und Kompilieren einmal im selben Lua-Code ausgeführt wird In einem Szenario, das mehrmals ausgeführt wird (z. B. wird auf einem HTTP-Server für jede Anforderung derselbe Lua-Code ausgeführt). Wenn wir den Code im Voraus kompilieren können, sollten wir in der Lage sein, den Aufwand für das Parsen und Kompilieren zu reduzieren (Wenn es sich um einen Hotpath-Code handelt) kann die Vorabkompilierung in der Tat unnötigen Overhead reduzieren, wenn derselbe Lua-Code ausgeführt wird Um die Leistung zu optimieren, können wir durch die Kompilierung auch einen Instanzpool für virtuelle Maschinen einführen.

Da das Erstellen einer virtuellen Lua-Maschine viele Speicherzuweisungsvorgänge erfordert, wird die Methode, sie jedes Mal neu zu erstellen und zu zerstören, viel verbrauchen

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

Benchmark-Ergebnisse zeigen, dass virtuelle Maschineninstanzen tatsächlich viele Speicherzuweisungsvorgänge reduzieren können

Die in der README-Datei bereitgestellte Instanzpoolimplementierung ist unten angegeben dass sich die Implementierung im Ausgangszustand befindet, nicht genügend Instanzen der virtuellen Maschine erstellt werden (zunächst beträgt die Anzahl der Instanzen 0) und es besteht das Problem der dynamischen Erweiterung von Slices. Dies sind Bereiche, die es wert sind, verbessert zu werden call

gopher-lua unterstützt Lua-Aufrufe. Ich persönlich halte dies für eine sehr aufregende Funktion, da wir bei der Entwicklung von Golang-Programmen möglicherweise viele häufig verwendete Module entwerfen zu Codes und Tools.

Natürlich gibt es auch das Go-Calling-Lua-Modul, aber ich persönlich bin der Meinung, dass Letzteres nicht notwendig ist, daher wird Letzteres hier nicht behandelt.

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)
// ...
}

Variablenverschmutzung

Wenn wir Instanzpools verwenden, um den Overhead zu reduzieren, entsteht ein weiteres heikles Problem: Denn dieselbe virtuelle Maschine kann denselben Lua-Code mehrmals ausführen und dadurch die darin enthaltenen globalen Variablen ändern. Wenn die Codelogik auf globalen Variablen basiert, kann es zu unvorhersehbaren Ausführungsergebnissen kommen (das riecht ein wenig nach „nicht wiederholbaren Lesevorgängen“ in der Datenbankisolation).

Globale Variablen

Wenn wir Lua-Code auf die Verwendung nur lokaler Variablen beschränken müssen, müssen wir von diesem Ausgangspunkt aus globale Variablen einschränken. Die Frage ist also: Wie erreicht man das?

Wir wissen, dass Lua in Bytecode kompiliert und dann interpretiert und ausgeführt wird. Dann können wir die Verwendung globaler Variablen während der Bytecode-Kompilierungsphase einschränken. Nachdem ich die Anweisungen für die virtuelle Lua-Maschine überprüft hatte, stellte ich fest, dass es zwei Anweisungen mit globalen Variablen gibt: GETGLOBAL (Opcode 5) und SETGLOBAL (Opcode 7).

Zu diesem Zeitpunkt haben wir bereits eine allgemeine Idee: Wir können die Verwendung globaler Variablen im Code einschränken, indem wir beurteilen, ob der Bytecode GETGLOBAL und SETGLOBAL enthält. Zum Abrufen des Bytecodes können Sie das FunctionProto des Lua-Codes durch Aufrufen von CompileString(...) und CompileFile(...) abrufen. Das Code-Attribut ist das Bytecode-Slice vom Typ []uint32.

Im Implementierungscode der virtuellen Maschine finden wir eine Toolfunktion, die den entsprechenden OpCode basierend auf dem Bytecode ausgibt.

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

Mit dieser Toolfunktion können wir globale Variablen überprüfen.

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

Module

Neben Variablen, die kontaminiert sein können, können auch importierte Go-Module während der Laufzeit manipuliert werden. Daher benötigen wir einen Mechanismus, um sicherzustellen, dass in die virtuelle Maschine importierte Module nicht manipuliert werden, d. h. die importierten Objekte sind schreibgeschützt.

Nachdem wir die relevanten Blogs überprüft haben, können wir die __newindex-Methode von Table ändern und das Modul in den schreibgeschützten Modus versetzen.

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),
}

Am Ende geschrieben

Die Integration von Golang und Lua hat meinen Horizont erweitert: Es stellt sich heraus, dass statische Sprache und dynamische Sprache auf diese Weise integriert werden können der dynamischen Sprache ist eine hohe Effizienz. Denken Sie darüber nach. Alle sind aufgeregt (Flucht.

Nach langer Suche im Internet habe ich festgestellt, dass es keinen technischen Austausch über Go-Lua gibt. Ich habe nur einen leicht verwandten Artikel gefunden (Continuous Architecture Optimization of JD.com's Level 3 List Page – Golang + Lua (OpenResty) Best Practices). ), und In diesem Artikel läuft Lua immer noch auf C. Aufgrund des Mangels an Informationen und meiner (studentischen) mangelnden Entwicklungserfahrung kann ich die Machbarkeit dieser Lösung in der tatsächlichen Produktion nicht gut beurteilen. Daher kann dieser Artikel nur als „Gelegenheitsartikel“ betrachtet werden, haha.

Das obige ist der detaillierte Inhalt vonWelche Funken werden entstehen, wenn Golang und Lua sich treffen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!