Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next Generation Out of Band Garbage Collection

railsatscale.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Next Generation Out of Band Garbage Collection

#81

Post by HumanOstrich »

IshKebab wrote: post #69
byroot wrote: post #56

Earlier quoted context omitted.

That's exactly the joke though. Every time Ruby (or Python) is discussed on HN we get the same old tired question of "why don't they just rewrite in Rust". But that's some silly engineer tunnel vision, squeezing the very last bit of performance out of a system isn't a goal in itself. You just need it to be efficient enough that it cost you significantly less to run that the amount of revenue it brings you. I can bet…

It's usually dismissed because companies think short term, and switching languages is a project with huge short term disadvantages and huge long term advantages.

It's usually dismissed because it's almost always a huge strategic blunder.

Re: Next Generation Out of Band Garbage Collection

#82

Post by bitbckt »

byroot wrote: post #41
spullara wrote: post #20

All the other virtual machines that support GC need to look at the JVM's ZGC and Shenandoah. Sub-millisecond pause times with terabyte heaps.

We're actually hoping to get mmtK included in Ruby to be able to use more advanced GCs. Medium term we hope to use Immix: https://bugs.ruby-lang.org/issues/20860 And yes, we're aware of ZGC &co https://www.eightbitraptor.com/presentations/RubyKaigi2023-m...

Amazing to see this happening. I wrote the non-moving Immix collector at Twitter for our Ruby runtime, Kiji.

Good luck!

Re: Next Generation Out of Band Garbage Collection

#83

Post by [deleted] »

cletus wrote: post #70

> no object allocated as part of a request should survive longer than the request itself So I've spent a lot of time doing Hack (and PHP) as well as Java, Python and other languages. For me, as far as serving HTTP requests goes, Hack/PHP are almost the perfect language. Why? 1. A stateless functional core. There's no loading of large libraries, which is an issue with Python and Java in certain paradigms. The core API…

[deleted]

Re: Next Generation Out of Band Garbage Collection

#84

Post by eru »

IshKebab wrote: post #68
eru wrote: post #58

Earlier quoted context omitted.

CPython itself has seen lots of performance improvements recently. Benchmarks on CPython 3.12 take about half the time they took on CPython 3.9.

Yeah it's definitely welcome, but even if it is double the performance (doesn't seem to be quite there in my experience) fast languages are still 25-50x faster. It's like walking twice as fast when the alternative is driving.

Yes.

Well, it really depends on whether that alternative is open to you, and at what cost.

So eg lots of machine learning code is held together by duct tape and Python. Most of the heavy lifting is done by Python modules implemented in (faster) non-Python languages.

The parts that remain in Python could potentially be sped up by migrating them, too. But that migration would likely not do too much for the overall performance, but still be pretty expensive to do (in terms of engineering effort).

For organisations in these kinds of situations, it makes a lot of sense to hope for / contribute to a faster Python. Especially if it's a drop-in replacement (like Python 3.12 is for 3.9).

What makes really me hopefully is actually JavaScript: on the face of it, JavaScript is actually about the worst language to have a fast implementation. But thanks to advances in clever compiler and interpreter techniques, JavaScript is one of the decently fast languages these days. Especially if you are willing to work in a restricted subset of the language for substantial parts of your code.

I'm hoping Python can benefit from similar efforts. Especially since they don't need to re-invent the wheel, but can learn from the earlier and ongoing JavaScript efforts.

(I myself made some tiny efforts for CPython performance and correctness. Some of them were even accepted into their repository.)

Re: Next Generation Out of Band Garbage Collection

#85

Post by eru »

Twirrim wrote: post #80
krapp wrote: post #59

Earlier quoted context omitted.

I was excited about Hack when it came out. Unfortunately PHP took just enough from it to kill it. I gave up on it once Composer stopped supporting it, after backwards compatibility with PHP no longer became a goal. IMHO Hack's best feature was native support for XHP... which (also unfortunately) isn't something PHP decided to take.

Hack really gave PHP/Zend the kick up the arse that it seemed to need.

I guess like Scala (et al) and Java? C++ also seems to be learning things from Rust these days.

Re: Next Generation Out of Band Garbage Collection

#86

Post by orf »

worik wrote: post #32
ziddoap wrote: post #13

Earlier quoted context omitted.

I bet the engineers at Instagram were unaware of pythons performance profile when they chose it, you should let them know that they should just switch to a different language.

> I bet the engineers at Instagram were unaware of pythons performance profile when they chose it, Is the Instagram stack Python? I doubt it, but stranger things have happened I suspect it is actually some derivative of Apache, or Nginx. Something sensible

You expect that the instagram stack is something sensible, such as only a web server? What?

Re: Next Generation Out of Band Garbage Collection

#87

Post by danmur »

indulona wrote: post #38
danmur wrote: post #17

Earlier quoted context omitted.

I don't think using Zig over Python is gonna have the biggest impact in making your next big company successful. It's a drop in the ocean compared to the quality of people you have to actually design and build it.

That is nonsense. If you can run your code on 10 servers instead of 1k servers, that is an insane time and money saver that could make or break a company.

I certainly don't claim to be an expert, but I have a hunch that getting to the point where performance becomes a significant factor (in the success or failure of a product) isn't going to be about the choice of language. I also think you're vastly underestimating the performance that good architects can get out of ANY (primary) language through good system design. Good design vs bad design makes the biggest difference in my experience, at least from a technical standpoint. Probably just nonsense though as you say.
Post reply on HN