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

The Swift compiler is slow due to how types are inferred

danielchasehooper.com

Post reply on HN
Print view View original

111–120 of 229 posts

Re: The Swift compiler is slow due to how types are inferred

#111

Post by wiseowise »

throwaway894345 wrote: post #106
wiseowise wrote: post #86

Earlier quoted context omitted.

It is. Compared to other languages (short of JS without Symbols and async/await/promises mumbo jumbo or lisp) it has much easier entry barrier.

Python absolutely has async/await/promises, and it's actually quite a lot worse than JavaScript in this regard because Python _also_ has synchronous APIs and _no_ tooling whatsoever to make sure you don't call a sync API in an async function thereby blocking your event loop (which, if your application is a networked service with any amount of traffic at all, will typically result in a cascading failure in production)…

Structured concurrency with Exception groups make it untouchable for JS. If JS implements structure concurrency like Python, Java, Kotlin, then maybe it can be viable.

Re: The Swift compiler is slow due to how types are inferred

#112

Post by ackfoobar »

tines wrote: post #87
ackfoobar wrote: post #53

Earlier quoted context omitted.

"Does type X have an implementation for typeclass Y" isn't always easy to answer. https://aphyr.com/posts/342-typing-the-technical-interview

That post, while awesome (as is the rest of aphyr's stuff), is a lot to wade through to get to the point you're trying to convey. Can you spell it out for me?

That typeclass resolution can encode some heavy computation, the example being n-queens in the article.

Re: The Swift compiler is slow due to how types are inferred

#113

Post by hu3 »

TillE wrote: post #89
lolinder wrote: post #77

Earlier quoted context omitted.

> Nothing breaks my flow like waiting for compilation. With a sufficiently fast compiler (and Go is not fast enough for me), you can run it on every keystroke and get realtime feedback on your code. I already get fast feedback on my code inlined in my editor, and for most languages it only takes 1-2 seconds after I finish typing to update (much longer for Rust, of course). I've never personally found that those 1-2 s…

Yeah even with a large C++ codebase, any decent IDE will flag errors very quickly in real time. I dunno, I've never found that waiting a minute to run a test or whatever is particularly detrimental to my workflow. I understand the benefits of super fast iteration if you're tweaking a GUI layout or something, but for the most part I'd prioritize many many other features first.

Fast compilation + unit tests allows me to quickly check if I broke a lot more stuff than IDE local checks.

Re: The Swift compiler is slow due to how types are inferred

#114

Post by estebank »

josephg wrote: post #108
estebank wrote: post #96

Earlier quoted context omitted.

> But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. I don't think that there are that many production level compilers that don't perform the kind of caching that you're advocating for. Part of them problem is what the language semantics are. https://www.pingcap.com/blog/rust-huge-compilation-units/ gives an example of this. > Surely it’s possible to make…

Yes, rust has an incremental compilation mode that is definitely faster than compiling the whole program from scratch. But linking is still done from scratch every time, and that gets pretty slow with big programs. I agree that it would be a lot of work to retrofit llvm like this. But personally I think that effort would be well worth it. Maybe the place to start is the linker.

You're in good company: multiple people want to experiment with taking ownership of the linking and codegen steps to enable this kind of behavior. I would be more than happy to see that happen. I feel that the problem is a project of that magnitude requires a benefactor for a small group of people to work completely dedicated to it for maybe 2 years. Those don't come along often. The alternative is that these projects don't happen, lose steam or take a really long time.

Re: The Swift compiler is slow due to how types are inferred

#115

Post by pcwalton »

withoutboats3 wrote: post #65

I'm suspicious about the truth of this claim. I don't think bidirectional typechecking is the problem in itself: the problem trying to do type inference when you have some extremely flexible operator overloading, subtyping, and literal syntax features. It's these "expressive" features which have made type inference in Swift far more computationally complex, not type inference itself. And certainly not bidirectional t…

Yeah, I agree. Regular H-M typechecking if you don't have subtyping is actually really fast. The problem is that subtyping makes it really complicated--in fact, IIRC, formally undecidable.

Re: The Swift compiler is slow due to how types are inferred

#116

Post by ashdnazg »

Our CI posts a list of shame with the 10 worst offending expressions on every PR as part of the build and test results.

So far it's working quite nicely. Every now and then you take a look and notice that your modules are now at the top, so you quickly fix them, passing the honour to the next victim.

Re: The Swift compiler is slow due to how types are inferred

#117

Post by [deleted] »

cerved wrote: post #69
irdc wrote: post #5

One could argue that anything that anything that makes the development process itself more efficient, as opposed to the compiling, is worth it since programmers themselves ain’t getting any faster anytime soon, but timing out after more than 40 seconds on a state-of-the-art CPU because of a handful of lines is just ridiculous.

I'm not sure I would draw the same conclusion, stricter requirements on typing is less cumbersome these days with better auto complete and LLMs

[deleted]

Re: The Swift compiler is slow due to how types are inferred

#118

Post by tolmasky »

dmurray wrote: post #60
refulgentis wrote: post #35

Earlier quoted context omitted.

Here's some light to make it appear less stupid: He doesn't claim its not a design failure. He doesn't say they sat down and said "You know what? Lets do beautiful minimal syntax but have awful error messages & really bad compile times" The light here is recursive. As you lay out, it is extremely s̶t̶u̶p̶i̶d̶ unlikely that choice was made, actively. Left with an unlikely scenario, we take a step back and question if…

The alternatives are even less charitable to the Swift creators. Surely, early in the development someone noticed compile times were very slow for certain simple but realistic examples. (Alternatives: they didn't have users? They didn't provide a way to get their feedback? They didn't measure compile times?) Then, surely they sat down considered whether they could improve compile times and at what cost, and determine…

> Alternatives: they didn't have users?

Correct, it is well known that they kept Swift a bizarre secret internally. It seems no one thought it would be a good idea to consult with the vast swathes of engineers that had been using the language this was intended to replace for the last 30 or so years, nor to consult with the maintainers of the frameworks this language was supposedly going to help write, etc. As you can imagine, this led to many problems beyond just not getting a large enough surface area of compiler performance use cases.

Of course, after it was released, when they seemed very willing to make backward-incompatible changes for 5 years, and in theory they then had plenty of people running into this, they apparently still decided to not prioritize it.

Re: The Swift compiler is slow due to how types are inferred

#119

Post by irq-1 »

jerf wrote: post #56
vlovich123 wrote: post #48

The combinatorial explosion is intractable but since it only seems to come up in really obscure corner cases, I wonder if the typical inference scenarios can be solved by having the compiler cache the AST across invocations so that inference only needs to be performed on invalidated parts of the AST as it’s being typed instead of waiting for the user to invoke the compiler.

I think it would also be interesting for the compiler to modify the source code (with a flag, presumably, or possibly through the local LSP server) with the solved result as needed. This would also feedback to the programmer what the problem is, what the compiler thought the solution is (and under the circumstances, while it can't be "wrong" there's a decent chance it is suboptimal or not what the programmer expected…

Why not make it a warning if the compiler leaves the happy path? The fix is easy for the programmer (enums, casting, etc.) and could be left unfixed if the programmer knows its OK (meaning it wont take 42 seconds and give an error.) The LSP would have to know when the compiler ran into this, but if the compiler can identify the type explosion problem, it can tell the LSP.

Re: The Swift compiler is slow due to how types are inferred

#120

Post by sans-seraph »

throwaway894345 wrote: post #110
sans-seraph wrote: post #74

Earlier quoted context omitted.

In the case of Rust the fast feedback loop is facilitated by the `cargo check` command which halts compilation after typechecking. Unlike in Swift the typechecking phase in Rust is not a significant contributor to compilation times and so skipping code generation, optimization, and linking is sufficient for subsecond feedback loops.

I mean, you still need to run code at the end of the day. Yeah, the type checker will update your IDE quickly enough, but you still need to compile and link at least a debug build in order to meaningfully qualify as a feedback loop IMHO.

This was my initial mindset as someone whose background lies in untyped languages, but after time with Rust I no longer feel that way. My feeling now is that seeing a Rust codebase typecheck gives me more confidence than seeing a Python or Javascript codebase pass a test suite. Naturally I am still an advocate for extensive test suites but for my Rust code I only run tests before merging, not as a continuous part of development.

To give an example, in the past week I have ported over a thousand lines of C code to a successor written in Rust. During development compilation errors were relatively frequent, such as size mismatches, type mismatches, lifetime errors, etc. I then created a C-compatible interface and plugged it into our existing product in order to verify it using our extensive integration test suite, which takes over 30 minutes to run. It worked the first time. In order to ensure that I had not done something wrong, I was forced to insert intentional crashes in order to convince myself that my code was actually being used. Running that test suite on every individual change would not have yielded a benefit.

Post reply on HN