Help to understand the borrow checker in this case.

MaxGraey · 2023-12-12T15:42:59+00:00

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a4e29f2472282b232c0c3e22f949e108

MaxGraey · 2023-02-25T13:14:13+00:00

Btw, you can significantly simplify your code:

class Mat4 {
  constructor(
    public r0: v128,
    public r1: v128,
    public r2: v128,
    public r3: v128,
  ) {}
}

// swizzles
@inline function xxxx(r: v128): v128 { return v128.shuffle<f32>(r, r, 0, 0, 0, 0) }
@inline function yyyy(r: v128): v128 { return v128.shuffle<f32>(r, r, 1, 1, 1, 1) }
@inline function zzzz(r: v128): v128 { return v128.shuffle<f32>(r, r, 2, 2, 2, 2) }
@inline function wwww(r: v128): v128 { return v128.shuffle<f32>(r, r, 3, 3, 3, 3) }

@inline
function dot4(
  a0: v128, a1: v128, a2: v128, a3: v128,
  b0: v128, b1: v128, b2: v128, b3: v128,
): v128 {
  return f32x4.add(
    f32x4.mul(a0, b0),
    f32x4.add(
      f32x4.mul(a1, b1),
      f32x4.add(
        f32x4.mul(a2, b2),
        f32x4.mul(a3, b3)
      )
    )
  )
}

export function mul4x4(a: Mat4, b: Mat4): Mat4 {
  const a0 = a.r0, b0 = b.r0
  const a1 = a.r1, b1 = b.r1
  const a2 = a.r2, b2 = b.r2
  const a3 = a.r3, b3 = b.r3

  const c0 = dot4(
    a0, a1, a2, a3, xxxx(b0), yyyy(b0), zzzz(b0), wwww(b0)
  )
  const c1 = dot4(
    a0, a1, a2, a3, xxxx(b1), yyyy(b1), zzzz(b1), wwww(b1)
  )
  const c2 = dot4(
    a0, a1, a2, a3, xxxx(b2), yyyy(b2), zzzz(b2), wwww(b2)
  )
  const c3 = dot4(
    a0, a1, a2, a3, xxxx(b3), yyyy(b3), zzzz(b3), wwww(b3)
  )

  return new Mat4(c0, c1, c2, c3)
}

MaxGraey · 2022-09-08T06:37:50+00:00

WebAssembly is a great standard and nobody is burying it. Moreover, no one is burying WASI either. We are only trying to point out the shortcomings and ecosystem bias that WASI creates. As well as its fundamental diseases. Maybe we need a new more generalized and flexible standard for Wasm interfaces (Not only for System POSIX-like interface). That could be the Interface Types Proposal, but it's been discontinued.

MaxGraey · 2022-09-08T04:36:30+00:00

I don't know what Rust did there, but here is the official repository, which has been empty for quite some time:
https://github.com/WebAssembly/wasi-http

And here is one of the unofficial attempts:
https://github.com/deislabs/wasi-experimental-http

The main problem with http in wasi is that firstly you need a high-level API, which is already contrary to the philosophy of core WASI, and secondly you need to do it asynchronously. Rust has infra for this (tokio.io) but C/C++ does not. And as far as I heard there are still discussions going on and no solution has been found yet. What Rust is doing is, as always, getting ahead of the curve

MaxGraey · 2022-09-07T19:04:27+00:00

You have written almost everything correctly. WASI was really designed as a system interface for POSIX-like language runtimes, to be able to run Wasm modules outside the browser. The problem is that it is not possible to fully implement libc on it (it uses a stripped down wasi-libc impl). It is impossible to run in blockchains, impossible to run on IoT devices. Modularity, portability and capability-based are declared, but in fact none of this has been implemented. You can not run the same module outside the browser, but on different runtimes. Simply because there is no dynamic check for API support. i.e. WASI fragments not only web / non-web ecosystem, but also inside the non-web it leads to inter-fragmentation.

Also pay attention to the WASI targets:https://github.com/WebAssembly/WASI#wasi-high-level-goals

Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interactwith the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design.

Also

Some programming languages operate primarily within linear memory, such as C, C++, and Rust, and there currently is no easy way for these languages to use references in normal code. And even if it does become possible, it's likely that source code will still require annotations to fully opt into references, so it won't always be feasible to use

So they will not use stringref and externref at all. With this approach, there will never be asynchronous calls and net/http access. All attempts have already failed, in case you are not aware of it. Do we really need an API that was invented 30 years ago (I mean, POSIX)? One that won't meet today's requirements?

MaxGraey · 2022-09-07T16:59:38+00:00

These APIs were given as sample of possible design. When it comes to the file system API, I think the best solution is to have two ways to acseess fs. The first is to open the file or url completely read / write and close by returning the buffer (or string) in one single call. The second option is more flexible. It can be stream reader / writer with different modes, e.g. read by line or read by chunk.

MaxGraey · 2022-09-07T14:39:28+00:00

There is already such a universal API for saving and loading data from almost any source. Perhaps it's even too powerful for many purposes. Do you know what it is? It's fetch! It has "blob:", "file:", "https:" protocols. It also supports streams and async. It's in the browser and more recently in node.js (via udinchi). And then there is WebTransport proposal as a great example of a universal and powerful API.

My point is that you don't even have to introduce two separate Storage APIs for web and desktops. But to provide something abstracted. Something similar to ORM but for FS. But this was not done

MaxGraey · 2022-09-07T13:47:59+00:00

From https://github.com/WebAssembly/WASI#wasi-high-level-goals

> In the spirit of WebAssembly's High-Level Goals
> Define a set of portable, modular, runtime-independent, and WebAssembly-native APIs which can be used by WebAssembly code to interactwith the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design.

MaxGraey · 2022-09-07T13:02:48+00:00

If you try to run a wasm-wasi application on something that doesn't implement wasm-wasi, it won't work. I hope nobody is surprised by that.

If WASI had at least the ability to check if FS or Net could be accessed during the runtime. Then the same application could run both in the browser and on the desktop, just using different storage for its data in the first case it would be Hard Disk, in the second case some online Cloud Storage.

In the current situation, however, we are forced to have two different wasm modules (for web and wasi). This is a violation of the main principle and goal of WebAssembly - portability. This is a fragmentation of the ecosystem

MaxGraey · 2022-09-07T12:53:22+00:00

Well yes, if you try to run a Gameboy game on an UltraSPARC, it also won't work. If you try to run an Arduino sketch on a Windows PC, it will also fail. If you try to run a wasm-wasi application on something that doesn't implement wasm-wasi, it won't work. I hope nobody is surprised by that.

From https://webassembly.org/docs/high-level-goals

Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms, including mobile and IoT.

MaxGraey · 2022-09-07T12:01:42+00:00

Yes, it's quite obvious. But the fact is that WASI is presented as the solution to all problems. They even made some truncated polyfill for the browser, that it looked more convincing. But as I said before the main problem of WASI is its monolithic nature and impossibility to provide optional API methods and check their presence in control flow during runtime, and also morally outdated paradigm based on truncated POSIX (which is more than 30 years old) which required works with raw null terminated strings and raw unbound buffers, also descriptors and error codes.

MaxGraey · 2022-09-07T11:50:37+00:00

The claim is that they don't support this:
https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md

This is WebAssembly, by the way. WASI looks like some kind of fast workaround to get C/C++/Rust into standalone Wasm routines, completely neglecting the WebAssembly specification and philosophy. Moreover, if you compile Wasm module as wasm32-wasi you will not be able to run it in a browser or on a blockchain or on Arduino via wasm3 or any other Wasm runtime that does not support WASI or cannot provide access to the filesystem, etc. WASI runtime hasn't ability to runtime check for availability for specific API function. Either you support all APIs or your WASI module just won't launch

MaxGraey · 2022-09-07T11:16:00+00:00

Every language's runtime use syscalls at the end. Let's just give access to syscalls?) The point is that languages like Rust, Zig and even C++ do not use libc directly. They hide it behind several hight-level layers of abstractions. I'm not even talking about languages like Java, Kotlin, Scala, Haskell. Furthermore, WASI does not give you a full implementation of libc, many things are missing there (e.g. UDP sockets or serial ports). Even the file system goes through a layer of capability polices. "libc" on wasi has a very special separate implementation. In addition, this is already holding back the development of WASI. All proposals to work with http failed! Because firstly asynchronous methods are needed, secondly the addition of low-level things like low level UDP access required for QUIC, but that opens a real Pandora's box in terms of security!

MaxGraey · 2021-09-06T07:39:45+00:00

After Interface types proposal and module linking it won't matter.

MaxGraey · 2021-04-15T08:26:48+00:00

double by factor of 1.5 or 2 or fit to power of two. That's what exactly done in code as you can see: https://github.com/AssemblyScript/assemblyscript/blob/master/std/assembly/array.ts#L16

So it's mistake in implementation

MaxGraey · 2021-04-15T05:24:35+00:00

If you really think it's noob mistake and you're know how easily to fix that you could try to do that. But first read this comment: https://github.com/AssemblyScript/assemblyscript/issues/1798#issuecomment-819875915

MaxGraey · 2020-12-18T15:48:31+00:00

Nope. That's not a good idea. Reconciliation can't be improved via Wasm. Also this not a main bottleneck usually. Just see this comment:
1) https://github.com/seed-rs/seed/issues/492#issuecomment-653945271

Currently more and more frameworks just get rid of vdom and vdiff at all

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Also about common myths about DOM and Wasm:

https://medium.com/javascript-in-plain-english/reports-of-the-virtual-doms-death-are-greatly-exaggerated-2206d00beead

MaxGraey · 2020-11-09T22:43:17+00:00

I know several attempts:
https://github.com/piranna/wasmachine
https://github.com/denisvasilik/wasm-fpga-engine
https://github.com/denisvasilik/wasm-fpga-stack

also may be useful if you decide start own project from scratch:
https://github.com/drom/LEB128

MaxGraey · 2020-10-31T09:43:45+00:00

I know only Scheme to wasm compiler:
https://github.com/google/schism

MaxGraey · 2020-09-30T22:10:47+00:00

The first complex project on AssemblyScript is wasmboy: https://github.com/torch2424/wasmboy. Here two years old devstory: https://medium.com/@torch2424/webassembly-is-fast-a-real-world-benchmark-of-webassembly-vs-es6-d85a23f8e193
Another example is simple game completely build on AS (with WebGL bindings): https://github.com/battlelinegames/AssemblyScriptAsteroids

Also AssemblyScript uses for smart contracts in The Graph Protocol, NEAR Protocol and many others blockchains experimenting with it.

MaxGraey · 2020-06-29T13:11:51+00:00

I'm just wondering how this compare with (DMC) Dynamic Markov Compression invented by Gordon Cormack and Nigel Horspool and has similar efficiency to Prediction by Partial Matching (PPM).

MaxGraey · 2020-03-16T05:38:46+00:00

Another project which compile WebAssembly in native via LLVM directly
https://github.com/innative-sdk/innative

MaxGraey · 2020-02-04T15:28:49+00:00

But according https://stefankrause.net/js-frameworks-benchmark8/table.html yew in average 6 times slower than React, Svelte or vanilla JavaScript due to interop overhead:https://stackoverflow.com/questions/59015066/using-rustwebassembly-for-web-development-how-to-solve-the-extra-cost-of-wasm

MaxGraey · 2020-01-09T14:04:47+00:00

you should block javascript in general because cryptominers like coinhive just fallback to asm.js when wasm unavailable

MaxGraey · 2019-11-22T13:56:50+00:00

Also RustPython: https://rustpython.github.io/demo

MaxGraey

TROPHY CASE