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

151–160 of 205 posts

Re: 4x Smaller, 50x Faster

#151

Post by gpderetta »

fulafel wrote: post #145
gpderetta wrote: post #97

Earlier quoted context omitted.

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

My issue was specifically with the claim that persistent data structures are great for parallelization.

I have absolutely no issues with efforts to improve single threaded performance of programming languages (and indeed the advances made by JS are remarkable) and I don't believe any language needs to be "As Fast As Cee". But There are other perfectly reasonable languages that are within a small integer factor of C and C++. You do not need to pay a large penalty for ergonomics.

Re: 4x Smaller, 50x Faster

#152

Post by hedora »

JasonFruit wrote: post #137
kazinator wrote: post #108

Earlier quoted context omitted.

I have a here 90 second .gif I made a year ago (demo of a particular Vim syntax highlighting scheme for a commit message format). It contains 930 frames, 10 fps. The resolution is 1200x768. The .gif is 600.0 kilobytes, so the coding density is about 660 bytes per frame. Someone downloading at 3-4KB/s might find the download annoying; on the other hand, it could play back on a 66 MHz 486 DX they found in the dumpster.…

You're clearly more careful with resource consumption than many, then. Many times I've had enough time to start coffee while waiting for a .gif to get through its first pass so I can usefully watch it, using rural satellite from Hughes. We're still using your stuff out here.

Hughes is latency-bound, not bandwidth bound. For it to take that long, they’d have to try really hard. For instance, the map could issue an http[s] request per frame.

Re: 4x Smaller, 50x Faster

#153

Post by hedora »

kevin_thibedeau wrote: post #25
codetrotter wrote: post #17

Earlier quoted context omitted.

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

Or copy/paste text.

FWIW, iOS 15 automatically OCR’s screenshots, so now copy paste works again (even from non-selectable text in apps).

However, most times I have problems with copy paste, it’s not due to gif’s. It’s due to some BS framework thing rendering text in some non-standard way.

Re: 4x Smaller, 50x Faster

#154

Post by michaelcampbell »

keymone wrote: post #134
Cthulhu_ wrote: post #74

Earlier quoted context omitted.

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.

You'd have to torture me before I would make a conscious choice to pick JS over Clojure.

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

Re: 4x Smaller, 50x Faster

#155

Post by hedora »

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…

> Rewriting your CRUD frontend in Rust isn't going to make your DB queries faster

A typical consumer disk can do 1,000,000 IOPS (enterprise is one generation behind, and slower at the moment), with millisecond read and write latencies.

Are there any managed CRUD frontend languages that are fast enough to keep up with that?

(By “keep up”, I mean “be less than half the hardware I provision at scale”)

Re: 4x Smaller, 50x Faster

#156

Post by paulgdp »

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

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.

Re: 4x Smaller, 50x Faster

#157

Post by cryptonector »

fnordsensei wrote: post #83
cryptonector wrote: post #11

Earlier quoted context omitted.

Immutability is a drag if you create lots and lots of referenced state because, e.g., you want to hold on to many snapshots of past state. Immutability done right need not be much worse than mutability. For example, jq's internal value representation is immutable in appearance: - mutations yield new values, - but when the value being "mutated" has only one extant reference then mutation is done in-place, - while when…

> Immutability is a drag if you create lots and lots of referenced state because, e.g., you want to hold on to many snapshots of past state. Isn't it the opposite? If you want to hold on to many referenced states at the same time, an immutable data structure should provide less overhead than a mutable one, due to structural sharing.

A performance drag. Let's say you have an app that for N inputs creates N^2 state in memory...

But now, if that's just what you must do for some reason, then, yes, immutability makes the task of taking all those snapshots real easy.

Re: 4x Smaller, 50x Faster

#158

Post by sickill »

stjohnswarts wrote: post #129
agys wrote: post #88

For my own realtime browser based ASCII projects I update the DOM “manually”: the biggest bottleneck is frequent -horizontal- changes in color as each character with a new color needs to be wrapped in its own element. After all you can’t avoid a DOM repaint. After several benchmarks I realized that the fastest way to update the entire window is to compose a string and assign it to each line/line-element via innerHTML…

Maybe you could benchmark it against this. It would make an interest HN followup post.

It's not the rendering / DOM part that got 50x faster though, so that would be apples to oranges.

Re: 4x Smaller, 50x Faster

#159

Post by sickill »

71a54xd wrote: post #143

Asciinema server is still quite frankly my favorite Elixir Phoenix project of all time. https://github.com/asciinema/asciinema-server

Oh wow, thank you! Frankly I'm the least proud of it, as it's been my first Elixir/Phoenix project and there's many things I'd have written differently today, especially after spending last 4 years writing Elixir at work. But time will hopefuly come to bring more love to it too :)

Re: 4x Smaller, 50x Faster

#160

Post by cryptonector »

cryptonector wrote: post #11
rektide wrote: post #3

Earlier quoted context omitted.

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…

Immutability is a drag if you create lots and lots of referenced state because, e.g., you want to hold on to many snapshots of past state. Immutability done right need not be much worse than mutability. For example, jq's internal value representation is immutable in appearance: - mutations yield new values, - but when the value being "mutated" has only one extant reference then mutation is done in-place, - while when…

I should add that reference counting GCs are nice because short-lived garbage is freed immediately and there's no need to look for garbage, so they're much faster than scanning GCs. Reference counting GCs can have GC-like pauses when releasing objects that have singular references to many many many other objects, but the same is true in manual memory management systems.
Post reply on HN