2 Punkte von GN⁺ 2024-07-31 | 1 Kommentare | Auf WhatsApp teilen

Von Grund auf experimentelle AOT-JS-Engine

Porffor ist eine ungewöhnliche JS-Engine/Compiler/Laufzeitumgebung, die JS-Code vorab zu WebAssembly oder nativ kompiliert. Derzeit wird es zu Forschungszwecken genutzt und ist für den produktiven Einsatz nur eingeschränkt geeignet.

Wasm-Kompilierung

Die WebAssembly-Ausgabe von Porffor ist im Vergleich zu bestehenden JS->Wasm-Projekten deutlich schneller und kleiner. Das liegt daran, dass Porffor JS per AOT kompiliert.

  • Wasm-Größe: 32-mal kleiner als Javy (~1,3MB -> ~40KB)
  • Wasm-Performance: 18-mal schneller als Javy (~70m -> ~4m)

Native Kompilierung

Da JS im Voraus kompiliert wird, kann Porffor ohne Paketierung einer Laufzeitumgebung zu echten nativen Binärdateien kompilieren. Das führt zu folgenden Ergebnissen:

  • Binärgröße: mehr als 1000-mal kleiner (~90MB -> <50KB)
  • Speicherverbrauch: mehr als 40-mal geringer (~50MB -> ~1MB)
  • Performance: bis zu 3-mal schneller

Weitere Punkte

  • Porffor ist sicher: Es wird zu Wasm kompiliert und ist in einer speichersicheren Sprache (JS) geschrieben.
  • Porffor wurde von Anfang an mit AOT im Blick entwickelt: Es basiert nicht auf einer bestehenden JS-Engine. Die einzige Abhängigkeit ist ein JS-Parser.
  • Porffor unterstützt TypeScript als Eingabe: Ein umständlicher Transpiler-Schritt ist nicht nötig. TS-Dateien können direkt verwendet werden.

Playground

Porffor kann online oder lokal ausprobiert werden. Dafür kann der Befehl npm i -g porffor@latest && porf verwendet werden.

  • Prime Numbers
  • Fibonacci
  • Factorial
  • Sum of Digits
  • Exception
  • Array Reading
  • ArrayPrototype
  • Math Proposals Parser: acorn, meriyah, hermes-parser, @babel/parser
  • Target: wasm
const isPrime = number => {
  if (number < 2) return false;
  for (let i = 2; i < number; i++) {
    if (number % i == 0) return false;
  }
  return true;
}

let counter = 0;
while (counter <= 10000) {
  if (isPrime(counter)) Porffor.numberLog(counter);
  counter++;
}

Test262

Test262 ist die offizielle ECMAScript-Konformitätstest-Suite. Porffor führt sie bei jedem Commit aus, um den Fortschritt bei der Konformität zu verfolgen.

Zusammenfassung von GN⁺

Porffor ist eine ungewöhnliche Engine, die JS-Code vorab zu WebAssembly oder nativ kompiliert. Dadurch bietet sie im Vergleich zu bestehenden Lösungen deutlich kleinere Größen und schnellere Performance. Sie wird zu Forschungszwecken verwendet und unterstützt TypeScript als Eingabe. Das Projekt kann nützlich sein, um Performance und Effizienz von JS-Engines zu erforschen. Ein ähnliches Projekt mit vergleichbarer Funktionalität ist ein JS->Wasm-Compiler wie Javy.

1 Kommentare

 
GN⁺ 2024-07-31
Hacker-News-Kommentare
  • Oliver hat angekündigt, sich voll auf Porffor zu konzentrieren.
  • Es gibt die Meinung, dass die Spielräume für Leistungssteigerungen bei JS begrenzt seien und Transpilierung zu V8-C++-Aufrufen der beste Weg sein könnte.
    • Durch das Kompilieren von TypeScript lassen sich große Performance-Gewinne erzielen.
    • TS und V8 sind sich schnell verändernde, nicht standardisierte Ziele, daher wäre ein großes Team nötig.
  • Es wird als cool angesehen, dass eine JS-Runtime versucht, Wasm-Zugriff zu ermöglichen.
    • Gemeinsamkeiten und Unterschiede zwischen Static Hermes und Porffor werden analysiert.
      • Beide zielen auf Konformität mit JS test262 ab.
      • Porffor unterstützt Native- und Wasm-Ausgabe, während Static Hermes sich hauptsächlich auf Native-Ausgabe konzentriert.
      • Porffor ist self-hosted und in reinem JS geschrieben, während Static Hermes von LLVM abhängt.
      • Porffor unterstützt kein async/Promises/await, Static Hermes dagegen in begrenztem Umfang.
      • Static Hermes ist in C++ geschrieben, Porffor hauptsächlich in JS.
      • Beide unterstützen TypeScript, aber Static Hermes transpiliert den TS-AST nach Flow, während Porffor dies nativ unterstützt.
      • Static Hermes hat einen Fallback-Interpreter, um schwierige JS-Szenarien wie eval zu unterstützen, während Porffor nur AOT-Kompilierung unterstützt.
  • Es gibt Vorfreude darauf, ob dieses Projekt JS-Engines beschleunigen kann.
  • Bei windmill.dev wird beim Deployment von Code ein Bun-Build verwendet, um Skripte und alle Abhängigkeiten in einer einzigen JS-Datei zu bündeln.
    • Das Bundle wird in s3 gespeichert, um Cold Starts und Speichernutzung zu verbessern.
    • Wenn sich alles nativ bündeln ließe, wäre das ein Gamechanger.
  • Es wird gefragt, warum "ahead-of-time JS engine" eine bessere Beschreibung sein soll als "JS-to-Wasm compiler".
  • Es gibt Zweifel am Versionierungsschema von Porffor.
    • Wenn in Test262-Tests Regressionen auftreten, könnte die Versionsnummer rückwärts laufen.
  • Porffor bedeutet auf Walisisch "lila".
  • Im Vergleich zu quickJS wird gefragt, wie JS in nativen Code kompiliert wird.
  • Es wird als ähnliche Idee angesehen wie der Versuch von Facebook, PHP nach C zu transpiliieren.
    • Das hieß hiphop-php, und am Ende wurde HHVM als neues Konzept entwickelt.
  • Es besteht Interesse an einer Möglichkeit, NodeJS als native Bibliothek zu kompilieren.
    • Der derzeit verwendete Prozess ist etwas kompliziert und fehleranfällig.