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

4x Smaller, 50x Faster

blog.asciinema.org

Post reply on HN
Print view View original

181–190 of 205 posts

Re: 4x Smaller, 50x Faster

#181

Post by gwern »

moonchrome wrote: post #136

It's funny how it starts out with "immutability is really fast and GCs are soo good" and ends up with "rewriting everything in unmanaged code made it 50x faster". Similar how "Ruby and Python interpreters are slow but webapps are IO bound anyway so it doesn't matter" to "how can I get this to handle more than x req/sec, can we get a JIT to speed up our dog slow backend".

One of the arguments high-level language proponents always made was that you could do exploratory programming and prototyping and develop your systems in nice easy high-level languages, and then FFI out or reimplement parts in the painfully low-level languages when you discover you need their performance.

asciinema prototyped and worked out their design, and discovered it needed more performance. And then it got it. Sounds like a success story to me.

Re: 4x Smaller, 50x Faster

#182

Post by unnouinceput »

fnordsensei wrote: post #124
unnouinceput wrote: post #114

I get it, Clojure bad, Rust good. Yeah, absolutely nothing to do with the brain in the chair.

More like, know when to apply Clojure and when to apply Rust. Having written a ClojureScript app with a Rust/WASM component, for me it's very clear that they have different strengths that can be complementary. That the author dropped CLJS along with React is fair enough, in my opinion. The CLJS ecosystem is pretty React-centric.

Listen, Clojure isn't born yesterday, it's around for quite some time and it's a mature product. And when you have mature products that are still in development and people behind it do evolve it then you also get all kind of optimizations.

I would expect the system maybe to be slower like 20 to maximum 50% (as in Rust to be maximum 2 times faster) but 50 times faster?. That's already brain in the chair mistake.

Re: 4x Smaller, 50x Faster

#183

Post by xfer »

keymone wrote: post #168
michaelcampbell wrote: post #154

Earlier quoted context omitted.

It sounds like that's exactly what happened to the GP.

GP didn’t pick JS for a rewrite either, so yes, I’m pretty sure GP is with me on that.

Yes they did, maybe take a look at the repo, the core vt layer is rust everything around it is in js(it's not cljs, you might ponder why not).

Re: 4x Smaller, 50x Faster

#184

Post by fnordsensei »

unnouinceput wrote: post #182
fnordsensei wrote: post #124

Earlier quoted context omitted.

More like, know when to apply Clojure and when to apply Rust. Having written a ClojureScript app with a Rust/WASM component, for me it's very clear that they have different strengths that can be complementary. That the author dropped CLJS along with React is fair enough, in my opinion. The CLJS ecosystem is pretty React-centric.

Listen, Clojure isn't born yesterday, it's around for quite some time and it's a mature product. And when you have mature products that are still in development and people behind it do evolve it then you also get all kind of optimizations. I would expect the system maybe to be slower like 20 to maximum 50% (as in Rust to be maximum 2 times faster) but 50 times faster?. That's already brain in the chair mistake.

If we were talking about Clojure, I would agree that 50x would indicate that something is off. But since we're talking ClojureSCRIPT, it doesn't surprise me.

Although, fair enough, it's a rewrite, and the author has the benefit of experience with the first implementation when writing this one. A second implementation in ClojureScript would likely have been faster than the first one. But 50x faster? Unlikely.

> Is WebAssembly faster than Javascript?

> Yes - about 50 times faster in my experience.

https://www.quora.com/Is-WebAssembly-faster-than-Javascript

Just as a data point that the author isn't the only one to see this type of performance increase.

I expect that it isn't 50x across the board over JS, but that it would vary wildly across the board, including being slower if you're doing something trivial and end up paying more in serialisation to and from WASM than you gain in speed.

Re: 4x Smaller, 50x Faster

#185

Post by alvarlagerlof »

ano88888 wrote: post #42
ryansolid wrote: post #16

It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.

congrats on the performance. But I just hope that React will quickly catch up and improve in terms of speed & performance. It is really tough to learn a new framework every few months.

Going to be very different in React 18

Re: 4x Smaller, 50x Faster

#186

Post by rightbyte »

devwastaken wrote: post #43
josephg wrote: post #18

Earlier quoted context omitted.

I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.

You cannot physically click faster than about 100ms in reaction to a UI. A proper application that isn't 100x less efficient will never be noticed by you unless you go out of your way to measure it. Stable software is more important than unusable fast. "Lazy devs", Work on a team in C graphic code and watch nothing get done.

Ever played a FPS game with 100 ms ping? Then compare that feeling to LAN latency.

Re: 4x Smaller, 50x Faster

#187

Post by keymone »

xfer wrote: post #183
keymone wrote: post #168

Earlier quoted context omitted.

GP didn’t pick JS for a rewrite either, so yes, I’m pretty sure GP is with me on that.

Yes they did, maybe take a look at the repo, the core vt layer is rust everything around it is in js(it's not cljs, you might ponder why not).

Well sure, but the important parts aren’t in JS. I can understand the argument that to provide npm library you may need to touch that garbage of a language, I’m just happy others do it for me.

Re: 4x Smaller, 50x Faster

#188

Post by vidarh »

EdwardDiego wrote: post #133
vidarh wrote: post #64

Earlier quoted context omitted.

If it's a video, it does noe exist for me. I could watch them, but I have better things to watch if I want to watch something. So I move on to something else.

Most of us read far faster than someone umming and ahing through a presentation in a monotone can speak. At the very least, give us a frigging transcript.

A transcript would be great, but it struck me in these days of deep learning it's just a question of time before someone does a "speedup" option for videos that instead of just increasing the speed of the video, combines that with "smart" cuts like removing umming and ahing and unnecessary dead space, and tries to apply other simplifications as well (I'd still prefer text, but I'm sure there'd be an upside for people who like video).

And imagine even a more aggressive "video summarizer" generating articles from videos with interspersed screenshots or brief video segments where they matter for the understanding...

Re: 4x Smaller, 50x Faster

#189

Post by derefr »

rtpg wrote: post #32
lxe wrote: post #2

The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.

What a boring takeaway from this. Beyond the fact that the immutable data structures proposed by Clojure/script tend to perform very well in a lot of "normal" cases (and in a lot of normal web-app workflows your stuff is immutable, like "query then display the result from an API"), at least to me it feels like asciinema is a very good example of a case where you have tougher-than-average performance requirements. Not…

On the other hand, rewriting the DBMS itself in Rust might. Especially if the DBMS was originally written in Clojure (see: Datomic.)

Re: 4x Smaller, 50x Faster

#190

Post by derefr »

ncmncm wrote: post #170
pohl wrote: post #162

Earlier quoted context omitted.

> Any optimization you could do in Rust is probably easier in C++ That's kind of funny in light of the history that certain optimizations in web layout engines were attempted, unsuccessfully, in C++ multiple times and ultimately they invented Rust to make them easier.

That is how the marketing goes, anyway. The facts on the ground probably have more to do with improvements to the C++ code being obliged work as deltas against existing C++ code, where the Rust code was a complete re-implementation, thus not constrained. Both C++ and Rust are today different languages from when that project ran.

Another subtle consideration is that with long-lived, highly-backward-compatible languages like C++, you'll have a bunch of people on your project who still write C++ like it was ten or twenty years ago (because that's when they learned it), and so bring down the code quality of your project. Whereas choosing a new language (like Rust at the time) means that everyone who claims to be able to write it at all, is working from the same, recent set of language idioms.
Post reply on HN