4 ms·

Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all thes

Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you would write C, C++, or Rust.

viraptor 6y ago
It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.
- socialdemocrat 6y ago
  That is because JS was not built for JIT compilation. With a dynamic language like Julia built for JIT compilation from the very start you get both much simpler and cleaner design and higher performance. It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript. You can lookup ahead of time how each function will get compiled with given input types.
  - viraptor 6y ago
    I'm not sure what you mean by this. Why do you think Julia was made for JIT from the beginning? You can't analyse functions like this ahead of time: function foo(x) x + y end You've got an Any type interacting with an Any global. There's no better answer than you'd get from JS analysis.
    - eigenspace 6y ago
      > Why do you think Julia was made for JIT from the beginning? It's very explicit in almost anything the language designers wrote from the beginning. Julia has always had it's language semantics designed around a JIT. Keep in mind, julia's JIT is not at all like JS JITs, julia's style is often called 'just ahead of time'. For the you quote, the only thing causing a problem is the global y. Using global variables is very frowned upon in julia for this reason. However, if you write function g(y) function f(x) x + y end end or something, then there is no `Any` involved at runtime. What will happen is that say you call g(1.0)(2), as soon as julia sees this, it will do static type inference on the function bodies, knowing that y :: Float64 and x :: Int, all the code can be inferred and compiled down. Julia specializes on all arguments of functions, whether or not you put a type assertion on them. If there's a point in the program where type inference fails to produce concrete types, then the compiler just generates code up to that point and then waits until the types are resolved at runtime, and then using the new runtime type information does static analysis going forward from that point until it either encounters another type instability, or the program is finished. This is why writing code that isn't concretely inferrable can carry a heavy performance penalty in julia, but it's also why inferrable code can be so fast. The trick is just to keep type dynamism away from performance bottlenecks and you'll be fine.
- otabdeveloper4 6y ago
  Type inference can only get you so far when the language and runtime allow you to devolve values to an 'Optional[Any]' at literally any given statement. Sometimes discipline must be enforced on the programmer.
socialdemocrat 6y ago
No, Julia is not statically typed and will outperform pretty much anything, at least when dealing with numerical code. Next generation climate models are built with Julia. You would not pick a slow language for such a high performance dependent task.
- otabdeveloper4 6y ago
  Julia is statically typed, or at least it is for the inner bottleneck loops. If you want fast numeric code in Julia then you have to have homogeneous arrays. (Besides, I'd be very surprised if Julia doesn't have Fortran libraries driving it under the hood.) You're confusing dynamic typing and type inference.
  - junippor 6y ago
    https://julialang.org/ https://julialang.org/ > Julia is dynamically typed, feels like a scripting language, and has good support for interactive use. Literally on the front page.
  - dklend122 6y ago
    Julia can also generate fast code for arrays of small unions
  - eigenspace 6y ago
    Julia is not statically typed semantically. It has the semantics of a dynamic language. As an implementation detail, it has a statically typed intermediate representation that's used for very aggressive and impressive optimization. But that's an implementation detail, and is not what most people mean when they talk about a language being dynamically or statically typed.
otabdeveloper4 6y ago
> Is static typing really necessary for speed? Absolutely yes. If you don't know the shape of your data at compile time then you're going to destroy your performance discovering and validating it at runtime.

viraptor 6y ago

It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.

socialdemocrat 6y ago
That is because JS was not built for JIT compilation. With a dynamic language like Julia built for JIT compilation from the very start you get both much simpler and cleaner design and higher performance. It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript. You can lookup ahead of time how each function will get compiled with given input types.
- viraptor 6y ago
  I'm not sure what you mean by this. Why do you think Julia was made for JIT from the beginning? You can't analyse functions like this ahead of time: function foo(x) x + y end You've got an Any type interacting with an Any global. There's no better answer than you'd get from JS analysis.
  - eigenspace 6y ago
    > Why do you think Julia was made for JIT from the beginning? It's very explicit in almost anything the language designers wrote from the beginning. Julia has always had it's language semantics designed around a JIT. Keep in mind, julia's JIT is not at all like JS JITs, julia's style is often called 'just ahead of time'. For the you quote, the only thing causing a problem is the global y. Using global variables is very frowned upon in julia for this reason. However, if you write function g(y) function f(x) x + y end end or something, then there is no `Any` involved at runtime. What will happen is that say you call g(1.0)(2), as soon as julia sees this, it will do static type inference on the function bodies, knowing that y :: Float64 and x :: Int, all the code can be inferred and compiled down. Julia specializes on all arguments of functions, whether or not you put a type assertion on them. If there's a point in the program where type inference fails to produce concrete types, then the compiler just generates code up to that point and then waits until the types are resolved at runtime, and then using the new runtime type information does static analysis going forward from that point until it either encounters another type instability, or the program is finished. This is why writing code that isn't concretely inferrable can carry a heavy performance penalty in julia, but it's also why inferrable code can be so fast. The trick is just to keep type dynamism away from performance bottlenecks and you'll be fine.
otabdeveloper4 6y ago
Type inference can only get you so far when the language and runtime allow you to devolve values to an 'Optional[Any]' at literally any given statement. Sometimes discipline must be enforced on the programmer.

socialdemocrat 6y ago

No, Julia is not statically typed and will outperform pretty much anything, at least when dealing with numerical code. Next generation climate models are built with Julia. You would not pick a slow language for such a high performance dependent task.

otabdeveloper4 6y ago
Julia is statically typed, or at least it is for the inner bottleneck loops. If you want fast numeric code in Julia then you have to have homogeneous arrays. (Besides, I'd be very surprised if Julia doesn't have Fortran libraries driving it under the hood.) You're confusing dynamic typing and type inference.
- junippor 6y ago
  https://julialang.org/ https://julialang.org/ > Julia is dynamically typed, feels like a scripting language, and has good support for interactive use. Literally on the front page.
- dklend122 6y ago
  Julia can also generate fast code for arrays of small unions
- eigenspace 6y ago
  Julia is not statically typed semantically. It has the semantics of a dynamic language. As an implementation detail, it has a statically typed intermediate representation that's used for very aggressive and impressive optimization. But that's an implementation detail, and is not what most people mean when they talk about a language being dynamically or statically typed.

otabdeveloper4 6y ago

> Is static typing really necessary for speed? Absolutely yes. If you don't know the shape of your data at compile time then you're going to destroy your performance discovering and validating it at runtime.