Hacker News new | ask | show | jobs
by luciana1u 7 days ago
engineering effort to make something 1000x faster that accounts for 0.1% of total runtime is the most software developer thing imaginable
10 comments

I initially had a Rust-based word cloud generator that generates word clouds in high resolution in ~100 milliseconds whereas it would take other generators a couple seconds to do the same thing. Does the world need a super-fast word cloud generator? No. Do I want a super-fast word cloud generator? Yes.

I later found enough optimizations to reduce the generation speed all the way down to ~16ms. Do I need a word cloud generator that fast? No. But if I have a word cloud generator it's going to be as fast as possible dammit.

links or it didn't happen ;)
"The pursuit of excellence does not need justification."

https://x.com/mitchellh/status/2074225453217505494

1000x improvements unlock qualitatively new capabilities, even when only applied to subcomponents. Moreover, the fact that it's only 0.1% of the runtime is usually [0] an artifact of the entire project being treated that way -- why write this the right way when it won't move the needle on the composite project?

[0] Yes, for LLMs we're closer to the bound than 1000x. Even there though, basic pytorch operations are often 2x slower than simple rewrites, better scheduling algorithms have a history of closer to 5x-10x gains, and all of that supposes you don't have further architectural improvements over time. Moreover, who's to say that legitimately fast tokenization doesn't unlock additional capabilities elsewhere which people have ignored because it was never close to viable?

This depends on what your workflow is. There are use cases for tokenization that don't always involve immediately feeding the text into a model.
There are more usecases, for this class of tokenizer, now that it's 1000x faster as well. RAG being one example.
1000x faster on 0.1% of runtime = 0.1% saved. Amdahl remains undefeated.

Globally that’s ~50 GWh/yr, or ~5.7 MW continuous:

• 4,700 American homes

• a week of British tea

If you're tokenizing to run a tiny SLM for routing purposes, it can be way more than 0.1%.

This is the "GPU driver optimizations don't matter because PC's sit idle at the desktop most of the time" mindset.

This can make a huge difference for local models on modest hardware
AI now consumes TWh. This is more energy than a lot of countries on the whole planet.

If this increases efficiency, it has real impact. 0.1% is A LOT at scale.

It's pretty funny but then again, why not if it's as trivial to simplify as it appears
I don't think this was particularly trivial, but I do think that thanks to AI assisted coding there's more capacity for making improvements that "don't seem worth it" at first or when you look at it as a percentage of total.

But look at e.g. Biome; optimizing the formatter didn't seem worth it for a long time because it only took <1s to format most files. But it's <1s times millions of files, billions of times a day when you add up every developer that used Prettier for their code formatting - it adds up.

And I'm convinced Biome triggered or was part of a bigger effort to convert JS based tools to native code. This saved time and energy, which in turn allows for faster and / or more feedback loops, which in turn allows faster turnaround cycles for software development (bet it human or LLM assisted), etc. It's a compound effect.

I don't know enough about tokenization or whatever to judge this one, but if it's 1000x as fast as it used to be, there will be less need to try and avoid or minimize tokenization which may lead to new applications.

Except, their benchmarking shows this can speed up time to first token by up to 10%.