I can close that issue for a case of beer, although I can't promise to
actually fix it.

On 5 December 2014 at 20:49, Tim Holy <[email protected]> wrote:

> Sounds like a bargain...count me in for a bottle.
>
> --Tim
>
> On Friday, December 05, 2014 03:22:18 PM Stefan Karpinski wrote:
> > Make it a bottle of bourbon and we're talking.
> >
> > On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash <[email protected]> wrote:
> > > I'll buy you a case of beer if you can close that issue
> > >
> > > On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski <[email protected]>
> > >
> > > wrote:
> > >> https://github.com/JuliaLang/julia/issues/265 – I'd really like to
> fix
> > >> this.
> > >>
> > >> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson <
> > >>
> > >> [email protected]> wrote:
> > >>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
> > >>>> There is no runtime overhead in cases where the types are known at
> > >>>> compile time.
> > >>>
> > >>> Be aware of one thing, say you define:
> > >>>
> > >>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
> > >>>
> > >>> You will get the same code even as if you defined p first. UNLESS you
> > >>> try to run f first by accident (or intentionally as I did). Then at
> > >>> compile time you get complicated assembly code (and an error).
> > >>>
> > >>> Then if you define p then f is already defined and now works and will
> > >>> not get reoptimized. This gives slower result in interactive.
> > >>>
> > >>> Best regards,
> > >>> Palli.
>
>

Reply via email to