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

141–150 of 205 posts

Re: 4x Smaller, 50x Faster

#141

Post by ben-schaaf »

knubie wrote: post #130
cjcampbell wrote: post #40

Earlier quoted context omitted.

As an oversimplified example, in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer (though one could probably think of ways to optimize this for the use case). Excess comes either in the form of unnecessary (relative to mutable) memory usage and/or CPU cycles necessary to support high-levels of garbage collection.

> in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer That’s actually not how clojure’s immutable data structures work. They use structural sharing, so only the portion that changes (roughly) needs new memory allocated, and only the parts that changed get garbage collected, so it is a bit more efficient than that.

You can't deallocate part of a frame buffer, it's a single allocation. Unless every pixel is individually allocated, which would clearly be insane.

Re: 4x Smaller, 50x Faster

#142

Post by rodamaral »

atoav wrote: post #51

While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.

asciinema is for showing off, specially TUI interfaces.

Re: 4x Smaller, 50x Faster

#144

Post by azakai »

gpderetta wrote: post #97
fulafel wrote: post #47

Earlier quoted context omitted.

Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single static assignment" intermediate-representation form that is mainstream in low level language compilers. But SSA form isn't as good as having the original program expressed immutably, because you get false or incidental data dependencies if the compiler has to conse…

Talking about parallelization opportunities is a bit pointless when you need 50 cores to match the performance of the single threaded code (in the best case, assuming perfect scaling).

Fair enough, but parallelism isn't just about cores since SIMD can also help. Also, immutability doesn't just help through parallelism, it also allows other things (as another example, avoiding redundant work like loads of an immutable field and computations on them).

Would that help with a huge 50x difference? Maybe not, but the point is that evaluating the benefits of immutability on a VM that does not optimize it - JS VMs - is not relevant. (And that 50x might also be caused by other limitations of JS VMs and not immutability at all, like say deopts.)

Re: 4x Smaller, 50x Faster

#145

Post by fulafel »

gpderetta wrote: post #97
fulafel wrote: post #47

Earlier quoted context omitted.

Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single static assignment" intermediate-representation form that is mainstream in low level language compilers. But SSA form isn't as good as having the original program expressed immutably, because you get false or incidental data dependencies if the compiler has to conse…

Talking about parallelization opportunities is a bit pointless when you need 50 cores to match the performance of the single threaded code (in the best case, assuming perfect scaling).

I disagree - lots of compiler work is done on languages that aren't best in class for high performance work. Look at all the effort that people are putting into making Python faster. And indeed JS itself, it wasn't always this fast. High level language users live by "There's more to life than increasing its speed" and then if they take off, people come work on performance and make them faster.

Also let's not forget that this was already "fast enough" for a long time before the 50x rewrite.

Re: 4x Smaller, 50x Faster

#146

Post by Ar-Curunir »

ncmncm wrote: post #46
rtpg wrote: post #32

Earlier quoted context omitted.

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…

Won't make them slower, anyway. There are often performance bottlenecks you didn't know about, and had blamed on database (or whatever) interaction overhead. It will never feel worthwhile to dig into each candidate, because any payback seems too unlikely. Not having left scope for such bottlenecks means you can be confident they are not there. Re-implementing once is a lot less work than diving into each possible bot…

> Any optimization you could do in Rust is probably easier in C++, and also easier to find maintainers for.

At least the first part is not necessarily true. E.g., in C++, you might make defensive copies, whereas in Rust the lifetime system will track things for you.

Re: 4x Smaller, 50x Faster

#147

Post by __s »

peoplefromibiza wrote: post #68
cjcampbell wrote: post #40

Earlier quoted context omitted.

As an oversimplified example, in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer (though one could probably think of ways to optimize this for the use case). Excess comes either in the form of unnecessary (relative to mutable) memory usage and/or CPU cycles necessary to support high-levels of garbage collection.

that's only because js is "stupid" if you have the string "hello" and somewhere else "hello world" you can retain only one copy of "hello" because it's guaranteed it won't change. but js vm it's not smart enough for that.

You're wrong, JS has immutable strings & so VMs use ropes to make mutable usage & slicing fast

https://gist.github.com/mraleph/3397008 https://twitter.com/rauschma/status/1269964154275799041

Re: 4x Smaller, 50x Faster

#148

Post by knubie »

ben-schaaf wrote: post #141
knubie wrote: post #130

Earlier quoted context omitted.

> in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer That’s actually not how clojure’s immutable data structures work. They use structural sharing, so only the portion that changes (roughly) needs new memory allocated, and only the parts that changed get garbage collected, so it is a bit more efficient than that.

You can't deallocate part of a frame buffer, it's a single allocation. Unless every pixel is individually allocated, which would clearly be insane.

I'm explaining how clojure's data structures are different from OP's screen buffer example.

Re: 4x Smaller, 50x Faster

#149

Post by __s »

ben-schaaf wrote: post #141
knubie wrote: post #130

Earlier quoted context omitted.

> in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer That’s actually not how clojure’s immutable data structures work. They use structural sharing, so only the portion that changes (roughly) needs new memory allocated, and only the parts that changed get garbage collected, so it is a bit more efficient than that.

You can't deallocate part of a frame buffer, it's a single allocation. Unless every pixel is individually allocated, which would clearly be insane.

But if your frame buffer is text, you can store the text in a rope data structure like JS vms do

So you don't necessarily have an allocation for every single character, but you're still able to share memory between buffers

I've implemented a game engine with immutability (makes for fast cloning in AI search) where much of the game state is shared between clones. With reference counting it also means if there's a unique reference being modified then no copy is made. This same trick is used by Python to optimize string concatenation

Re: 4x Smaller, 50x Faster

#150

Post by Scarbutt »

Cthulhu_ wrote: post #74
ajaxexact wrote: post #39

> ClojureScript is not that easy to integrate with the JS ecosystem. I know, there’s been a lot of improvements done in this space over the years, and I’m sure someone will immediately point me to relevant docs, but it’s still the extra mile you need to go when compared to regular JS codebase This always kills me. Clojure(script) is one of the neatest languages I've ever used, but it is just such a pain to work with.…

I just wonder why not just write straight JS? Adding a layer on top just means you have more complexities and steps to worry about. And clearly, in this case it was a big compromise in terms of performance and bundle size.

Yep, the author learnt their lesson. I bet they won't be using cljs again, not even for non-performant apps.
Post reply on HN