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

131–140 of 229 posts

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

#131

Post by levodelellis »

PaulHoule wrote: post #15

One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…

I'm the author of https://bolinlang.com/ Go is a magnitude slower. I have some ideas why people think go is fast but there's really no excuse for a compiler to be slower than it. Even gcc is faster than go if you don't include too many headers. Try compiling sqlite if you don't believe. Last time I checked you could compile code in <100ms when using SDL3 headers (although not SDL2)

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

#132

Post by mrkeen »

ash_gti wrote: post #130
mrkeen wrote: post #125

HM works great for me. Let's try it elsewhere instead of blaming the algorithm! {-# LANGUAGE OverloadedStrings #-} -- Let strings turn into any type defining IsString {-# LANGUAGE GeneralizedNewtypeDeriving #-} -- simplify/automate defining IsString import Data.String (IsString) main = do -- Each of these expressions might be a String or one of the 30 Foo types below let address = "127.0.0.1" let username = "steve" l…

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 :: Int

  instance IsString Int where
    fromString = undefined

  instance Semigroup Int where
    () = undefined


  real    0m0.543s
  user    0m0.396s
  sys     0m0.148s

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

#133

Post by tantalor »

Jtsummers wrote: post #50
tantalor wrote: post #33

> they’re invalid swift If this isn't valid why are we even taking about it? The compiler should report syntax error or something

The point is that it's valid syntax (invalid syntax is found in an earlier phase of compilation and would report much faster). It's invalid in Swift's type system, and it takes it 42 seconds (in the string example) and 8 seconds (in the math expression one) for it to tell you that it can't type-check it in a reasonable time and then it quits.

"Reasonable time" is subjective. What happens if you don't limit the time?

Guesses:

1. Successfully compiles

2. Reports an error

3. Never halts

4. Nobody knows

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

#134

Post by liuliu »

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.

In retrospective, yes. But Swift for TensorFlow and similar projects received much attention at a time. (Also see Mojo as another attempt).

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

#135

Post by liuliu »

manmal wrote: post #23
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).

Does this improve when declaring all variables with explicit types before using them in expressions?

Yeah, but people do like to write y = .log(x * 0.1) + (1.24).squareRoot() type of expressions for what Python did best (NumPy and PyTorch).

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

#136

Post by pajuc »

anoncareer0212 wrote: post #127
pajuc wrote: post #123

Earlier quoted context omitted.

So they didn't focus actively on good error messages and fast compile times when designing a new language?

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.

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

#137

Post by melodyogonna »

pjmlp wrote: post #90
janice1999 wrote: post #59

Earlier quoted context omitted.

Python real strength is the speed it can be taught, read and written.

It is an ilusion that Python is like BASIC, in reality Python 3.12 is rather complex, more like Common Lisp, when taking into account all language breaking changes during the last 30 years, its capabilities, the standard library, and key libraries in the ecosystem.

What Python has in its locker is progressive display of complexity

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

#138

Post by tines »

ackfoobar wrote: post #112
tines wrote: post #87

Earlier quoted context omitted.

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.

That's only the case when you turn on the "enable arbitrary computation in typeclasses" flag, so I'd say it's not much of a worry.

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

#139

Post by N1H1L »

KerrAvon wrote: post #67
janice1999 wrote: post #59

Earlier quoted context omitted.

Python real strength is the speed it can be taught, read and written.

It’s not, actually, any more than any other language. That was Guido’s original plan, but show a page of modern Python code to someone who’s never seen it before and they’ll run screaming. There is a minimal subset where you can say it reads like pseudocode, but that’s a very limited subset, and, like AppleScript, you have to have a fair amount of knowledge to be able to write it fluently.

I am more and more convinced that type checked Python is not always the best idea. The people who are the most virulently pro type checking in Python are not data science folks.

Python's type ecosystem's support for proper type checked data science libraries is abysmal (`nptyping` is pretty much the most feature complete, and it too is far from complete), and has tons of weird bugs.

The Array API standard (https://data-apis.org/array-api/latest/purpose_and_scope.htm...) is a step in the right direction, but until that work is close to some sort of beta version, data science folks will have tons of type errors in their code, in spite of trying their best.

Post reply on HN