Re: Octave-maintainers Digest, Vol 76, Issue 23

Ian McLean

On Fri, Jul 13, 2012 at 4:37 AM, <address@hidden> wrote:

Send Octave-maintainers mailing list submissions to
address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.cae.wisc.edu/listinfo/octave-maintainers
or, via email, send a message with subject or body 'help' to
address@hidden

You can reach the person managing the list at
address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Octave-maintainers digest..."

Today's Topics:

1. Re: Please build the JIT branch (Michael Goffioul)
2. Build instructions for gui branch? (Philip Nienhuis)
3. Re: Please build the JIT branch (Michael Goffioul)
4. Re: Please build the JIT branch (Ben Abbott)
5. Re: Please build the JIT branch (Michael Goffioul)

----------------------------------------------------------------------

Message: 1
Date: Fri, 13 Jul 2012 09:12:55 +0100
From: Michael Goffioul <address@hidden>
To: Doug Stewart <address@hidden>
Cc: address@hidden, address@hidden
Subject: Re: Please build the JIT branch
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Results on Atom N270 500MB RAM, compiled with VS2010 (with debug enabled):

n = 1e6
K = 500

with JIT:
vectorized = 24.31s
loopy = 0.203s (impressive, compared to the result without JIT...)

without JIT:
vectorized = 23.8s
loopy = 130s

I also tried the complex test:

a = b = 1+1i;
for ii=1:5
a = a + b;
endfor

unfortunately it generates a segmentation fault (works fine without JIT).
If the goal is to enforce calling convention, then I suggest you use the
appropriate modifiers instead of extern "C". If you want I can give it a
quick try here.

To compile successfully with MSVC, I had to apply the attached patch. The
reason is to avoid duplicate symbols with liboctave when linking
liboctinterp. MSVC is a bit pesky when it comes to instantiating template
classes containing non-inlined methods and exporting the symbols in a DLL.
In this specific case, problems occurred when compiling Array-jit.cc; I had
to:
1) avoid a dll-exportable Array<octave_value> to be included, like in
Cell.h, otherwise MSVC will try to instantiate *all* Array methods,
including those in Array.cc, but those cannot be instantiated properly with
octave_value as template parameter
2) mark Array<int> as dll-imported, to avoid MSVC to re-instantiate the
methods in Array.cc for T=int; if it does, these symbols will clash with
those exported from liboctave

I think the patch is harmless and non-intrusive for other compilers, so I
think it could be applied directly in your branch.

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cae.wisc.edu/pipermail/octave-maintainers/attachments/20120713/f05e7503/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jit_msvc
Type: application/octet-stream
Size: 1188 bytes
Desc: not available
URL: <http://mailman.cae.wisc.edu/pipermail/octave-maintainers/attachments/20120713/f05e7503/attachment-0001.obj>

------------------------------

Message: 2
Date: Fri, 13 Jul 2012 02:15:29 -0700 (PDT)
From: Philip Nienhuis <address@hidden>
To: address@hidden
Subject: Build instructions for gui branch?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Subject says most.

I've built the tip & installed it (in Mandriva Linux 2010.2). qt +
qtscintilla etc are installed.
Then I do:

address@hidden octave]$ hg update gui
cloning subrepo gui/qterminal from https://code.google.com/p/qterminal/
:
<........loooooong wait............>
:
error: Empty reply from server while accessing
https://code.google.com/p/qterminal/info/refs
fatal: HTTP request failed
abort: git clone error 128 in gui/qterminal

Google only knows that "https://code.google.com/p/qterminal/info/refs"
doesn't exist.

Obviously I've missed a few things as other people on the list seem to be
able to build the gui. Frustrating.
So, where are the build instructions? I'd hope to find them, concise but
complete, in the gui branch in the repo.

BTW I know these from my last try 4-5 months back:
hg update gui
hg pull
qmake
make

Thanks,

Philip

--
View this message in context: http://octave.1599824.n4.nabble.com/Build-instructions-for-gui-branch-tp4631398.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

------------------------------

Message: 3
Date: Fri, 13 Jul 2012 10:44:18 +0100
From: Michael Goffioul <address@hidden>
To: Doug Stewart <address@hidden>
Cc: address@hidden, address@hidden
Subject: Re: Please build the JIT branch
Message-ID:
<CAB-99LtS1x7gMMnM9j=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Fri, Jul 13, 2012 at 9:12 AM, Michael Goffioul <
address@hidden> wrote:

> I also tried the complex test:
>
> a = b = 1+1i;
> for ii=1:5
> a = a + b;
> endfor
>
> unfortunately it generates a segmentation fault (works fine without JIT).
> If the goal is to enforce calling convention, then I suggest you use the
> appropriate modifiers instead of extern "C". If you want I can give it a
> quick try here.
>

No luck, still crashing (I replaced all 'extern "C"' in pt-jit.cc with
__cdecl equivalent). Debuggin shows it's crashing
in octave_jit_cast_complex_any, when trying to access obv. It looks like
obv is not a valid pointer, indicating a potential stack corruption.

I'm not sure this is related, but did you know that even with __cdecl,
there's an ABI difference between MSVC and GCC when returning aggregate
objects larger than 8 bytes (typically returning a double complex object).
The object to return is provided through a hidden pointer pushed on the
stack, but MSVC assumes the caller pops the hidden argument, while GCC
assumes the callee pops it (note: this has been fixed in gcc-4.7.0, which
is now compatible with MSVC). Another source of problems is
stack-alignment, although I don't whether it's relevant in this case (MSVC
aligns the stack on 4 bytes, GCC aligns it on 16 bytes).

I have no idea how the JIT is working, but if binary code is compiled on
the fly for functions returning a large aggregate object, maybe the wrong
ABI is being used, leading to stack corruption.

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cae.wisc.edu/pipermail/octave-maintainers/attachments/20120713/139a0f11/attachment-0001.html>

------------------------------

Message: 4
Date: Fri, 13 Jul 2012 07:27:26 -0400
From: Ben Abbott <address@hidden>
To: Max Brister <address@hidden>
Cc: Jordi Guti?rrez Hermoso <address@hidden>,
address@hidden
Subject: Re: Please build the JIT branch
Message-ID: <address@hidden>
Content-Type: text/plain; CHARSET=US-ASCII

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)

Ben

------------------------------

Message: 5
Date: Fri, 13 Jul 2012 12:37:08 +0100
From: Michael Goffioul <address@hidden>
To: Doug Stewart <address@hidden>
Cc: address@hidden, address@hidden
Subject: Re: Please build the JIT branch
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Fri, Jul 13, 2012 at 10:44 AM, Michael Goffioul <
address@hidden> wrote:

> On Fri, Jul 13, 2012 at 9:12 AM, Michael Goffioul <
> address@hidden> wrote:
>
>> I also tried the complex test:
>>
>> a = b = 1+1i;
>> for ii=1:5
>> a = a + b;
>> endfor
>>
>> unfortunately it generates a segmentation fault (works fine without JIT).
>> If the goal is to enforce calling convention, then I suggest you use the
>> appropriate modifiers instead of extern "C". If you want I can give it a
>> quick try here.
>>
>
> No luck, still crashing (I replaced all 'extern "C"' in pt-jit.cc with
> __cdecl equivalent). Debuggin shows it's crashing
> in octave_jit_cast_complex_any, when trying to access obv. It looks like
> obv is not a valid pointer, indicating a potential stack corruption.
>
> I'm not sure this is related, but did you know that even with __cdecl,
> there's an ABI difference between MSVC and GCC when returning aggregate
> objects larger than 8 bytes (typically returning a double complex object).
> The object to return is provided through a hidden pointer pushed on the
> stack, but MSVC assumes the caller pops the hidden argument, while GCC
> assumes the callee pops it (note: this has been fixed in gcc-4.7.0, which
> is now compatible with MSVC). Another source of problems is
> stack-alignment, although I don't whether it's relevant in this case (MSVC
> aligns the stack on 4 bytes, GCC aligns it on 16 bytes).
>
> I have no idea how the JIT is working, but if binary code is compiled on
> the fly for functions returning a large aggregate object, maybe the wrong
> ABI is being used, leading to stack corruption.
>
>
I did some more debugging to analyze what's going on and there's something
wrong in the assembly code that is calling octave_jit_cast_complex_any.
I've attached a screenshot of the disassembled code: function starts at
02CB00E0 and ends at 02CB010E, you can recognize the standard prologue and
epilogue of x86.

If you inspect how the stack is constructed before
calling octave_jit_cast_complex_any, you can see that:
- 24 bytes are allocated on the stack (02CB00E9, that's 3 double's, let's
call them d1, d2 and d3)
- EAX is copied at the top of the stack, at this point EAX is the
"octave_base_value* obv" argument, so it's basically the first argument of
the function; it occupies the location d1 on the stack
- after octave_jit_cast_complex_any call, results are pulled from the stack
at location d2 and d3

This does not correspond to the ABI MSVC is using. Instead of pushing a
hidden pointer on the top of the stack (as it should do), it allocates the
memory for the returned complex value on the stack and *after* the regular
function arguments. Of course, when octave_jit_cast_complex_any tries to
access obv, it points to invalid memory and crashes.

What kind of ABI is this?

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cae.wisc.edu/pipermail/octave-maintainers/attachments/20120713/f856f08e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jit_dbg1.png
Type: image/png
Size: 47858 bytes
Desc: not available
URL: <http://mailman.cae.wisc.edu/pipermail/octave-maintainers/attachments/20120713/f856f08e/attachment.png>

------------------------------

_______________________________________________
Octave-maintainers mailing list
address@hidden
https://mailman.cae.wisc.edu/listinfo/octave-maintainers

End of Octave-maintainers Digest, Vol 76, Issue 23
**************************************************

From:	Ian Franklin McLean
Subject:	Re: Octave-maintainers Digest, Vol 76, Issue 23
Date:	Fri, 13 Jul 2012 16:25:52 -0700