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

61–70 of 205 posts

Re: 4x Smaller, 50x Faster

#61

Post by vladvasiliu »

qwertox wrote: post #57
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.

It's a lean-back experience, like the difference between a book and a video. It does have its perks.

I think it can work well as a demo, but I wouldn't call that documentation.

If you need to find something out, having to wait or randomly click through a video is extremely frustrating.

Re: 4x Smaller, 50x Faster

#62

Post by niels_bom »

lxe wrote: post #2

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

This talk by Richard Feldman about Roc (a new language) goed into why immutable does not necessarily mean slow and given enough attention can mean higher performance in certain cases: https://youtu.be/vzfy4EKwG_Y

Re: 4x Smaller, 50x Faster

#63

Post by laurent92 »

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.

I hope React won’t have all of those gotchas which make a good year of experience necessary when training a junior, until he migrates to a job that pays for his upgraded skills… Cost of skills is a thing.

Re: 4x Smaller, 50x Faster

#64

Post by vidarh »

vladvasiliu wrote: post #61
qwertox wrote: post #57

Earlier quoted context omitted.

It's a lean-back experience, like the difference between a book and a video. It does have its perks.

I think it can work well as a demo, but I wouldn't call that documentation . If you need to find something out, having to wait or randomly click through a video is extremely frustrating.

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.

Re: 4x Smaller, 50x Faster

#65

Post by comma_at »

josephg wrote: post #38
askonomm wrote: post #26

Earlier quoted context omitted.

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.

I agree - I think having 10 billon layers of abstraction is worse for everyone. It’s buggier, more expensive to make and (ironically) often slower in practice anyway; because you can’t optimize what you can’t understand. Java style OO has a lot to answer for. Functional programming is great. What’s not great is loading the entire closure VM environment into my browser - resulting in the software running (in this case…

> What’s not great is loading the entire closure VM environment into my browser

There's no VM in clojurescript, it compiles to JS, it is tree-shaken and heavily optimized and minified through Google's Closure compiler.

> resulting in the software running (in this case) 50x slower

The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives. The same can be done in clojurescript or javascript.

I think this is a common misunderstanding, that's why I'm reacting. Nobody claims immutable data structures to be the silver bullet. Computation-heavy parts need to be done in low level code and with primitive types.

Re: 4x Smaller, 50x Faster

#66

Post by littlestymaar »

titzer wrote: post #22
kccqzy wrote: post #14

Earlier quoted context omitted.

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 an…

This comment is completely off: obviously asciinema didn't store each individual pixel in its data structure. That would be a completely stupid thing to do even for a regular data structure instead of an immutable one…

Re: 4x Smaller, 50x Faster

#67

Post by peoplefromibiza »

lxe wrote: post #2

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

or maybe is JavaScript hype and the make concurrent programming impossible that it's finally dying.

Immutability is alive and well, it's simply a matter of js runtime not supporting it, because the developers thought "one thread ought be enough for anybody".

Re: 4x Smaller, 50x Faster

#68

Post by peoplefromibiza »

cjcampbell wrote: post #40
bsg75 wrote: post #29

Earlier quoted context omitted.

What is the connection between mutability and excessive hardware usage?

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.

Re: 4x Smaller, 50x Faster

#69

Post by atoav »

qwertox wrote: post #57
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.

It's a lean-back experience, like the difference between a book and a video. It does have its perks.

It has, if the thing you are showing fits the media. If you show the different flags of ls without explaination you would be better of just showing me the printout of ls -h

If you are showing off some beautiful TLI, an interactive prompt or ascii animations, this is the perfect tool.

As someone who works in film: film also doesn't lend itself to everything. Certain internal observations that work great in literature would be unwatchable on film etc.

Or to take it to the extreme: you don't expect the overview of an database to be experimental performance video art.

Re: 4x Smaller, 50x Faster

#70

Post by w-m »

The blog post mentions that seeking to any point works very well without having to create keyframes, just from the speed of the implementation. It would be great if the progress bar could actually respond to click-and-drag events, to quickly find a specific location.
Post reply on HN