Re: [Vxl-maintainers] vnl thread safety - vx winxp optimsation problems

[David C. <dav...@ma...>]

Hi Brad,

I'm not sure how long "v3p_netlib" took to compile before. In the past 
I've just compiled it alongside the rest of VXL and not paid much 
attention. Maybe optimising the code just takes time.

However, I think your fix for "slamch.c and "dlamch.c" has worked! :-)

I've added the pragma option for these two files and then recompiled 
"v3p_netlib". This has removed the 5 minute delay in starting release 
applications using v3p_netlib. Do you want me to commit this fix for 
these two files now?

The only other thing to note is that "zlarfx.c" takes about 10mins to 
compile with optimisation switched on and 2 seconds without optimisation 
(3Ghz WinXP machine). Do you think the pragma switch should be added to 
this file also?! Or is the optimisation worth the wait at compile time?

Thanks for the quick and helpful response,

David

Brad King wrote:
> David Cristinacce wrote:
>> 1. Some of the "v3p_netlib" c files take ages to compile (ie compared to 
>> the debug time). Specifically the following files:-
>>
>> zlarfx.c
>> zgemm.c
>> dhgeqz.c
>> ztrmm.c
>> hqr2.c
> 
> This is probably because the optimizer is spending alot of time on these
> files.  Many of these functions have been in vxl for a long time in the
> old netlib library.  They've just been re-converted from fortran and
> moved into the new library.  Did this happen before?
> 
>> 2. When running any release applications which access the v3p_netlib 
>> library (statically compiled), for example "netlib_slamch_test". The dos 
>> terminal window appears, but only about 5 mins later is any output 
>> produced in the terminal window.
>>
>> The debug version of "netlib_slamch_test" has no problems, it starts 
>> producing output immediately.
>>
>> My current work around is to build the entire release version of 
>> "v3p_netlib" using the "Disabled (/Od)" optimisation option (set 
>> manually in VS). This speeds up the compilation of the "v3p_netlib" 
>> libarary and allows release binaries to be built without the 5 minute 
>> start delay, but presumably the resulting code is slower.
> 
> The slamch.c and dlamch.c files have had optimization disabled for GCC
> because they seemed to be getting into infinite loops.  I bet the loops
> were not actually infinite but just very long, and the VS optimizer is
> making the same mistake.
> 
> Try adding this at the top of those files for your build:
> 
> #ifdef _MSC_VER
> # pragma optimize ("",off)
> #endif
> 
> If that solves the problem then we can commit the fix.  However in that
> case two compilers will have made the same optimization mistake so it
> would be interesting to try to figure out why.
> 
> Thanks,
> -Brad
> 
> 

-- 
Dr David Cristinacce
Research Associate
Imaging Science and Biomedical Engineering,
University of Manchester,
M13 9PT, UK.
dav...@ma...
http://mimban.smb.man.ac.uk/
tel: +44 161 275 6871
fax: +44 161 275 5145