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

41–50 of 68 posts

Re: We sped up bun by 100x

#41

Post by yevbar »

delusional wrote: post #17
sc68cal wrote: post #7

So, they implemented a git client in zig, that had some significant speedups for their usecase. However: > The git CLI test suite consists of 21,329 individual assertions for various git subcommands (that way we can be certain ziggit does suffice as a drop-in replacement for git). > While we only got through part of the overall test suite, that's still the equivalent of a month's worth of straight developer work (aga…

> 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-based Macs https://github.com/hdresearch/ziggit/blob/master/BENCHMARKS....

Re: We sped up bun by 100x

#42

Post by yevbar »

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…

I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality

As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done

Re: We sped up bun by 100x

#43

Post by carterschonwald »

im pretty stoked about the llm harness theyre using. cause I wrote all the code thats not monopi code in that fork!

despite it’s paucity of features, the changes i landed in it from my design notes actually have been so smooth in terms of comparative ux/ llm behavior that its my daily driver since ive stood it up.

Previously, since early december, ive had to run a patch script on every update of claude code to make it stop undermining me. I didnt need a hilarious code leak to find the problematic strings in the minified js ;)

I regard punkin-pi as a first stab at translating ideas ive had over the past 6 months for reliable llm harnesses. I hit some walls in terms of mono pi architecture for doing much more improvement with mono pi.

so Im working on the next gen of agent harnesses! stay tuned!

Re: We sped up bun by 100x

#46

Post by testdelacc1 »

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…

Now we just need that AI booster guy to join this thread and tell us that actually this is super impressive. He was doing that for that worthless “browser” that Cursor built.

Re: We sped up bun by 100x

#47

Post by TimTheTinker »

yevbar wrote: post #39
TimTheTinker wrote: post #35

These "AI rewrite" projects are beginning to grate on me. Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. However, if the original package is in its training data, it's very likely to plagiarize the original source. Also, who actually wants to use or maintain a large project that no…

> Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. This was the "validation" used for determining how much progress was made at a given point in time. Re training data concerns, this was done and shipped to be open source (under GPLv2) so there's no abuse of open source work here imo…

I suppose "Project X has been used productively by Y developers for Z amount of time" is a decent-enough endorsement (in this case, ziggit used by you).

But after the massive one-off rewrite, what are the chances that (a) humans will want to do any personal effort on reading it, documenting it, understanding it, etc., or that (b) future work by either agents or humans is going to be consistently high-quality?

Beyond a certain level of complexity, "high-quality work" is not just about where a codebase is right now, it's where it's going and how much its maintainers can be trusted to keep it moving in the right direction - a trust that only people with a name, reputation, observable values/commitments, and track record can earn.

Re: We sped up bun by 100x

#48

Post by djoldman »

rao-v wrote: post #15
sc68cal wrote: post #7

So, they implemented a git client in zig, that had some significant speedups for their usecase. However: > The git CLI test suite consists of 21,329 individual assertions for various git subcommands (that way we can be certain ziggit does suffice as a drop-in replacement for git). > While we only got through part of the overall test suite, that's still the equivalent of a month's worth of straight developer work (aga…

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?

This is the same as all the folks asking for and hawking quantized models.

It doesn't matter if the parent model is GPT GOD mode mythos opus 100x Ultra. What matters is the performance of the quantized model.

Re: We sped up bun by 100x

#49

Post by ARandumGuy »

TimTheTinker wrote: post #35

These "AI rewrite" projects are beginning to grate on me. Sure, if you have a complete test suite for a library or CLI tool, it is possible to prompt Claude Opus 4.6 such that it creates a 100% passing, "more performant", drop-in replacement. However, if the original package is in its training data, it's very likely to plagiarize the original source. Also, who actually wants to use or maintain a large project that no…

> Sure, if you have a complete test suite for a library or CLI tool

And this is a huge "if". Having 100% test coverage does not mean you've accounted for every possible edge or corner case. Additionally, there's no guarantee that every bugfix implemented adequate test coverage to ensure the bug doesn't get reintroduced. Finally, there are plenty of poorly written tests out there that increase the test coverage without actually testing anything.

This is why any sort of big rewrite carries some level of risk. Tests certainly help mitigate this risk, but you can never be 100% sure that your big rewrite didn't introduce new problems. This is why code reviews are important, especially if the code was AI generated.

Re: We sped up bun by 100x

#50

Post by plorkyeran »

mfitton wrote: post #6

What it cost doesn't actually say what it cost. I wonder what models they used. Napkin math of Opus for everything (probably not true) with no caching suggests $67,000. Cool article though!

Anthropic owns Bun, so they presumably did not directly pay for anything.
Post reply on HN