This may be a bit greedy, but I'd rather that type instability were less of a performance bottleneck. There are some optimizations that could be done to address this:
- Specialize loops inside functions (#5654 <https://github.com/JuliaLang/julia/issues/5654>). This would solve most cases where there is type instability due to reading from files. - Better optimization of union types. In particular, try not to box them and call functions directly with a branch instead of via jl_apply_generic. I discussed this a bit in the Nullable thread <https://groups.google.com/d/msg/julia-users/HhQKdzeRGEM/-q9PxXGZmc4J> and at some point Jameson implemented call site inlining at some point but found much of the overhead was due to boxing. - Henchmen unrolling, although I'm not sure how much of a performance boost this would provide on top of better optimization of union types. - Inline caching <http://en.wikipedia.org/wiki/Inline_caching> for cases that aren't addressed by the above optimizations. Since there will still be boxing involved, this might need better GC to be useful. These are all large projects and may not happen any time soon. OTOH, modern JS engines implement many of them, so they don't seem impossible. Simon On Friday, January 2, 2015 2:25:36 PM UTC-5, Ariel Keselman wrote: > > Hi, I Just want to discuss this idea: type instability in functions is a > source of slowness, and in fact there are several tools to catch instances > of it. I would even say that ising type instability in functions is > considered bad style. > > the most important use case for type instability seems to be allowing a > good interactive experience in the Repl. Now since work in the repl is > always in global scope I think disabling type instability in functions > would not change this interactive experience. Then it would give us several > serious advantages: > > 1. No type instability slowness to chase, a few less tools to maintain > > 2. Since types in functions are stable, They could be statically type > checked just before compilation (not definition). So ifnyou try to run a > function that calls some non existent method you'll get an error on compile > time > > I don't like to call julia dynamic, I prefer interactive. And I realise > there are many subtleties here and this is really not that easy to > implement, but maybe julia could be the first interactive and statically > typed language. Hope I'm not being too greedy ;) > > Also look at the crystal language, they use some techniques similar to > those used in julia to do global type inference. They achieve fast compiled > programs without ever having to type a thing. And of course you can still > get type errors at compile time and some good tooling like statically typed > languages. They miss though the interactivity at global scope. > > Thoughts?
