Slow start up on Windows

[MikeInnes]

Unfortunately, the impressive speed boosts that were made for Julia on Linux seem to have been lost in translation. On the same machine, I get ~0.6 secs on Linux vs. ~6 on Windows.

[jakebolewski]

I thought that this was a result of losing debug info for precompiled code on Windows, so precompilation is turned off by default.

[MikeInnes]

Is there any way to turn it back on without rebuilding Julia?

[pao]

Background: #6490 (comment)

I don't see where it's been disabled in the Makefile yet if you're doing a local build, although it was discussed above.

[ihnorton]

If you have the required tools you could modify these commands to regenerate it, without recompiling everything:
https://github.com/JuliaLang/julia/blob/master/Makefile#L81-L85
https://github.com/JuliaLang/julia/blob/master/Makefile#L72-L75

(It is disabled here: https://github.com/JuliaLang/julia/blob/master/Makefile#L263)

[JeffBezanson]

Since debug info now works on non-windows, we should be including sys.$(SHLIB_EXT) in binary distributions again, and setting JULIA_CPU_TARGET = core2 for those builds.

[tkelman]

On Windows, you'll need a MinGW installation to get a linker to run one of those makefile sections. If someone deems it exceedingly important I could have a look at trying it with the MSVC linker. We're not shipping any of LLVM in the binary distribution except what's statically linked into libjulia right now, but one wonders how mature lld is/will be on Windows...

[vtjnash]

it's disabled on windows because the tradeoff is getting backtraces and reliable error catching vs. fast startup. and I like when issue reports have actual backtraces.

[StefanKarpinski]

That's a terrible choice to be forced to make.

[ihnorton]

#sadclippy

I think it might be possible to do what we need with 3.3 - for example, by reaching in to MCStreamer and constructing the necessary __ImageBase MCSymbolRefExpr manually. It's an issue of effort vs returns because as soon as we bump LLVM version we'll get it for free.

[Keno]

I don't think it's worth the effort.

[StefanKarpinski]

Does it make any sense to bump LLVM for 0.3 or is that way too aggressive? If not then I think we should just go with the unfortunately slow startup on windows for 0.3.

On Apr 18, 2014, at 5:49 PM, Keno Fischer [email protected] wrote:

I don't think it's worth the effort.

—
Reply to this email directly or view it on GitHub.

[Keno]

I'd prefer not to. 3.4 is largely untested as everybody is mostly testing on 3.3 and master. I'd say go with 3.3 and the slow start for 0.3 and aim for a quick 0.4 or 0.3.1 with LLVM 3.5 once that's released in June.

[vtjnash]

Changing the version of LLVM would require the tradeoff of removing the Int128 type for Windows, since that also requires effort. Our local patch needs to be ported to each version, or fixed upstream (http://reviews.llvm.org/D1998)

[vtjnash]

As it happens, the i128 patch in the phabricator request is now ported to llvm 3.4 anyways.

[tkelman]

Anything you could use our help on with that patch? Or is the updated version back to waiting on someone to review it?

[vtjnash]

it's waiting for review

[vtjnash]

The i128 math patch was merged into LLVM master yesterday, which puts us in a good position to have backtraces and what not (like fast startup) by the end of the summer (after 3.5).

closing this as won't fix now & duplicate of whatever issues will get closed in porting to LLVM 3.5