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

161–170 of 186 posts

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

#161

Post by carlmr »

pjmlp wrote: post #158
carlmr wrote: post #156

Earlier quoted context omitted.

>but C++ currently offers better paths for understanding and utilizing existing code or getting a job using it I wouldn't say this is entirely wrong, but proper cross-platform package and test management with Cargo is a reason alone that utilizing existing code is waaay easier in Rust. C++ has more existing code though, so they might hit your niche needs better.

Here something like conan might finally win the hearts of C++ devs, but it is still pretty much in the beginning. In what concerns Windows development, NuGET and vcpkg are already a big improvement.

NuGet is pretty good, I've only used it with C#/F# though.

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

#162

Post by pjmlp »

Pxtl wrote: post #128
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.

Which is why profilers exist.

Writing code based on gut feeling and urban myths was never a good idea.

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

#163

Post by [deleted] »

sametmax wrote: post #153
kjksf wrote: post #94

Earlier quoted context omitted.

Actually, Google tried to make Python faster, with Unladden Swallow project. They failed miserably. And several other projects failed miserably at the same thing as well. Either way, speed was not the main reason they created Dart. Dart was designed for writing large web apps. Dart's top design constraints was good interop with JavaScript meaning transpilation of Dart to decent JavaScript and consumption of existing…

Pypy is proof that you can speed up Python considerably. And it's written in Python. Imagine what could be achieve if one would write something like that in, say, Rust ? My guess is that they didn't invest anywhere near the resources on unladden shallow (which was probably a side project) than they invested on chrome vm (which was a core project). Actually, I spend quite a lot of time on the Python mailling list, and…

[deleted]

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

#164

Post by vanderZwan »

deathanatos wrote: post #148
ridiculous_fish wrote: post #108

Earlier quoted context omitted.

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

TIL. For those like me for which this is new, this was apparently a change in the ES 2015 / ES 6 version of the standard. See: https://stackoverflow.com/questions/5525795/does-javascript-... The order is only sometimes guaranteed, of course, because JavaScript. (But critically, for this discussion, it is important that it is sometimes guaranteed, because it forces that information to be stored by the VM.)

I feel so justified in adding this guard in my compression pre-processor[0] code, even though I never had a bug without it:

    // the keys of an object
    export function keysOf(obj) {
      let keys = Object.keys(obj);
      keys.sort();
      return oneOf(keys);
    }
Context: the rest of the code takes an object representing a schema, and creates two functions. One that can turn any object fitting that schema into an array, with positions indicating which key they originally belonged to, and another one that can reverse the process.

Could this also explain why I have no consistent order of properties when viewing state with the Redux dev-tools? Instead of Object.assign I use my own simplified merge code[1]. Maybe if I also make that use a sorted set of keys, the devtools will become more consistent in their presentation (and it might result in more consistent hidden classes too).

[0] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...

[1] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...

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

#165

Post by Cthulhu_ »

anp wrote: post #25

I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…

And yet, which is better; finding someone that has the skill and knowledge needed to optimize this (e.g. bring in a consultant), or rewrite the thing - hundreds if not thousands of lines of code and working hours being replaced by even more. And not just rewrite it, but (IMO) replacing it with more complicated technology (additional steps required to make it usable, additional skills needed to work on the project).

I think people think too lightly of rewrites. Actually, I'd even argue that in some cases, rewrites are done because they're easier than actually fixing the problem. Yes, Rust and other languages will give you better performance out of the box, but at what cost?

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

#166

Post by steveklabnik »

b0rsuk wrote: post #144
kbenson wrote: post #89

Earlier quoted context omitted.

It's a cost/benefit type of situation. Learning to optimize JavaScript might cost less, but the benefit is fairly narrow, and may lesson over time (or you may need to pay more in attention and time to keep up with JavaScript VM changes). Rust (or C++) to WASM costs more (if you don't already know the language), but the benefit should stay static and useful over time, and there are many other benefits as well (such as…

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

> As far as I know Rust has just two major success stories right now

Here's a bunch more. Dunno what your definition of "major" is though: https://www.rust-lang.org/en-US/friends.html

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

#167

Post by dhucerbin »

catnaroek wrote: post #134
alangpierce wrote: post #129

Earlier quoted context omitted.

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

> My understanding is that "tagged unions" and "sum types" are the same thing Well, your understanding is wrong. Sum types satisfy a specific universal property, which union types don't.

What specific universal property?

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

#168

Post by pdpi »

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).

Wait what? Since when? That wasn’t the case at all 5 or 6 years ago (I got bitten in the arse by Rhino not implementing it that way)

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

#169

Post by [deleted] »

pdpi wrote: post #168
ridiculous_fish wrote: post #108

Earlier quoted context omitted.

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

Wait what? Since when? That wasn’t the case at all 5 or 6 years ago (I got bitten in the arse by Rhino not implementing it that way)

[deleted]

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

#170

Post by swsieber »

fenomas wrote: post #133
seeekr wrote: post #90

Earlier quoted context omitted.

It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool. Such a tool would give you the benefits you're praising about the W…

JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to. What could a tool like you're describing do that the engines don't do themselves?

Well, for one, the compiler could rearrange key assignment of similarly shaped objects, so that they actually are similarly shaped objects to the JIT .... but that seems like really dangerous territory
Post reply on HN