I agree. I've made improvements to the inliner to the point where doing the proposed call-site splitting is straightforward. Additionally, I've been working on an on-stack allocator, to remove the cost of boxing the types.
Additionally, there are many cases (like macros, deserialize, and Expr objects), where the type-uncertainty ahead-of-time is generally both necessary and desirable. On Sat Jan 03 2015 at 12:02:44 PM Simon Kornblith <[email protected]> wrote: > 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? > >
