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

141–150 of 229 posts

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

#141

Post by adamwk »

lamontcg wrote: post #121
Tuna-Fish wrote: post #97

Earlier quoted context omitted.

Rust took the other road: error[E0277]: cannot add `i64` to `i32` 1i32 + 2i64; ^ no implementation for `i32 + i64` It bothered me at first, there are a lot of explicit annotations for conversions when dealing with mixed precision stuff. But I now feel that it was the exactly correct choice, and not just because it makes inference easier.

Rust still lets you create your own algorithmic data types so that you can overload traits like Add, Mul, Div and Sub to implement your own e.g. Vector3 class (although I still feel this is too restrictive, but understand why rust chooses not to do that). What Rust blocks in your example there is implicit type conversion/coercion/promotion, and I'm actually okay with that and forcing being much more explicit about ty…

the rust traits are not overloading though (at least not in the same way as swift), that’s just implementing a trait on a type. I think the distinction is that with traits or protocols you get a lot of expressivity, reducing the need for overloading

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

#142

Post by ash_gti »

mrkeen wrote: post #132
ash_gti wrote: post #130

Earlier quoted context omitted.

Your example is different than the example in the post. Specifically, `channel = 11`, an integer. If it was a string then it parses very quickly.

If what your saying is true (the type is fixed as an integer), then it's even easier in tfa's case. No inference necessary. In my code channel is not a string, it's one type of the 31-set of (String, Foo01, Foo02, .., Foo30). So it needs to be inferred via HM. > If it was a string then it parses very quickly. "Parses"? I don't think that's the issue. Did you try it? ----- EDIT ------ I made it an Int let channel = 11…

The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types).

The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.

This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.

If any of the types in the expression had an explicit type then it would be type checked basically instantly. Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.

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

#144

Post by refulgentis »

pajuc wrote: post #136
anoncareer0212 wrote: post #127

Earlier quoted context omitted.

If we have to flatten it to "they chose and knew exactly what choice they were making", then there's no light to be shed. Sure. That's stupid. Its just as stupid to insist on that being the case. If that's not convincing to you on its merits, consider another aspect, you expressly were inviting conversation on why that wasn't the case

Why is there no light to be shed? This is a perfectly reasonable question to ask. And a straight simple answer might be that no, they didn't. Or not initially but later it was too late. Or here are the circumstances in leadership, historical contexts that led to it and we find those in other projects as well. That would be interesting to hear.

I've kind of lost the plot myself. XD The whole concept seems a bit complicated to me.

You're holding out on responding constructively until someone on the Swift team responds?

Better to just avoid boorishness, or find another way to word your invitation to the people who you will accept discussion from.

I wouldn't go out of my way to engage in the comments section with someone who calls me stupid repeatedly, based on an imagined analysis of my thought process being that of a small child, then refuses to engage with any discussion that doesn't start with yes, my team was stupid, we did actively choose awful error messages and really bad compile times for pretty syntax.

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

#145

Post by samatman »

tolmasky wrote: post #72
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…

Honestly it follows the design of the rest of the language. An incomplete list: 1. They wrote it to replace C++ instead of Objective-C. This is obvious from hearing Lattner speak, he always compares it to C++. Which makes sense, he dealt with C++ every day, since he is a compiler writer. This language does not actually address the problems of Objective-C from a user-perspective. They designed it to address the proble…

This is a great comment, you clearly know what you're talking about and I learned a lot.

I wanted to push back on this a bit:

> The "Objective-C problems" they fixed were things that made Objective-C annoying to optimize, not annoying to write (except if you are a big hater of square brackets I suppose).

From an outsider's perspective, this was the point of Swift: Objective C was and is hard to optimize. Optimal code means programs which do more and drain your battery less. That was Swift's pitch: the old Apple inherited Objective C from NExT, and built the Mac around it, back when a Mac was plugged into the wall and burning 500 watts to browse the Internet. The new Apple's priority was a language which wasn't such a hog, for computers that fit in your pocket.

Do you think it would have been possible to keep the good dynamic Smalltalk parts of Objective C, and also make a language which is more efficient? For that matter, do you think that Swift even succeeded in being that more efficient language?

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

#146

Post by mrkeen »

ash_gti wrote: post #142
mrkeen wrote: post #132

Earlier quoted context omitted.

If what your saying is true (the type is fixed as an integer), then it's even easier in tfa's case. No inference necessary. In my code channel is not a string, it's one type of the 31-set of (String, Foo01, Foo02, .., Foo30). So it needs to be inferred via HM. > If it was a string then it parses very quickly. "Parses"? I don't think that's the issue. Did you try it? ----- EDIT ------ I made it an Int let channel = 11…

The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types). The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal. This is whats causing the type ch…

> The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.

Can you please go back and read what I wrote and come up with any plausible alternative explanation for why I wrote the code that I wrote, if not to overload the HM with too many possible types to infer.

> If any of the types in the expression had an explicit type then it would be type checked basically instantly.

Did you try this?

> Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.

That's what I wrote in my first version. No explicit types. Then I got some comment about it needing to be an Int.

> That combination produces 59k+ permutations without even looking at non-standard library types.

Mine should reject 26439622160640 invalid typings to land on one of 31 possible well-typed readings of this program. (31 ^ 9) - 31.

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

#147

Post by dmurray »

> The issue is caused by using the + operator with the channel Int and a String literal. Thanks to the standard library’s 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol, the swift compiler can’t rule out that there might be a combination of types and operators that make the expression valid, so it has to try them all. Just considering that the five string literals could be one of the possible nine types results in 59,049 combinations, but I suspect that’s a lower bound, since it doesn’t consider the many overloads of +.

This really seems like a design flaw. If there are 59,049 overloads for string concatenation, surely either

- one of them should be expressive enough to allow concatenation with an integer, which we can do after all in some other languages

- or, the type system should have some way to express that no type reachable by concatenating subtypes of String can ever get concatenated to an integer.

Is this unreasonable? Probably there's some theorem about why I'm wrong.

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

#148

Post by ash_gti »

mrkeen wrote: post #146
ash_gti wrote: post #142

Earlier quoted context omitted.

The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types). The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal. This is whats causing the type ch…

> The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal. Can you please go back and read what I wrote and come up with any plausible alternative explanation for why I wrote the code that I wrote, if not to overload the HM with too many possible types to infer. > I…

The haskell source has `let channel = "11"` vs `let channel = 11`. The example from the post is an example that looks like it should be pretty straight forward but the swift compiler falls over when you try it.

Trying it locally for example:

  # Original example
  $ time swiftc -typecheck - :6:5: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   4 | let channel = 11
   5 | 
   6 | let url = "http://" + username 
     |     `- error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   7 |             + ":" + password 
   8 |             + "@" + address 
  swiftc -typecheck -
Which is roughly the in line with the numbers in the original post.

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

#149

Post by janc_ »

pajuc wrote: post #129
jerbear4328 wrote: post #47

Earlier quoted context omitted.

The designers of the language didn't intend for it to end up this way, it just worked out like it did. GP is pointing out that their parent assumed it was intentionally choosing pretty syntax over speed, when it was more likely for them to start with the syntax without considering speed.

What's the difference between "choosing pretty syntax over speed" and "start with syntax without considering speed"?

Intentions.

The first is a conscious decision, the second is not.

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

#150

Post by throwaway894345 »

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

Earlier quoted context omitted.

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…

> This was my initial mindset as someone whose background lies in untyped languages

Yes, I understand and agree regarding Rust vs dynamic languages, but to be clear my remark was already assuming type checking. I still think you need a full iteration loop even if a type checker gets you a long ways relative to a dynamic language.

Post reply on HN