Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you don't need Rust and WASM to speed up your JS

mrale.ph

Post reply on HN
Print view View original

121–130 of 186 posts

Re: Maybe you don't need Rust and WASM to speed up your JS

#121

Post by vanderZwan »

ridiculous_fish wrote: post #108
vanderZwan wrote: post #101

Earlier quoted context omitted.

> monomorphisation trick Here's a crazy thing I recently learned: apparently monomorphism isn't just "object with identical keys", apparently (at least in Chrome), the order in which you declare those keys matters . According to this presentation from 2015[0], adjusting the following lines in the Octane/Splaytree benchmark so that node.left and node.right are always assigned in the same order resulted in 15% better p…

Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).

Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order.

Although I suppose you're already required to have two separate hidden classes to distinguish these two kinds of objects anyway.

> with a bizarre exception for arrays

Wow, you weren't joking with how bizarre this gets:

    var a = {};
    var b = {};
    a.a = 0;
    a.b = 1;
    a[0] = 0;
    a[1] = 1;
    b.b = 1;
    b.a = 0;
    b[1] = 1;
    b[0] = 0;
    Object.keys(a); // Array [ "0", "1", "a", "b" ]
    Object.keys(b); // Array [ "0", "1", "b", "a" ]
PS: Thanks for making a great shell :)

Re: Maybe you don't need Rust and WASM to speed up your JS

#122

Post by kibwen »

abritinthebay wrote: post #114
kibwen wrote: post #42

Earlier quoted context omitted.

The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).

They will diverge about as much as JS does, that will hardly be a surprise

I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.

Re: Maybe you don't need Rust and WASM to speed up your JS

#123

Post by virtualwhys »

Too wrote: post #17
lmm wrote: post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

TypeScript, while interesting, isn't so great if you're coming from an expression based language (i.e. where everything is a value).

That you have to return from statements is such a flow-breaking PITA, one that leads to ugly, verbose code. switch is particularly painful in this regard, would be wonderful to write `let foo = switch (x) { case ... }`, but no, it's a statement, not a value.

Also, structural typing has its strengths, but equality is not one of them. In order to generate a nominal type you have to hack in a private class member (what they call "branding"). This makes newtype/value class wrappers needlessly verbose.

TS feels somehow like a Java/Javascript hybrid with some more advanced type system features (e.g. union types) mixed in. Saying that, editor support (VS Code) and JS interop are pretty amazing.

Re: Maybe you don't need Rust and WASM to speed up your JS

#124

Post by hitekker »

mraleph wrote: post #78
hitekker wrote: post #54

Irrelevant and maybe a bit small-minded, but the font of the article is too squished to be pleasantly readable.

Not irrelevant. Question for you, is this more legible: https://twitter.com/mraleph/status/965686742614462466 I can update CSS if that helps. UPD. Updated CSS to use non monospace fonts for the body.

This is better by far. I'd be interested if there's a better combination of code + paragraph font, but otherwise the only other minor adjustment I'd make is increasing the padding / margins between text and code.

Thanks for taking criticism in a healthy way.

Re: Maybe you don't need Rust and WASM to speed up your JS

#125

Post by rmrfrmrf »

virtualwhys wrote: post #123
Too wrote: post #17

Earlier quoted context omitted.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

TypeScript, while interesting, isn't so great if you're coming from an expression based language (i.e. where everything is a value). That you have to return from statements is such a flow-breaking PITA, one that leads to ugly, verbose code. switch is particularly painful in this regard, would be wonderful to write `let foo = switch (x) { case ... }`, but no, it's a statement, not a value. Also, structural typing has…

As someone who loves JS, your post sort of made me more comfortable with WASM as a competitor. JS is currently under seige by competing factions of OOP and FP that are constantly at odds with one another. Perhaps if these two groups had the WASM bone thrown to them, they'd leave TC39 the hell alone and let actual JS devs develop the language in its own right.

Re: Maybe you don't need Rust and WASM to speed up your JS

#126

Post by rmrfrmrf »

devit wrote: post #28
Too wrote: post #17

Earlier quoted context omitted.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type. I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't natur…

Spoiler: no type systems guarantee anything. At least JS doesn't have the audacity to make false promises about bug prevention.

Re: Maybe you don't need Rust and WASM to speed up your JS

#127

Post by staticassertion »

Awesome. I think it makes a lot of sense to explore new algorithmic approaches before choosing to reimplement in a new language - and thankfully these are not mutually exclusive.

To those saying "these are implementation defined optimizations" etc - you do the same exact thing in rust. I know some rust code is 'fast' and some is 'slow' and I have to understand rust and to some extent the state of llvm + rust. This is simply part of writing fast code, no matter the platform or language.

Nice writeup!

Re: Maybe you don't need Rust and WASM to speed up your JS

#128

Post by Pxtl »

greenhouse_gas wrote: post #39

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back th…

It's like SQL servers all over again, where an infinite plethora of rumours and received wisdom and magical thinking guides performance optimization because it's such a goddamned black box that will optimize your query however it sees fit.

Re: Maybe you don't need Rust and WASM to speed up your JS

#129

Post by alangpierce »

catnaroek wrote: post #104
alangpierce wrote: post #51

Earlier quoted context omitted.

When you say ADTs, do you mean algebraic data types or abstract data types? My impression has been that TypeScript is quite good at algebraic data types (i.e. tagged unions). You need to use normal conditionals like if/switch or your own function instead of syntactic support for pattern matching, but IMO the static analysis makes it work out pretty well.

It is good at neither. Union types and sum types are veeery different from each other.

To be clear, I was talking about tagged unions; TypeScript supports both tagged and untagged unions[1]. My understanding is that "tagged unions" and "sum types" are the same thing, and Wikipedia[2] seems to agree.

[1] https://www.typescriptlang.org/docs/handbook/advanced-types....

[2] https://en.wikipedia.org/wiki/Tagged_union

Re: Maybe you don't need Rust and WASM to speed up your JS

#130

Post by lkbm »

greenhouse_gas wrote: post #39

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back th…

In this case, it looks like he's optimizing for Firefox and Chrome--he mentions benchmark results from both and also running into a SpiderMonkey optimization that was causing problems.

That does leave out Safari, Edge, Opera, and probably some other obscure browsers, and doesn't help with your point about future engine changes potentially breaking the optimizations.

Post reply on HN