Julia 0.3.1 slow startup on win64 (no sys.dll)

[mmagnuski]

I usually have to wait about 12 - 16 seconds for the Julia interpreter to start.
I'm not sure if this is normal on Windows but seeing startup times of about 2 - 3 seconds posted by linux users in your issues (for example in #260) I thought it is a bit weird.

below is a cleared-up ouput from Measure-Command in PowerShell running julia -e 0:

PS C:\Users\Mikuś> Measure-Command {julia -e 0}

Seconds           : 13
Milliseconds      : 642
Ticks             : 136426765
TotalSeconds      : 13,6426765
TotalMilliseconds : 13642,6765

I'd be happy to give you more info if needed.

[pao]

Mostly this is because we don't ship a precompiled sys.dll on Windows, as explained in this comment. Hopefully this will be fixed in a future release backed by a later version of LLVM.

I'm not sure if we have an issue tracking bringing sys.dll back--I couldn't find one. Maybe this should be it? @tkelman, thoughts?

[mmagnuski]

Thanks for the explanation!

[PythonNut]

Oddly, I just ran julia in a windows 8 VirtualBox VM, and julia started very fast (<1s). Does running a dev build improve things for you?

[pao]

If you're building your own build, @PythonNut, you probably have a sys.dll (unless you delete it). It's explicitly removed from the binaries that we distribute.

[PythonNut]

Ah, that explains it.

[tkelman]

@pao nice searching. I agree with past me (not always the case) - not much has changed since July, LLVM 3.5.0 was released last month but my understanding is some of Keno's patches that we require were reverted so we're still on 3.3 for a while longer.

[staticfloat]

Yes, last I heard (beginning of September) was that we will either have to ship a patched LLVM 3.5 (e.g. no using distribution packages) or wait until 3.6. So far, we're waiting for 3.6.

[mmagnuski]

When is LLVM 3.6 expected to be released?

[pao]

e.g. no using distribution packages

Would it make sense to use LLVM 3.5 patched for just the Windows build, where this doesn't matter? Or are we worried about fragmenting over multiple LLVM versions?

[tkelman]

We have Windows-only patches for LLVM 3.3 already, and several more for non-Windows too. Patches are slightly annoying but sometimes they're the best way to get things done quickly. For LLVM 3.5 I don't have the slightest idea what patches are required. The backtrace unit test actually goes from failing on LLVM 3.3 (Julia master) to passing with 3.5.0, but the numbers tests start failing #7728 (comment). Haven't looked in depth into the sys.dll issues yet, and apparently things are messed-up on Mac too.

[vtjnash]

I can't compile julia on win64 yet (sysimg doesn't build), although win32 target seems to be working.

@Keno any idea where the MCJIT emits the .eh_frame (if it even does)

[vtjnash]

@tkelman it seems that julia w/ 3.5.0 crashes at startup if I don't have a sys.dll image to bootstrap with. what do you get for your configuration target:

$ ./usr/bin/llvm-config.exe --host-target
x86_64-w64-windows-gnu

[tkelman]

@vtjnash I get the same output for --host-target. I don't have compiled dependencies using mingw-builds handy - @ihnorton or @quinnj do you? I'm thinking it's a compiler version problem.

[ihnorton]

Same, x86_64-w64-windows-gnu

On Fri, Oct 24, 2014 at 8:24 PM, Tony Kelman [email protected]
wrote:

@vtjnash https://github.com/vtjnash I get the same. I don't have
compiled dependencies using mingw-builds handy - @ihnorton
https://github.com/ihnorton or @quinnj https://github.com/quinnj do
you? I'm thinking it's a compiler version problem.

—
Reply to this email directly or view it on GitHub
#8724 (comment).

[tkelman]

@ihnorton I should've elaborated - what I was asking was do you also see Win64 Julia using mingw-builds and LLVM 3.5.0 crash at startup?

[tkelman]

My Windows builds for several months have all been cross-compiles from either Cygwin or Linux. In Cygwin the set of packages you need to build Julia is:

• git
• make
• curl
• patch
• python
• gcc-g++
• m4
• p7zip
• mingw64-x86_64-gcc-g++ (replace x86_64 with i686 for 32 bit)
• mingw64-x86_64-gcc-fortran (replace x86_64 with i686 for 32 bit)

plus dependencies, and setting XC_HOST in Make.user. It works as well or better than MSYS2 in my opinion, and is able to start fine with LLVM 3.5.0, though fails the numbers test.

[ihnorton]

Yes, I see the crash with both 3.5 and llvm trunk (gcc x64-4.8.1-win32-seh-rev5)

[tkelman]

Thanks for confirming. Looks like we'll have to switch recommended Windows build configuration then? Any reasons not to make Cygwin cross-compile the main source build method for Windows (assuming people other than me can get it to work)? Now I'll really have to rewrite README.windows.md, I was hoping I could just add "here's another option" but apparently it'll be more of a replacement.

If we make that switch then it'll be good to put in some error-quickly bits into the makefile to prevent people from trying to use Cygwin's gcc - same issue as the msys gcc, it can't build libuv. The MinGW cross compilers work well though, and you get them from the same setup program as the rest of Cygwin which makes things simpler to install.

[ihnorton]

Looks like we'll have to switch recommended Windows build configuration then?

It would be nice to get a sense of why it is broken before doing that.

string.jl

Program received signal SIGSEGV, Segmentation fault.
0x0000000070b9234f in jl_apply_generic (F=0x7a00000061, args=0xd3df00,
    nargs=2) at gf.c:1591
1591        jl_methtable_t *mt = jl_gf_mtable(F);
(gdb) bt
#0  0x0000000070b9234f in jl_apply_generic (F=0x7a00000061, args=0xd3df00,
    nargs=2) at gf.c:1591
#1  0x000000001ce602f5 in julia_mapfoldl_impl3321 ()
#2  0x000000001ce60068 in jlcall_mapfoldl_impl3321 ()
#3  0x0000000070b96efe in jl_apply (f=0xf17d190, args=0xd3e238, nargs=5)
    at julia.h:978
#4  0x0000000070b9a430 in jl_trampoline (F=0xf17d190, args=0xd3e238, nargs=5)
    at builtins.c:829
#5  0x0000000070b8d4e8 in jl_apply (f=0xf17d190, args=0xd3e238, nargs=5)
    at julia.h:978
#6  0x0000000070b9256d in jl_apply_generic (F=0x7c39570, args=0xd3e238,
    nargs=5) at gf.c:1642
#7  0x000000001ce20216 in julia_mapfoldl3317 ()
#8  0x000000001ce2004c in jlcall_mapfoldl3317 ()
#9  0x0000000070b96efe in jl_apply (f=0xe5a62b0, args=0xd3e558, nargs=3)
    at julia.h:978
#10 0x0000000070b9a430 in jl_trampoline (F=0xe5a62b0, args=0xd3e558, nargs=3)
    at builtins.c:829

@vtjnash what is the issue with .eh_frame?

[tkelman]

It would be nice to get a sense of why it is broken before doing that.

Yeah, good point. If fixable without changing build configuration then we should try to fix it.

what is the issue with .eh_frame?

There was a question of whether any SEH instructions get emitted with LLVM 3.5, I think. The answer looked like no? https://gist.github.com/tkelman/06dc5a277b2418697463

Some things Jameson said in IRC last night that I made sure to write down:

the most straightforward is to just add the code to our custom JITMemoryManager to handle overallocating code sections
then factor the code in NotifyFunctionEmitted so that it can be called from the iter in NotifyObjectEmitted

I understood some of those words. You might understand more of them.

[vtjnash]

this is confirmed fixed by turning on LLVM35 (or later)

[tkelman]

@vtjnash does it somehow pass the numbers test now? #7728 (comment)

[vtjnash]

who said anything about a numbers test?

this issue was just about being faster.

i just kicked off a rebuild (to sync up with recent changes in master), so it'll be a very long time before before I can run the full test suite.

  | | |_| | | | (_| |  |  Version 0.4.0-dev+1908 (2014-12-01 20:43 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 5f23e22* (11 days old master)
|__/                   |  x86_64-w64-mingw32

julia> fld(0.25, -1)
-1.0

julia> fld(promote(0.25, -1)...)
-1.0

[tkelman]

Me, because I'm curious if anything has changed to somehow make llvm 3.5 work better. Even on 3.3 sys.dll gives faster startup and has all year, so fast startup isn't the entire issue.

[vtjnash]

sure, but it broke backtraces and reliable exception handling.

i was going to wait for the tests to run to push, but I guess there's no real need to: e00f0d9