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

We sped up bun by 100x

vers.sh

Post reply on HN
Print view View original

51–60 of 68 posts

Re: We sped up bun by 100x

#51

Post by ghjnut »

BearOso wrote: post #22
nightpool wrote: post #14

Seems like they actually sped bun up ~1x: When evaluating the complete bun install improvements, it came out speed-wise to about the same as the existing git usage (due to networking being the big bottleneck time-wise despite more cases being slightly faster with ziggit over multiple benchmarks). Except, it's done in 100% zig and those internal improvements pile up as projects consist of more git dependencies. All in…

You have to maintain a completely separate implementation of AI generated code that's translated from C, so not even idiomatic zig. Edit And then I go their repository and read commits like this https://github.com/hdresearch/ziggit/commit/31adc1da1693e402... which confirms it wasn't even looked over by a human.

I don't know zig well. What's raising flags for you?

Re: We sped up bun by 100x

#53

Post by mpalmer »

The title is obviously dishonest. I do not hesitate to call it a lie.

The post is also not about the speed increase, it's about how proud this team is of their agent orchestration scheme.

As I understand it, there is really no speed difference at all between Zig and C, just some cognitive overhead associated with doing things "right" in C. It's all machine code at bottom.

So why is this rewrite faster? Why did the authors choose Zig? How has the logic or memory management changed?

The authors give us absolutely no insight whatsoever into the the Zig code. No indication that they know anything about Zig, or systems programming, at all. I wish this was an exaggeration.

And really. With all this agentic power at your fingertips, why wouldn't they just contribute these improvements to git itself? I can think of at least one reason, that they don't want their changes to be rejected as unhelpful or low-quality.

Re: We sped up bun by 100x

#54

Post by ARandumGuy »

yevbar wrote: post #30
varispeed wrote: post #12

Earlier quoted context omitted.

Reminds me when I was happy with my algorithm being super fast until I started tackling edge cases. Suddenly it's got quite slow.

Edge cases certainly apply with scripts depending on specific git CLI args or stdout strings may not suffice with ziggit. _However_, for the use cases that most developers or agents are looking for, ziggit should have enough features covered. Happy to fix issues or bugs if that's not the case

> _However_, for the use cases that most developers or agents are looking for

What use cases are those? How did you determine that these are the use cases most developers/agents are looking for?

For me, git has a ton of features that I rarely use. But when I need them, I really need them. Any replacement that doesn't cover these edge cases is fundamentally incomplete and insufficient, even if it works fine 99% of the time.

Re: We sped up bun by 100x

#55

Post by mpalmer »

yevbar wrote: post #40
cwillu wrote: post #32

I think we might be getting to the point where submissions for projects that are primarily written by ai and/or ai agents need to be tagged with [agent] in the title

If this were 2+ years ago perhaps, with industry adopting more agents in their SDLCs (ie Stripe minions or Ramp background agents), I think we're more a matter of time before we treat agent/human built products the same unless we're branding smth as artisanal human-crafted software

Well, we're not there today. Generated code and prose are still trivial to spot.

And even mass-produced products benefit from thoughtful design by a human.

Why didn't the blog post explain anything about why the rewrite is faster? Or about Zig, or C, programming, at all?

Re: We sped up bun by 100x

#56

Post by BearOso »

ghjnut wrote: post #51
BearOso wrote: post #22

Earlier quoted context omitted.

You have to maintain a completely separate implementation of AI generated code that's translated from C, so not even idiomatic zig. Edit And then I go their repository and read commits like this https://github.com/hdresearch/ziggit/commit/31adc1da1693e402... which confirms it wasn't even looked over by a human.

I don't know zig well. What's raising flags for you?

The commit I linked shows that it didn't even read the user name and email from git's config file, but used a test name, which means it's woefully incomplete.

Then there's stuff like this: https://github.com/hdresearch/ziggit/blob/master/src/cmd_bra...

It's just one giant function. Sometimes big functions are necessary. This one is clearly AI generated and not very readable for a human. This is just from a quick glance.

Re: We sped up bun by 100x

#57

Post by delusional »

llimllib wrote: post #37
delusional wrote: post #17

Earlier quoted context omitted.

> The bun team has already tested using git's C library and found it to be consistently slower hence resorting to literally executing the git CLI when performing bun install. I find that to be a much more remarkable claim. Git doesn't have a C library, and even if it did, In which world is literally shelling out faster than a C library call? I suppose libgit2 could be implemented poorly. If we follow their link[1] we…

libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library. Your comment does not seem to be in good faith, implying that they've made up the performance difference. There's a comment with a benchmark here: https://github.com/oven-sh/bun/blob/4760d78b325b62ee62d6e47b... referencing the com…

> Your comment does not seem to be in good faith, implying that they've made up the performance difference.

I believe I have accurately represented what the article says. Had the article provided the comment you have just linked, I would have commented on that as well. I did not intend to imply that they manufactured the performance difference, merely that they don't know what they are talking about. The thought I have in my head is that they are incompetent, not that they are malicious.

I wholeheartedly agree that libgit2 is full of footguns, that's why it matters that it's not actually "git's own C library" but a separate project. I also agree that you usually end up shelling out to git, exactly because of those problems libgit2 has. If those problems aren't speed though, and I don't think they are, the blog post would have to cover how this reimplementation of libgit2 avoids those problems.

I'm not here to litigate if bun would be faster with libgit2. I am however here to make the argument that the blogpost does not make a convincing argument for why libgit2 isn't good enough.

Re: We sped up bun by 100x

#59

Post by delusional »

yevbar wrote: post #41
delusional wrote: post #17

Earlier quoted context omitted.

> The bun team has already tested using git's C library and found it to be consistently slower hence resorting to literally executing the git CLI when performing bun install. I find that to be a much more remarkable claim. Git doesn't have a C library, and even if it did, In which world is literally shelling out faster than a C library call? I suppose libgit2 could be implemented poorly. If we follow their link[1] we…

Bun's attempted to integrate with libgit2 instead of spawning calls to the git CLI and found it to be consistently 3x slower iirc The micro-benchmarks are for the internal git operations that bun rn delegates to CLI calls. Overall, network time (ie round trip to GitHub and back) is what balances the performance when evaluating `bun install` but there are still places where ziggit has better visible wins like on arm-b…

I don't know what that "BENCHMARKS" document is supposed to show. When I try to replicate their results I'm getting wildly faster executions of standard git, and they don't provide enough details for me to theorize why.

I also noticed that their version of the "blame src/main.zig" command doesn't actually work (it shows all lines as not being committed). Sure, it's easy to optimize an algorithm if you just don't do the work. Git does indeed take longer, but at least it actually gives you a blame of the file.

Re: We sped up bun by 100x

#60

Post by delusional »

didgetmaster wrote: post #25
rao-v wrote: post #15

Earlier quoted context omitted.

Wait, so they don’t have test parity with git? How do they know that they, umm … did the actual thing they were trying to do?

I have heard that you can speed up your favorite compression algorithm by 1000x, if you are not so concerned about what happens when you try to decompress it.

It's just a lossy compression scheme.
Post reply on HN