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

Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

github.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

#21

Post by embedding-shape »

pier25 wrote: post #20
embedding-shape wrote: post #17

Earlier quoted context omitted.

That's maybe more worrisome, everything has tradeoffs, if you don't know them yet, search for them :)

It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant. I know the tradeoffs. For me it's way better than Node. Especially given the campaign targeting Node devs. https://socket.dev/blog/attackers-hunting-high-impact-nodejs...

> It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant.

About the same, regardless, truth usually sits somewhere in the middle :)

> I know the tradeoffs

No harm no foul then, "it's been flawless for me" certainly gave me a different impression, but I guess as long as we all find the tools that work for us.

Re: Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

#22

Post by phplovesong »

gear54rus wrote: post #11
phplovesong wrote: post #7

I had high hopes for Bun, but looks like it has gone down the shitter after they went all in on vibecoding.

Any specific links to problems? I was planning to start a new project on it :(

Deno is solid. Or just use nodejs, it got many of the features deno/bun originally shipped with. No matter how you slice it, node is still the defacto server side JS runtime.

Re: Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

#23

Post by pier25 »

embedding-shape wrote: post #21
pier25 wrote: post #20

Earlier quoted context omitted.

It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant. I know the tradeoffs. For me it's way better than Node. Especially given the campaign targeting Node devs. https://socket.dev/blog/attackers-hunting-high-impact-nodejs...

> It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant. About the same, regardless, truth usually sits somewhere in the middle :) > I know the tradeoffs No harm no foul then, "it's been flawless for me" certainly gave me a different impression, but I guess as long as we all find the tools that work for us.

Well I certainly didn't say "it's flawless" :)

Re: Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

#24

Post by rcxdude »

lioeters wrote: post #5
jasdfwasd wrote: post #3

Earlier quoted context omitted.

> p = (char*)""; yikes

I thought that was a typo or the forum software removed something, but no - it's a pointer to an empty string literal. If I understand how that works, this creates a null byte (in the read-only memory section of the compiled output?) and points to it. Before this line it checks if p is NULL. I wonder what is the advantage of doing this? Maybe to make sure that p is an actual pointer, so later code can just make that…

it would be better to make p a const char* though, so that the code is not casting away the constness of the string literal (which can invoke undefined behaviour, though in practice string literals are going to be in a read-only area of memory anyway).

Re: Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux

#25

Post by nevon »

Anyone have ideas about what to do when using cgroup weights rather than max?

I'm currently in the process of removing cpu.max from our clusters, to allow applications to better utilize the available cpu time which currently is just being wasted. We will use cpu weights to make sure that cpu time is fairly allocated during contention, and to not oversubscribe the hosts, but I'm sure that among the thousands of applications that are running on those clusters today, many will be relying on cpu.max to size threadpools etc.

On the one hand, we do want applications to use the available cpu time, but at the same time they need to not kill themselves by running out of memory.

Post reply on HN