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

Fast

catherinejue.com

Post reply on HN
Print view View original

441–450 of 450 posts

Re: Fast

#441

Post by pron »

sirwhinesalot wrote: post #421
pron wrote: post #417

Earlier quoted context omitted.

> That is not the case for the TLA+ spec and your 1MLOC Java Database. That is the case. Of course, nobody bothers to write the TLA+ proof that that is the case, because even if somebody had the resources to do it, the ROI on doing that is not good. If you can avoid 4 major bugs with 10 hours of work, you probably won't want to work an extra 10,000 hours to avoid two additional minor ones. That most people choose to…

Too defeatist. If much of the software infrastructure of the world was built on say... Idris, we could do it. That's the promise of dependent types, proof carrying code. Can we extend that to large scale software? There's no obvious barrier to it, beyond a lack of existing provably correct code to build upon. I don't expect this to change, however, since the cost/benefit ratio just isn't there. And that makes me sad.…

> There's no obvious barrier to it

It's like saying that there's no barrier to turning lead into gold except for the fact that it's easier to get gold by other means; that's a good thing! The cost of deriving formal deductive proofs is high, while unsound methods are much cheaper and highly effective.

The reason proofs can be expensive is that proving things has an intrinsic computational complexity cost (it's a search problem in a large space). A decade ago I summarised some relevant results of the last three or four decades about the difficulty in proving programs correct: https://pron.github.io/posts/correctness-and-complexity

If software were generally simple enough for all of its interesting properties to be easily proven, that would mean that there wouldn't be much point in the software at all. I think it was a formal methods researcher/practitioner at NASA who once said something like, "computers were built to surprise us; if they didn't, there would be no point in building them in the first place."

> We build everything on quicksand.

You do realise that while an abstract algorithm or a program on the page can be proven correct, it is impossible to prove that a software system is correct, because it's a physical system, and not a mathematical object anymore (you cannot prove that hardware will behave as specified). If mathematical proofs were the only thing that's not "quicksand", then everything in the physical world is quicksand.

Re: Fast

#442

Post by sipjca »

ilyakaminsky wrote: post #213
sipjca wrote: post #171

Earlier quoted context omitted.

ive approached the same thing but slightly differently. i can run it on consumer hardware for vastly cheaper than the cloud and don't have to worry about image sizes at all. (bare metal is 'faster') offering 20,000 minutes of transcription for free up to the rate limit (1 Request Every 5 Seconds) https://geppetto.app I contributed "whisperfile" as a result of this work: * https://github.com/Mozilla-Ocho/llamafile/tre…

> i can run it on consumer hardware for vastly cheaper than the cloud Woah, that's really cool, CJ! I've been toying the with idea of standing up a cluster of older iPhones to run Apple's Speech framework. [1] The inspiration came from this blog post [2] where the author is using it for OCR. A couple of things are holding me back: (1) the OSS models are better according to the current benchmarks and (2) I have custom…

ty! if there's any way I can help just lmk, always happy to lend a hand or an ear

Re: Fast

#443

Post by Breza »

ilyakaminsky wrote: post #69

Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and…

Well said. And it's not just the cloud. We self-host at my job and there are real cost savings to speed here too. Being able to continue using an old server for another year and having your staff be just a little more efficient adds up quickly.

Re: Fast

#445

Post by rendx »

joshvm wrote: post #61
Liftyee wrote: post #54

I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.

For ACH, it's the scheduling and batching that makes it slow. The transfer itself should be instant but often my bank sends it out around midnight. This is why Venmo and Zelle are so popular. You can also modify/cancel a bank transfer before it goes through, which is nice. This is the same in Switzerland. If you request an IBAN transfer, it's never instant. The solution there for fast payments is called TWINT, which…

> If you request an IBAN transfer, it's never instant.

"In 2024, EU adopted Instant Payment Regulation, aiming to accelerate instant payments in Europe. For EU member states operating in euro it partially took affect in January 2025, for non-euro member states it will partially take affect in January 2027. This regulation includes requirements to send and receive transfers within 10 seconds, as well as to implement the Verification of Payee service."

https://en.wikipedia.org/wiki/Instant_payment

Re: Fast

#446

Post by zahlman »

citizenpaul wrote: post #436
zahlman wrote: post #182

Earlier quoted context omitted.

> A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever" If I reached a point where I would find this helpful, I would take this as a sign that I have structured the code wrongly.

I knew someone would make this comment. I almost added a "I'm probably not leet enough to avoid these situations" disclaimer. It seemed a bit pointlessly self deprecating. You don't always get to choose the state of or the way a system you work in/with is designed. In this case I was working in a limited scripting language that I have no choice about. Keep that nose turned up. I'm sure you are leet10xninja. Maybe wor…

No slight was intended. I've learned a lot of techniques; I don't consider this a matter of elitism. I have generally been fortunate to have control over the architecture of my projects; when I encounter something like this in someone else's code, I can at least raise my concern. Sometimes the code is that way because doing it the other obvious way would lead to some other inconvenience. Hence "a sign", not proof. It's worth investigating signs.

Re: Fast

#447

Post by phtrivier »

jodrellblank wrote: post #413
phtrivier wrote: post #409

Earlier quoted context omitted.

I would have loved to live in a universe where we could replace the Windows Terminal with RefTerm - if only, to measure how many hours would pass before a Fortune 500 company has to halt operations, because RefTerm does not properly re- implement one of the subtle bugs creeping from one of the bazillion features that had made WinTerm slow over the years. [1] [1] https://xkcd.com/1172/

I sighed when I read your comment, a comment which is exemplary of what Casey Muratori was ranting against - casual lazy dismissal of the idea that software can be faster, based on misunderstanding and lack of knowledge and/or interest, and throwing out the first objection that comes to mind as if it's an impassable obstacle. There were no bazillion features that made WinTerm slow over the years because Windows Termi…

Oh, sorry if that's the tone that got out of my message. I'm a big Casey fan myself, so I'm absolutely convinced that there is something "better" to do in terms of performance.

However, just because Windows Terminal was "new" in 2019, it does not mean that it was not embarking lots of legacy code to ensure compatibility with older software.

For example, the wikipedia page you linked to explicitly says WinTerm is "a replacement for Windows Console", which dates back to Win 9x [1] ; and that it's "compatible with Windows Narrator" [2], which dates from the early 2000s, and which scares me just by its name...

So, yes, there is probably a story of piling crap on top of backward compatible crap with zero incentive for performance, and an unhealthy dose a learned-helplessness.

I don't necessarily says it's an excuse for the problem ; but I would really not be surprised if it was "part" of the problem that MS is facing, and that Casey attacked a slightly different problem by not caring about obscure retro-compatibility to Win3.1.

It's good that the team used the software to improve their own. They're in a better position to argue than armchair commentators like me.

[1] https://en.wikipedia.org/wiki/Windows_Console#Windows_9x

[2] https://en.wikipedia.org/wiki/Narrator_(Windows)

Re: Fast

#448

Post by Night_Thastus »

Night_Thastus wrote: post #73

I wish I could live in a world of fast. C++ with no forward decls, no clang to give data about why the compile time is taking so long. 20 minute compiles. Only git tool I like (git-cola) is written in Python and slows to a crawl. gitk takes a good minute just to start up. Only environments are MSYS which is slow due to Windows, and WSL which isn't slow but can't do DPI scaling so I squint at everything.

EDIT for anyone struggling with DPI problems: Windows seems to over-ride the Nvidia control panel's default GPU, at least on my system. Swapping from the integrated graphics to the 'high-performance' Nvidia GPU option in System->Display->Graphics for wsl.exe and wslg.exe seems to have fixed it for me. I can't 100% confirm that was the solution as I was tweaking a lot of other things, but it's my best guess.

Re: Fast

#449

Post by seunosewa »

resonious wrote: post #262
PaulHoule wrote: post #2

Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes. I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 min…

As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my poc…

What are you using to fire up requests on your phone?

Re: Fast

#450

Post by Night_Thastus »

Night_Thastus wrote: post #448
Night_Thastus wrote: post #73

I wish I could live in a world of fast. C++ with no forward decls, no clang to give data about why the compile time is taking so long. 20 minute compiles. Only git tool I like (git-cola) is written in Python and slows to a crawl. gitk takes a good minute just to start up. Only environments are MSYS which is slow due to Windows, and WSL which isn't slow but can't do DPI scaling so I squint at everything.

EDIT for anyone struggling with DPI problems: Windows seems to over-ride the Nvidia control panel's default GPU, at least on my system. Swapping from the integrated graphics to the 'high-performance' Nvidia GPU option in System->Display->Graphics for wsl.exe and wslg.exe seems to have fixed it for me. I can't 100% confirm that was the solution as I was tweaking a lot of other things, but it's my best guess.

EDIT 2: This did not work for a second WSL instance, so there goes that theory. Though it may be necessary along with other steps.
Post reply on HN