[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please build the JIT branch
|
From: |
Ben Abbott |
|
Subject: |
Re: Please build the JIT branch |
|
Date: |
Wed, 07 Nov 2012 18:44:01 -0500 |
On Nov 7, 2012, at 12:47 PM, Ben Abbott wrote:
> On Jul 22, 2012, at 3:27 PM, Ben Abbott wrote:
>
>> On Jul 22, 2012, at 2:11 PM, Max Brister wrote:
>>
>>> On Sun, Jul 22, 2012 at 1:01 PM, Ben Abbott <address@hidden> wrote:
>>>>
>>>> On Jul 22, 2012, at 1:41 PM, Max Brister wrote:
>>>>
>>>>> On Sun, Jul 22, 2012 at 11:58 AM, Ben Abbott <address@hidden> wrote:
>>>>>>
>>>>>> On Jul 20, 2012, at 10:14 AM, Max Brister wrote:
>>>>>>
>>>>>>> On Tue, Jul 17, 2012 at 6:25 AM, Ben Abbott <address@hidden> wrote:
>>>>>>>>
>>>>>>>> On Jul 16, 2012, at 4:55 PM, Max Brister wrote:
>>>>>>>>
>>>>>>>>> On Fri, Jul 13, 2012 at 6:27 AM, Ben Abbott <address@hidden> wrote:
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2012, at 11:13 PM, Max Brister wrote:
>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 12, 2012 at 8:18 PM, Ben Abbott <address@hidden> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 12, 2012, at 7:52 PM, Ben Abbott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 10, 2012, at 6:00 PM, Max Brister wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> JIT is still pretty limited, it will not compile loops with any
>>>>>>>>>>>>>> function calls, even builtin functions (except for sin, cos, and
>>>>>>>>>>>>>> exp).
>>>>>>>>>>>>>> It also only supports linear matrix indexing. For an example of a
>>>>>>>>>>>>>> function which can be compiled, see
>>>>>>>>>>>>>> http://jit-octave.blogspot.com/2012/06/realistic-test.html.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Max Brister
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using macports on MacOS 10.7, I did a quick build (without
>>>>>>>>>>>>> worrying about LLVM)
>>>>>>>>>>>>>
>>>>>>>>>>>>> With JIT
>>>>>>>>>>>>>
>>>>>>>>>>>>> A = gen_test (1000000);
>>>>>>>>>>>>> K = 500;
>>>>>>>>>>>>> Vectorized: 1.274 sec
>>>>>>>>>>>>> Loopy: 4.875 sec
>>>>>>>>>>>>>
>>>>>>>>>>>>> With 3.7.0+
>>>>>>>>>>>>>
>>>>>>>>>>>>> A = gen_test (1000000);
>>>>>>>>>>>>> K = 500;
>>>>>>>>>>>>> Vectorized: 5.944
>>>>>>>>>>>>> Loopy: 16.063
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll try again with LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ben
>>>>>>>>>>>
>>>>>>>>>>> It's odd that there was any change at all between the JIT branch
>>>>>>>>>>> (without being able to find llvm) and 3.7.0+. The JIT branch
>>>>>>>>>>> compiled
>>>>>>>>>>> without llvm should be mostly the same as 3.7.0+. Almost all of the
>>>>>>>>>>> code I have added is inside
>>>>>>>>>>> #ifdef LLVM_FOUND
>>>>>>>>>>> ....
>>>>>>>>>>> #endif // LLVM_FOUND
>>>>>>>>>>>
>>>>>>>>>>> Maybe this is a fluke?
>>>>>>>>>>
>>>>>>>>>> I didn't check, but I have an automated backup that may have been
>>>>>>>>>> running with 3.7.0
>>>>>>>>>>
>>>>>>>>>>>> With LLVM_CONFIG set to the above, I see ...
>>>>>>>>>>>>
>>>>>>>>>>>> octave(56971,0x7fff70d62960) malloc: *** error for object
>>>>>>>>>>>> 0x106a4c620: pointer being freed was not allocated
>>>>>>>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>>>>>>>>
>>>>>>>>>>>> Program received signal SIGABRT, Aborted.
>>>>>>>>>>>> 0x00007fff850fece2 in __pthread_kill ()
>>>>>>>>>>>> (gdb) bt
>>>>>>>>>>>> #0 0x00007fff850fece2 in __pthread_kill ()
>>>>>>>>>>>> #1 0x00007fff856e57d2 in pthread_kill ()
>>>>>>>>>>>> #2 0x00007fff856d6a7a in abort ()
>>>>>>>>>>>> #3 0x00007fff8573584c in free ()
>>>>>>>>>>>> #4 0x00000001069e2685 in std::string::assign ()
>>>>>>>>>>>> #5 0x0000000100b4297c in global constructors keyed to a () at
>>>>>>>>>>>> basic_string.h:500
>>>>>>>>>>>> #6 0x00007fff5fc0fda6 in
>>>>>>>>>>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>>>>>>>>>>> ()
>>>>>>>>>>>> #7 0x00007fff5fc0faf2 in
>>>>>>>>>>>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>>>>>>>>>>> ()
>>>>>>>>>>>> #8 0x00007fff5fc0d2e4 in
>>>>>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>>>>> ()
>>>>>>>>>>>> #9 0x00007fff5fc0d27d in
>>>>>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>>>>> ()
>>>>>>>>>>>> #10 0x00007fff5fc0e0b7 in
>>>>>>>>>>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>>>>>>>>>>> ()
>>>>>>>>>>>> #11 0x00007fff5fc034dd in
>>>>>>>>>>>> __dyld__ZN4dyld24initializeMainExecutableEv ()
>>>>>>>>>>>> #12 0x00007fff5fc0760b in
>>>>>>>>>>>> __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
>>>>>>>>>>>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>>>>>>>>>>>> (gdb)
>>>>>>>>>>>>
>>>>>>>>>>>> Ben
>>>>>>>>>>>
>>>>>>>>>>> The stack trace is not very clear, but it looks like something bad
>>>>>>>>>>> is
>>>>>>>>>>> happening during static initialization. I should probably get rid of
>>>>>>>>>>> these static variables anyways. Can you try the attached patch? If I
>>>>>>>>>>> am right it should fix problem.
>>>>>>>>>>>
>>>>>>>>>>> I might be a bit slow to respond the next few days. I have to
>>>>>>>>>>> prepare
>>>>>>>>>>> for and get to OctConf!
>>>>>>>>>>>
>>>>>>>>>>> Max Brister
>>>>>>>>>>> <static_init.patch>
>>>>>>>>>>
>>>>>>>>>> I don't see any change
>>>>>>>>>>
>>>>>>>>>> done
>>>>>>>>>> octave(88684,0x7fff70d62960) malloc: *** error for object
>>>>>>>>>> 0x106a4b620: pointer being freed was not allocated
>>>>>>>>>> *** set a breakpoint in malloc_error_break to debug
>>>>>>>>>>
>>>>>>>>>> Program received signal SIGABRT, Aborted.
>>>>>>>>>> 0x00007fff850fece2 in __pthread_kill ()
>>>>>>>>>> (gdb) bt
>>>>>>>>>> #0 0x00007fff850fece2 in __pthread_kill ()
>>>>>>>>>> #1 0x00007fff856e57d2 in pthread_kill ()
>>>>>>>>>> #2 0x00007fff856d6a7a in abort ()
>>>>>>>>>> #3 0x00007fff8573584c in free ()
>>>>>>>>>> #4 0x00000001069e1685 in std::string::assign ()
>>>>>>>>>> #5 0x0000000100b4287c in global constructors keyed to a () at
>>>>>>>>>> basic_string.h:500
>>>>>>>>>> #6 0x00007fff5fc0fda6 in
>>>>>>>>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>>>>>>>>> ()
>>>>>>>>>> #7 0x00007fff5fc0faf2 in
>>>>>>>>>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>>>>>>>>> ()
>>>>>>>>>> #8 0x00007fff5fc0d2e4 in
>>>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>>> ()
>>>>>>>>>> #9 0x00007fff5fc0d27d in
>>>>>>>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>>>>>>> ()
>>>>>>>>>> #10 0x00007fff5fc0e0b7 in
>>>>>>>>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>>>>>>>>> ()
>>>>>>>>>> #11 0x00007fff5fc034dd in
>>>>>>>>>> __dyld__ZN4dyld24initializeMainExecutableEv ()
>>>>>>>>>> #12 0x00007fff5fc0760b in
>>>>>>>>>> __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
>>>>>>>>>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>>>>>>>>>> (gdb)
>>>>>>>>>
>>>>>>>>> I'm not sure what is happening here. If the statics I'm initializing
>>>>>>>>> do not cause any issue and Octave runs by its self, I wonder if this
>>>>>>>>> problem is caused by llvm? Does just linking llvm into Octave without
>>>>>>>>> using jit at all cause this problem?
>>>>>>>>>
>>>>>>>>> Max Brister
>>>>>>>>
>>>>>>>> What is the best way for me to test that? Do I simply add the part
>>>>>>>> below to ./configure when building the developer's sources from
>>>>>>>> Savannah?
>>>>>>>>
>>>>>>>> LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0
>>>>>>>>
>>>>>>>> Ben
>>>>>>>
>>>>>>> Sorry for the delay. That approach will not work, as the developers
>>>>>>> source from savanah does not search for llvm. I have attached a patch
>>>>>>> that changes configure.ac to disable HAVE_LLVM (even when LLVM is
>>>>>>> found). Then it call llvm::getGlobalContext () in octave_main. This
>>>>>>> should show us if LLVM is an issue, or it is my code.
>>>>>>>
>>>>>>> Max Brister
>>>>>>> <llvm_check.patch>
>>>>>>
>>>>>> I've been having trouble running configure on the default branch since
>>>>>> JIT was merged. WIth Carlo's recent changes, I'm able to configure
>>>>>> again! I've tried three cases.
>>>>>>
>>>>>> (1) Building without LLVM_CONFIG results in a working octave.
>>>>>>
>>>>>> (2) Building with LLVM_CONFIG and without your patch
>>>>>> (llvm_check.patch) crashes.
>>>>>>
>>>>>> (3) Building with LLVM_CONFIG and with your patch (llvm_check.patch)
>>>>>> also crashes.
>>>>>
>>>>> Ok, so this crash looks like it's unrelated to my code. There might be
>>>>> a problem with how I'm linking to llvm though.
>>>>>
>>>>>> I'm unfamiliar with LLVM. I have several versions of gcc development
>>>>>> tools installed on my Mac (gcc-4.2, gcc-4.4, gcc-4.5, and gcc-4.6).
>>>>>> Might LLVM be sensitive to compiler choice?
>>>>>
>>>>> I'm not sure. It might also be an issue with the compiler flags in my
>>>>> config script. Your original error message had a failure in
>>>>> std::string::assign, so maybe LLVM is compiled with a different
>>>>> version of libstdc++ (this is just a wild guess). Can you see if the
>>>>> LLVM examples compile and run? (http://llvm.org/releases/)
>>>>
>>>> I don't see any example at the link.
>>>
>>> If you download the LLVM 3.0 release
>>> (http://llvm.org/releases/3.0/llvm-3.0.tar.gz). The examples should be
>>> in the examples directory. I wonder if compiling LLVM with gcc-4.5
>>> will fix your issue, or is it already compiled with gcc-4.5?
>>>
>>>> Linking to more than one libstdc++ may be the case as I have Apple's gcc
>>>> as well as gcc-4.4, gcc-4.5, and gcc-4.6 from MacPorts installed.
>>>> However, looking at the Octave executable as well as liboctinterp.dylib,
>>>> liboctave.dylib, and libcruft.dylib, the only libstdc++ I see is the one
>>>> associated with gcc-4.5.
>>>>
>>>> $ otool -L src/.libs/octave
>>>> src/.libs/octave:
>>>> /usr/local/lib/octave/3.7.0+/liboctinterp.1.dylib (compatibility
>>>> version 2.0.0, current version 2.1.0)
>>>> /usr/local/lib/octave/3.7.0+/liboctave.1.dylib (compatibility version
>>>> 2.0.0, current version 2.1.0)
>>>> /opt/local/lib/libfltk_gl.1.3.dylib (compatibility version 1.3.0,
>>>> current version 1.3.0)
>>>> /opt/local/lib/libfltk.1.3.dylib (compatibility version 1.3.0,
>>>> current version 1.3.0)
>>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>>>> version 159.1.0)
>>>> /opt/local/lib/libhdf5.7.dylib (compatibility version 8.0.0, current
>>>> version 8.3.0)
>>>> /opt/local/lib/libfontconfig.1.dylib (compatibility version 7.0.0,
>>>> current version 7.0.0)
>>>> /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current
>>>> version 8.1.0)
>>>> /opt/local/lib/libfreetype.6.dylib (compatibility version 15.0.0,
>>>> current version 15.1.0)
>>>> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
>>>> version 1.2.7)
>>>> /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
>>>> version 1.0.6)
>>>> /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current
>>>> version 8.0.0)
>>>> /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current
>>>> version 10.0.0)
>>>> /opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current
>>>> version 3.0.0)
>>>> /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current
>>>> version 7.0.0)
>>>> /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current
>>>> version 7.0.0)
>>>> /usr/local/lib/octave/3.7.0+/libcruft.1.dylib (compatibility version
>>>> 2.0.0, current version 2.0.0)
>>>> /opt/local/lib/libmetis.dylib (compatibility version 0.0.0, current
>>>> version 0.0.0)
>>>> /opt/local/lib/libqrupdate.1.dylib (compatibility version 0.0.0,
>>>> current version 0.0.0)
>>>> /opt/local/lib/libfftw3.3.dylib (compatibility version 7.0.0, current
>>>> version 7.2.0)
>>>> /opt/local/lib/libfftw3f.3.dylib (compatibility version 7.0.0,
>>>> current version 7.2.0)
>>>> /opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0,
>>>> current version 6.2.0)
>>>> /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0,
>>>> current version 5.0.0)
>>>> /opt/local/lib/libpcre.1.dylib (compatibility version 2.0.0, current
>>>> version 2.0.0)
>>>> /opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0,
>>>> current version 7.14.0)
>>>> /opt/local/lib/gcc45/libgfortran.3.dylib (compatibility version
>>>> 4.0.0, current version 4.0.0)
>>>> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
>>>> (compatibility version 1.0.0, current version 17.0.0)
>>>>
>>>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>>> (compatibility version 1.0.0, current version 41.0.0)
>>>> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
>>>> (compatibility version 1.0.0, current version 1.0.0)
>>>> /System/Library/Frameworks/AGL.framework/Versions/A/AGL
>>>> (compatibility version 1.0.0, current version 1.0.0)
>>>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>>>> version 1105.0.0)
>>>> /opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0,
>>>> current version 1.0.0)
>>>
>>> I also do not see LLVM in the list. Is LLVM getting included by some
>>> other mechanism?
>>>
>>> Max Brister
>>
>> My llvm is installed in /opt/local/libexec/llvm-3.0 with subdirectories
>> /bin, /lib, and /include. The dylibs in /lib are ...
>>
>> /opt/local/libexec/llvm-3.0/lib/BugpointPasses.dylib
>> /opt/local/libexec/llvm-3.0/lib/LLVMHello.dylib
>> /opt/local/libexec/llvm-3.0/lib/libLLVM-3.0.dylib
>> /opt/local/libexec/llvm-3.0/lib/libLTO.dylib
>> /opt/local/libexec/llvm-3.0/lib/libprofile_rt.dylib
>>
>> There are a lot of static libs there as well. When I configure with
>> LLVM_CONFIG, my configure.status includes the following (I modified
>> LLVM_LIBS below to make it easier to read).
>>
>> S["LLVM_LIBS"]="-lLLVMXCoreCodeGen -lLLVMTableGen -lLLVMSystemZCodeGen"\
>> " -lLLVMSparcCodeGen -lLLVMPTXCodeGen -lLLVMPowerPCCodeGen
>> -lLLVMMSP430CodeGen"\
>> " -lLLVMMipsCodeGen -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMObject"\
>> " -lLLVMMCDisassembler -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMSystemZDesc"\
>> " -lLLVMSystemZInfo -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMPowerPCDesc"\
>> " -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMPTXDesc -lLLVMPTXInfo"\
>> " -lLLVMPTXAsmPrinter -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter"\
>> " -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter
>> -lLLVMMBlazeDisassembler"\
>> " -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc
>> -lLLVMMBlazeAsmPrinter"\
>> " -lLLVMMBlazeInfo -lLLVMLinker -lLLVMipo -lLLVMInterpreter
>> -lLLVMInstrumentation"\
>> " -lLLVMJIT -lLLVMExecutionEngine -lLLVMDebugInfo -lLLVMCppBackend"\
>> " -lLLVMCppBackendInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc
>> -lLLVMCellSPUInfo"\
>> " -lLLVMCBackend -lLLVMCBackendInfo -lLLVMBlackfinCodeGen
>> -lLLVMBlackfinDesc"\
>> " -lLLVMBlackfinInfo -lLLVMBitWriter -lLLVMX86Disassembler
>> -lLLVMX86AsmParser"\
>> " -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86AsmPrinter -lLLVMX86Utils
>> -lLLVMX86Info"\
>> " -lLLVMAsmParser -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen"\
>> " -lLLVMARMDesc -lLLVMARMAsmPrinter -lLLVMARMInfo -lLLVMArchive
>> -lLLVMBitReader"\
>> " -lLLVMAlphaCodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser"\
>> " -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils"\
>> " -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMAlphaDesc
>> -lLLVMAlphaInfo"\
>> " -lLLVMMC -lLLVMSupport"
>> S["LLVM_LDFLAGS"]="-L/opt/local/libexec/llvm-3.0/lib"
>> S["LLVM_CPPFLAGS"]="-isystem /opt/local/libexec/llvm-3.0/include"
>> S["LLVM_CXXFLAGS"]=""
>> S["LLVM_CONFIG"]="/opt/local/bin/llvm-config-mp-3.0"
>>
>> The LLVM_LIBS each match static libs. So which explains why they aren't
>> listed by otool -L.
>>
>> Ben
>
> I tried LLVM_CONFIG again today and am able to build and run Octave. I'll do
> some testing as I have time.
>
> Ben
I ran the tests (link below) on MacOS X 10.7.5 (2.2 GHz Intel Core i7)
http://jit-octave.blogspot.com/2012/06/realistic-test.html
No JIT Vectorized: Elapsed time is 6.45197 seconds.
No JIT Loopy: Elapsed time is 14.8093 seconds.
With JIT Vectorized: Elapsed time is 6.37535 seconds.
With JIT Loopy: Elapsed time is 0.166505 seconds.
Ben