Re: Bug#770009: convert(1) very slow on mips with no FPU

On Sat, Aug 15, 2015 at 3:08 PM, Simon McVittie <[email protected]> wrote:
> (debian-mips: please keep me and the bug in Cc if replying.)
>
> On Wed, 28 Jan 2015 at 08:00:53 +0100, roucaries bastien wrote:
>> Smell like an openmp bug.... ny memory they are a enviroment variable to
>> disable openmp.
>
> I tried building with --disable-openmp on a mips porterbox
> (minkus.debian.org, which I believe is a dual Cavium Octeon II with no FPU,
> the same as the buildds where imagemagick has been failing).
>
> Unfortunately building with --disable-openmp doesn't seem to help.
>
> On Thu, 29 Jan 2015 at 19:59:45 +0100, Bastien ROUCARIES wrote:
>> try to add to convert command line "-limit thread 1"
>
> Sadly that doesn't seem to help either.
>
>> On Fri, Jan 30, 2015 at 2:37 PM, Dejan Latinovic
>> <[email protected]> wrote:
>> > did anyone tried to wait some longer time to see if command will execute?
>>
>>   No, but the build machines wait for a pretty long time before
>> killing (5 hours), and I've checked that it uses the proc at 200%. We
>> can't burden the build machines like that...
>
> The latest experimental build (which adds some "echo", to stop sbuild
> killing the build process after 5 hours of apparent inactivity) took
> 19 hours. That's longer than gcc-5 took on the same hardware.
>
> While doing test builds yesterday evening, I was able to compile
> imagemagick more than once, so it can't have taken longer than 2 or 3 hours;
> assuming the porterbox and the buildd have a similar spec, that means
> converting a SVG to a PNG 14 times is taking at least 16 hours.
> That seems unusably slow to me. It's entirely possible that imagemagick
> built for mips is currently only really useful on mips hardware that has
> a FPU. Unfortunately, the mips buildds don't seem to have FPUs.
>
> mips porters: how common are FPUs expected to be among mips machines
> where Debian will run? Also, is it an ABI break for a mips library to
> be built with -msoft-float? If mips FPUs are rare, and -msoft-float
> produces a compatible ABI, then perhaps we should be compiling imagemagick
> with -msoft-float, so it will use libgcc for somewhat slow floating
> point emulation (like armel does), rather than very slow kernel traps
> (like the old arm port)?

I could add moreover a special lib for mips if you support subarch
path like /lib/i686/cmov under i686 (partial arch will really help
here but I could special case mips).


> If -msoft-float is not viable, either because FPUs are common or because
> it produces a different ABI, then it seems to me as though we need
> some sort of compromise to make imagemagick builds complete in a finite time.
> Bastien doesn't want to remove the smoke-test of the built binaries,
> which I can understand; but at the same time, building imagemagick
> shouldn't take 19 hours.
>
> Bastien: perhaps the conversion of SVG to 14 PNG icons could move to the
> arch-indep part of the build, and the smoke-test could be something
> simpler, like a single image-resize operation? Even if that takes an
> hour (leading to maybe a 3-4 hour total build time), that's way better
> than spending 16 hours on a smoke-test.

Yes but I do not want to do that before next version. My priority is
the new c++ library.

Bastien

>>   I could try building with another version of gcc, though.
>
> Unfortunately, this has ceased to be an option, because g++-4.x and g++-5
> produce a different ABI for libmagick++.
>
>     S