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

171–180 of 205 posts

Re: 4x Smaller, 50x Faster

#171

Post by seniorivn »

aasasd wrote: post #163
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".

> "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" Turns out that if you write business logic with abandon, you end up with a lot of business logic. Personally I wish that Python, Ruby and the ilk all get replaced with Lua, but also that Lua gets a proper `null`.

and array numbering from zero

Re: 4x Smaller, 50x Faster

#172

Post by nojito »

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

Fable is becoming the best way to compile to JS.

https://fable.io/

Re: 4x Smaller, 50x Faster

#173

Post by ncmncm »

paulgdp wrote: post #156
ncmncm wrote: post #46

Earlier quoted context omitted.

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++" I think this feeling comes from the fact that it takes longer to learn the basics of Rust compared to C++. However, once one has learned C++ or Rust to a reasonable level, I would argue that Rust is actually easier to use. This is not the same thing but many people make this claim.

Each is easier than the other, depending on where you look and where you come from.

But it is a fair bet that changes to C++ code to implement a point performance optimization will be smaller than the same sort of change would be for Rust code. For the latter, you are likely to need to re-architect that part of the system some to get your optimization and still satisfy the borrow checker. Having a borrow checker that demands satisfaction is a virtue, but there is no denying it adds cost in the small, where we're talking about, notwithstanding that such cost may be paid back at the system level.

Re: 4x Smaller, 50x Faster

#174

Post by smrtinsert »

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

It's almost like one side had the ability to say "we told you so" and they never bothered to :)

Re: 4x Smaller, 50x Faster

#175

Post by mmastrac »

seniorivn wrote: post #171
aasasd wrote: post #163

Earlier quoted context omitted.

> "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" Turns out that if you write business logic with abandon, you end up with a lot of business logic. Personally I wish that Python, Ruby and the ilk all get replaced with Lua, but also that Lua gets a proper `null`.

and array numbering from zero

This is why I've never been able to do anything serious with Lua. Small thing, but fatal for me.

Re: 4x Smaller, 50x Faster

#176

Post by ncmncm »

Ar-Curunir wrote: post #146
ncmncm wrote: post #46

Earlier quoted context omitted.

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.

Thus, "probably".

Re: 4x Smaller, 50x Faster

#177

Post by titzer »

sickill wrote: post #103
titzer wrote: post #22

Earlier quoted context omitted.

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…

That's not how asciinema-player works though. The player internally represents the terminal buffer as a grid of characters. So for 80x24 terminal you have 80*24=1920 grid cells, each keeping a unicode char + color attrs. When rendering the adjecent cells of each line are grouped by their common color attrs, resulting in (usually) a small number of span elements with text and proper style/class. You can see this in ac…

Sure, if you don't break it down to individual pixels, the data is way less. Ultimately, getting a well-performing GC is finding enough idle/spare/background cycles to scan memory and recycle it at a greater rate than allocation. If the GC falls behind then inevitably you are going to end up with a big pause. I don't think there's enough memory bandwidth to decode 4k video the naive way, but a small terminal will probably be OK. That said, it's still less efficient than just poking the bytes in memory.

Re: 4x Smaller, 50x Faster

#178

Post by ryansolid »

com2kid wrote: post #164
skrebbel wrote: post #100

Earlier quoted context omitted.

Wow, I just read about Solid for the first time, and I'm very impressed at the API design. I love how it's actually a fully reactive data flow thing, but it looks and feels like React Hooks. The other reactive/observable-based frameworks I've seen (eg Cycle) very much put the observable streams center piece, and I always felt that was distracting, and that nuances about how the underlying observable stream library wo…

> but it looks and feels like React Hooks. I am confused about why this is a positive. React Hooks are the reason why I want to stop using React. They are confusing and seemingly magical, compared to lifecycle methods that make a ton of sense. While I agree they can make complex things easier, they are also incredibly easy to get wrong, as they are order dependent. Reading the Solid landing page, what I see is "Solid…

Reactivity like this predates React Hooks. It doesn't have the hook rules/stale closures etc... No dependency arrays, useRef, or useCallback. It's a very powerful model and very different. The similarities are surface level but aren't without benefit. Composable declarative data patterns, read/write segregation, traceable state dependencies.

Some people position it more like, "Solid makes Hooks the way they should have been in React". Personally understanding how React works this doesn't make sense. But I think it might be helpful for people just approaching the framework.

Re: 4x Smaller, 50x Faster

#179

Post by qwertygnu »

nawgz wrote: post #34
qwertygnu wrote: post #33

Went to https://asciinema.org/ and clicked the demo video. I'm a bit confused because it looks like future lines are being rendered after the cursor while lines are being typed. Is that...correct? It looks like either a blatant bug in their product (that they're displaying on their homescreen demo!) or on purpose for some reason I can't find.

You made me click through, and I could not recreate. Is this the new viral marketing? I truly just was reverse psychology'd

not a plant I swear!

Re: 4x Smaller, 50x Faster

#180

Post by qwertygnu »

sickill wrote: post #111
qwertygnu wrote: post #33

Went to https://asciinema.org/ and clicked the demo video. I'm a bit confused because it looks like future lines are being rendered after the cursor while lines are being typed. Is that...correct? It looks like either a blatant bug in their product (that they're displaying on their homescreen demo!) or on purpose for some reason I can't find.

Feel free to report a bug here https://github.com/asciinema/asciinema-player/issues/new (including browser version, OS would help a lot). Btw, it's not a product, just a side, hobby project of mine.

Ohhh weird, I thought it was a literal mp4 on the front page haha. Must be one of my browser extensions messing with it!
Post reply on HN