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

191–200 of 229 posts

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

#191

Post by hinkley »

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.

Deltas and caches need some work too. It's a little unfortunate that my compile time is more affected by the amount of code that didn't change than the code I changed.

One of the features of Rational was that it would distribute precompiled headers around. Whoever changed the header files had to pay to recompile them, but everyone else just got the results instead.

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

#192

Post by fire_lake »

wiseowise wrote: post #107
liuliu wrote: post #6

The math type inference example makes the usual claim that "what if Swift can replace Python" a non-starter. As someone who have to deal with this on frequent basis, it is pretty sad. (I maintains s4nnc and a fork of PythonKit).

> what if Swift can replace Python What a ridiculous statement. I’m willing to bet everything I have in life that this is never going to happen.

Probably not Swift, but you know at some point Python will be surpassed in popularity by something else right? This has happened many times to programming languages in the past.

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

#193

Post by agent281 »

fooker wrote: post #156
fweimer wrote: post #45

Earlier quoted context omitted.

I know that historically, we were taught that NP-complete problems are unsolvable for interesting problem sizes, but that was already a bit of lie in when I went to university. (TSP was presented as a warning example, but even back then, very efficient approximations existed.) These days, when you have a SAT-like problem, you're often done because you can throw a SAT solver at it, and it will give you an answer in a…

I know, my PhD was about verifying software correctness with SMT solvers. The reason we don't do this in production is that the solvers take an unpredictable amount of time. A small problem can take forever and a large problem can be instant. You can't gave that in a compiler. There are enough people at Apple who know about SAT solvers. :)

On the other hand, they might know about SAT solvers, but not have enough time to actually experiment with it and integrate one into the language. Especially if there are other high priority issues.

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

#194

Post by hinkley »

ajkjk wrote: post #11

The times here seem unreasonably bad even with the bad algorithm. Something else has got to be going on. Maybe kind of hidden factorial complexity when it tries every combination?

It's very hard to track time complexity when you nest multiple layers of delegation.

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

#195

Post by hinkley »

fweimer wrote: post #88
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 the challenge here is that it only happens for a type error, not a successful compilation. Each time this happens, the programmer would try to fix the type error, usually invalidating the cache. I'm not so sure the problem is intractable because it's so well-structured. Someone would have to look at it and check that there aren't any low-hanging fruits. The challenge might be that anyone who could fix this co…

I still have a hunch that editors, when attempting to assist the developer, should have memory of the last clean copy of the code and use that for inference, as much or moreso than the current code.

In particular there are no guarantees that as I am writing a new method that I have the brackets balanced to make the code around it be seen as valid code. I'm so tired of not being able to use autocomplete in the middle of a complex edit unless I ritualistically write the code in an order that is unnatural to me.

Similarly, if I'm iteratively trying to fix a type error, the previous edit was not sane, and is of no help at all. You may have to go several edits back.

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

#196

Post by DanielHB »

kaba0 wrote: post #190
DanielHB wrote: post #71

Earlier quoted context omitted.

A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.

Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.

I wouldn't call the compile times super fast, but they were not that bad. I brought up the hot code swap thing because I did use it a lot when I was doing Java development.

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

#197

Post by kaba0 »

DanielHB wrote: post #196
kaba0 wrote: post #190

Earlier quoted context omitted.

Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.

I wouldn't call the compile times super fast, but they were not that bad. I brought up the hot code swap thing because I did use it a lot when I was doing Java development.

The compile itself is very fast, but the build tools tend to think a bit when not hot/do some additional stuff besides building. But the actual time spent in `javac` is very short (partially because it only outputs very high level byte code)

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

#198

Post by mike_hearn »

DanielHB wrote: post #185
Weebs wrote: post #183

Earlier quoted context omitted.

This is a direction I've been pushing in partly because I'm using a significantly slower type inference algorithm in my language. I'm hoping with that and focusing on separate compilation I'll be able to keep the fancy inference without sacrificing the UX too much

When I used to program Java I absolutely loved hot code swap and was always amazed how little people even knew it was possible. If you have a massive codebase no matter how fast your compiler is, re-compiling is going to be slow. But hot code swap is even better in that you can keep any state around without having to set it up all over again. In Java I could change a method implementation with the program running and…

Bear in mind that the underlying protocol used to request hot swap on Java is a lot more expressive than the standard HotSpot implementation is. If you use the Jetbrains Runtime (a fork of OpenJDK) or the GraalVM "Espresso" VM (a.k.a. Java on Truffle) then you can do way more hotswapping than you'd be able to normally.

Espresso goes further and doesn't only allow hot swapping but lets you write plugins that react to hot swaps of code:

https://www.graalvm.org/latest/reference-manual/java-on-truf...

If you use the Micronaut web framework then it will selectively re-initialize your app in response to hot swaps that need it. Pretty advanced stuff.

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

#199

Post by mike_hearn »

josephg wrote: post #84
diffxx wrote: post #70

Earlier quoted context omitted.

> One of the interesting tradeoffs in programming languages is compile speed vs everything else. Yes, but I don't think that compile speed has really been pushed aggressively enough to properly weigh this tradeoff. For me, compilation speed is the #1 most important priority. Static type checking is #2, significantly below #1 and everything else I consider low priority. Nothing breaks my flow like waiting for compilat…

I think this is a false choice. It comes from the way we design compilers today. When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. This is quite silly. Surely it’s poss…

That's called incremental compilation and is fully supported by languages like Java or Kotlin. The JVM also supports this, being able to recompile methods on the fly whilst the program runs. And the IDE plugins for these types of languages are actually "presentation compilers". They do all the work of compiling and type checking, except for code emission, and they run fast enough to run continuously in the background on every keystroke.

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

#200

Post by mike_hearn »

jwells89 wrote: post #42
pajuc wrote: post #32

It's really hard for me to read past Lattner's quote. "Beautiful minimal syntax" vs "really bad compile times" and "awful error messages". I know it's not helpful to judge in hindsight, lots of smart people, etc. But why on earth would you make this decision for a language aimed at app developers? How is this not a design failure? If I read this article correctly, it would have been an unacceptable decision to make u…

I can’t offer much in the way of reasoning or explanation, but having written plenty of both Swift and Kotlin (the latter of which being a lot like a more verbose/explicit Swift in terms of syntax), I have to say that in the day to day I prefer the Swift way. Not that it’s a terrible imposition to have to type out full enum names and such, but it feels notably more clunky and less pleasant to write. So maybe the deci…

Bear in mind that in both Java and Kotlin you can statically import enum entries:

    import foo.SomeEnum.MIDNIGHT

    setThreadLevel(MIDNIGHT)
In practice, you write out ThreatLevel.MIDNIGHT, let the IDE import it for you, and then use an IDE hotkey to do the static import and eliminate the prefix.
Post reply on HN