Live data from Hacker News

4x Smaller, 50x Faster

blog.asciinema.org

21–30 of 205 posts

Re: 4x Smaller, 50x Faster

#21
post #18

Earlier quoted context omitted.

I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.

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.

I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy

Re: 4x Smaller, 50x Faster

#22
post #14

Earlier quoted context omitted.

I've always thought of immutability as great for situations where you want to "explore" (clone complex current state and go do some "what if"), need internal transactions, or allow time travel (snapshot/undo/redo) - situations where the state sharing is both efficient and feels "natural". Also if the data/history are relatively small compared to the available memory it's a fine default that generally leads to "nicer"…

Video can be played backwards and forwards, can be sought, or jumped to a particular point in time. It fits well with the "time travel" benefit of immutable data structure. The author mentioned it was extremely easy to implement some kind of a checkpoint or key framing with immutability. That's exactly using immutability to its strength.

The downside of immutability is the sheer volume of data (in the form of pixels) that needs to be pushed around. A single 4k frame is 8.3 million pixels, so you are looking at over 30MiB of data for 32-bit color, and you gotta push 30, maybe 60 of those a second. Maybe if you have a really good garbage collector (or a custom one, because frames are all the same size) you can get away with allocating that much data and freeing it every second. But that doesn't free you from the fact that you are not utilizing hardware caches well; you don't get good spatial locality at the hardware level unless you reuse the same physical pages of memory for every frame. And you can basically only do that if you have a mutable design.

Re: 4x Smaller, 50x Faster

#23
post #2

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

This is an application where the goal is to squeeze every last drop of performance possible out of the processor. The "every last drop of performance" crowd has never been the source of the "immutability hype". Your comment is dismissive of many domains of programming - immutable didn't become a thing because others weren't as enlightened as you.

Re: 4x Smaller, 50x Faster

#24
post #3
post #2

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

mutability is a data structuring virtualization but i'd just as much suspect the runtime virtualization. that the bundle used to be 570kB isnt an immutability issue. itcs that clojurescript drags in a whole clojure runtime, a new virtualization layer atop the js runtime. that, to me, is the most likely suspect. that said, for sure, short tbeow away high gc allocation patterns are generally not good. at work there's a…

Clojure solves these issues with unneeded garbage creation in algorithms with the transducers functions.

And you can of course just use java objects whenever you want.

Re: 4x Smaller, 50x Faster

#25

Earlier quoted context omitted.

Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.

You can’t pause and rewind or skip ahead in a gif in any of the major browsers.

Or copy/paste text.

Re: 4x Smaller, 50x Faster

#26
post #18

Earlier quoted context omitted.

I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.

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 may call functional programmers who prefer immutable data structures lazy because we want to actually understand what we create, but I don't see how the 10 billion layers of abstractions and state duplications somehow end up making better software.

Re: 4x Smaller, 50x Faster

#27

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! One nit I have about SolidJS documentation is that it doesn't have a clear path for "migrating from React" which I take it is probably actually important to you given how similar SolidJS looks to React and how much faster it claims to be. Also might be good to include a section on how to interop with existing React libraries -- even if the answer is that you can't.

And it might be worth putting in your HN profile that you are the creator of SolidJS. :)

Re: 4x Smaller, 50x Faster

#28
post #5

Earlier quoted context omitted.

This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.

How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?

Pretty bog standard behavior for a compiler backend translating immutables in IR. Including a runtime compiler into app code is the next stage in the evolution of cycle burning leetness.

Re: 4x Smaller, 50x Faster

#29
post #2

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

What is the connection between mutability and excessive hardware usage?

Re: 4x Smaller, 50x Faster

#30
Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library.

I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.

Post reply on HN