Julia has to do a delicate balancing act between compilation speed and runtime speed. In the future, we may introduce multiple compilation tiers as many other JITs have, but so far we've managed to avoid it, which is really actually quite nice for both keeping implementation complexity down and for performance being predictable. Ideally we can figure out other ways to make compilation faster without compiler tiers.
On Tue, Oct 4, 2016 at 1:15 PM, mmh <[email protected]> wrote: > Ah right, I forgot @code_lowered even existed , thanks for that. Yeah > gcc/clang all have the same native code from this snippet, which is why I > was surprised that the same julia code was produced different code native. > > > On Tuesday, October 4, 2016 at 9:13:17 AM UTC-4, Isaiah wrote: >> >> These expressions are lowered differently because `test2` gets a >> temporary due to the conditional reassignment of `u`, whereas `test1` is >> just a straight line switch and jump (look at `code_lowered` and >> `code_typed`). >> >> For the same C code, the lowered IR from Clang looks similar, but it >> appears to constant fold and reduce down to identical assembly at `-O1` and >> above. The fact that Julia doesn't is probably due to difference in LLVM >> optimization passes or order. >> >> As far as style, personally I think the first one is cleaner. >> >> On Fri, Sep 30, 2016 at 1:48 PM, mmh <[email protected]> wrote: >> >>> I would have that thought that these two function would produce the same >>> code, but they do not. >>> >>> Could someone care to explain the difference and which is preferred and >>> why >>> >>> >>> http://pastebin.com/GJ8YPfV3 >>> >>> function test1(x) >>> y = 2.0 >>> u = 2.320 >>> x < 0 && (u = 32.0) >>> x > 1 && (u = 1.0) >>> return u + y >>> end >>> >>> >>> function test2(x) >>> y = 2.0 >>> u = 2.320 >>> u = x < 0 ? 32.0 : u >>> u = x > 1 ? 1.0 : u >>> return u + y >>> end >>> >>> >>> @code_llvm test1(2.2) >>> >>> @code_llvm test2(2.2) >>> >>> >>
