syg

6 ms·

1.
by syg 1y ago
This kind of elision is implemented.
2.
by syg 1y ago
Yeah this is the bug. My bad, will fix.
3.
by syg 2y ago
Only if your implementation holds doubles without boxing them. V8 boxes doubles, but JSC and SpiderMonkey do not.
4.
by syg 2y ago
Well I'm trying to make it suck less.
5.
by syg 2y ago
To be more precise, aligned to whatever size such that you can guarantee field writes that don't tear. Pointer-aligned is a safe bet. 4-byte aligned should be okay too on 64bit architectures if you use pointer compression like V8 does.
6.
by syg 2y ago
The ability to do unordered operations on shared memory is important in general to write performant multithreaded code. On x86, which is very close to sequentially consistent by default (it has something called TSO, not SC), there is less o
7.
by syg 2y ago
Author here. I hear your feedback about unsafe blocks. Similar sentiment is shared by other delegates of the JS standards committee. The main reason it is there today is to satisfy some delegates' requirement that we build in guardrail
8.
by syg 4y ago
Exactly right. `arr[-1]` means `arr["-1"]` and already does something.
9.
by syg 6y ago
WeakRef and FinalizationRegistry will ship in Chrome 84.
10.
by syg 9y ago
Indeed it's a semantic change. Are you saying you'd like that change to be proposed separately? That can't be done for the text format for the obvious compat reasons. It also has very little value on its own, as it is only on
11.
by syg 9y ago
Early error behavior is proposed to be deferred (i.e. made lazy), not skipped. Additionally, it is one of many things that require frontends to look at every character of the source. I contend that the text format for JS is no way easy to i
12.
by syg 9y ago
The gzip point aside (which is not an apples-to-apples comparison as gzipping a big source does not diminish its parse time), I see the response of "JS devs need to stop shipping so much JS" often. My issue with this response is t
13.
by syg 9y ago
Please do not disparage an entire committee because you disagree philosophically with one proposal in it.
14.
by syg 9y ago
This is important, as there seems to be a lot of misunderstanding in this thread. What's proposed is structural compression of JS with JS-specific bits to speed things up even more. What's proposed is not compiled JS, in that th
15.
by syg 10y ago
The current draft is available at http://tc39.github.io/ecmascript_sharedmem/shmem.html The two strengths provided by the model are sequentially consistent atomics and something between the strengths of C++'s non-
16.
by syg 10y ago
Shu here. I'm the person drafting the memory model for the SharedArrayBuffer spec, and as Dave says, it'll be the basis for the wasm story as well. Lars Hansen deserves most of the credit for the actual spec -- I'm just doing
17.
by syg 12y ago
The slowness of functional methods like .map and .forEach for a time was due to their not being self-hosted. Since then, both V8 and SpiderMonkey self-host them, and bz has posted some numbers below [1]. But perf problems are more numerous
18.
by syg 14y ago
I actually don't think we're sharing any code with Gordon. But yes, the name is this obscure transitive-closure reference: (Adobe) Flash -> (Flash) Gordon -> (Gordon) Shumway.
19.
by syg 14y ago
To be more precise, JITs on top of JITs. :) We have both an interpreter for ActionScript bytecode as well as a compiler that compiles that bytecode method-at-a-time to JavaScript using a restructuring approach like emscripten's relooper. Di
20.
by syg 14y ago
There's a CoffeeScript dialect with those features for use optionally. It also emits the typed array-style of JS code, though.