wasm | js | wasm / js | |
---|---|---|---|
sha512 | 12368.78034 | 69356.554 | 0.1783361431 |
sha512int | 12078.89027 | 18342.09272 | 0.6585339229 |
queens | 3.299606497 | 9.262363477 | 0.3562380709 |
list | 76.06484363 | 142.8739845 | 0.5323911412 |
richards | 92.35085892 | 130.1592505 | 0.7095220552 |
cd | 40129.51947 | 62085.45494 | 0.6463594332 |
gcbench | 111415.1666 | 135005.6104 | 0.8252632331 |
tracerFloat | 1048.518644 | 1280.901067 | 0.8185789445 |
Benchmarked against https://github.com/tanishiking/scala-js/tree/opt%2Btyped-closures that contains the following changes.
- CI ONLY Enable the optimizer with WebAssembly. by sjrd · Pull Request #4993 · scala-js/scala-js
- RFC: Introduce TypedClosures in the IR, which are closures without JS interop. by sjrd · Pull Request #5003 · scala-js/scala-js
The benchmark is
- Create a Service Account https://developers.google.com/identity/protocols/oauth2/service-account?hl=en#creatinganaccount That account should be able to read/write to the firestore.
- Download the service account key to the current directory.
- Run
scala-cli main.scala --
diff --git a/sample/src/main/scala/Sample.scala b/sample/src/main/scala/Sample.scala | |
index 2bd374c..c861535 100644 | |
--- a/sample/src/main/scala/Sample.scala | |
+++ b/sample/src/main/scala/Sample.scala | |
@@ -17,6 +17,7 @@ object Main { | |
def main(args: Array[String]): Unit = { | |
println("hello world") | |
+ val foo = new Foo | |
} |
WebAssembly interacts with the external environment through imported and exported functions. If it's a simple function that takes an integer and returns an integer, there is no problem.
However, when trying to use complex data types (such as strings or arrays), the limitation of WebAssembly 1.0 having only 4 types (i32
, i64
, f32
, f64
) becomes an issue.
To represent strings or user-defined types, we have to represent it using these 4 types, and there are no predefined rules on how to represent them in linear memory. The consumers of these modules need to understand how these data structures are laid out in linear memory and implement glue code accordingly.
To communicate with the systems provided by the operating system, you need to call system calls. However, WebAssembly is designed as a complete sandbox, and Wasm modules cannot directly access OS system calls.
To call system calls from Wasm, you need to import functions that have access to system calls from the host environment.
#[link(wasm_import_module = "syscall")]
extern "C" {
fn write(pointer: i32, length: i32);
/**
* The `String` class represents character strings. All string literals in Kotlin programs, such as `"abc"`, are
* implemented as instances of this class.
*/
public class String internal @WasmPrimitiveConstructor constructor(
private var leftIfInSum: String?,
@kotlin.internal.IntrinsicConstEvaluation
public override val length: Int,
private var _chars: WasmCharArray,
https://github.com/tanishiking/scala-wasm
- Basic mathematics
- class
- object (load module / store module)
- static function call
- virtual call
- interface call
- loop
- if/switch
on Aug 22 Maintainer So I don't have a specific point to bring up for this topic, but lately on Discord there have been multiple different places where conversations about the usage of SemanticDB and TASTY are discussed. We currently have an ecosystem that heavily relies on semanticDB for tooling, but also TASTy is starting to be used in various places. There are also other tools/formats like SCIP that are using semanticDB to produce SCIP.
Especially to outsiders this web gets pretty confusing. Why do we need both? Can't X work for both use-cases, etc. I think it may be a good idea to have a session where we discuss the pros and cons of both and potentially look at solutions in tooling that only require using one these to avoid the situation where we have tools relying on both semanticDB and TASTy.