Optimisation flags in the jackd Debian package

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Optimisation flags in the jackd Debian package

Free Ekanayaka-4
Hi,

I'm one of the maintainer of the jack Debian package. I would like to
ask the developers' opinion about the default build flags/compilation
options to use.

At the moment the package is built with the followings options:

DEB_CONFIGURE_EXTRA_FLAGS := --enable-resize \
        --enable-timestamps --disable-iec61883 --with-oldtrans \
        --disable-ensure-mlock --enable-sse=yes --enable-static=yes

Plus

 --enable-dynsimd=yes

if the architecture is amd64 (it has been disabled on i386 because
apparently not every CPU supports it).

Further more the CFLAGS variable gets:

CFLAGS += -m3dnow -msse

both on amd64 and i386. The full build script is available here:

http://svn.debian.org/wsvn/demudi/jack-audio-connection-kit/trunk/debian/rules?op=file&rev=0&sc=0

However it seems that the use of --enable-sse=yes and -m3dnow -msse
leads to problems on some i386 CPUs, see:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422076;repeatmerged=no

How much impact has the use SSE and m3dnow in terms of performances?
Would it be acceptable to drop them in the Debian package in order to
get a wider support of CPUs?

If their use is highly recommended, we could think about providing to
different binary packages, say jackd and jackd-noopt, one built with
these optimisations and the other not. In that case should be also the
library built in two flavours?

Thanks,

Free

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation flags in the jackd Debian package

Pieter Palmers
Free Ekanayaka wrote:

> Hi,
>
> I'm one of the maintainer of the jack Debian package. I would like to
> ask the developers' opinion about the default build flags/compilation
> options to use.
>
> At the moment the package is built with the followings options:
>
> DEB_CONFIGURE_EXTRA_FLAGS := --enable-resize \
>         --enable-timestamps --disable-iec61883 --with-oldtrans \
>         --disable-ensure-mlock --enable-sse=yes --enable-static=yes
>
> Plus
>
>  --enable-dynsimd=yes
>
> if the architecture is amd64 (it has been disabled on i386 because
> apparently not every CPU supports it).
>
> Further more the CFLAGS variable gets:
>
> CFLAGS += -m3dnow -msse
>
> both on amd64 and i386. The full build script is available here:
>
> http://svn.debian.org/wsvn/demudi/jack-audio-connection-kit/trunk/debian/rules?op=file&rev=0&sc=0
>
> However it seems that the use of --enable-sse=yes and -m3dnow -msse
> leads to problems on some i386 CPUs, see:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422076;repeatmerged=no
>
> How much impact has the use SSE and m3dnow in terms of performances?
> Would it be acceptable to drop them in the Debian package in order to
> get a wider support of CPUs?
>
> If their use is highly recommended, we could think about providing to
> different binary packages, say jackd and jackd-noopt, one built with
> these optimisations and the other not. In that case should be also the
> library built in two flavours?

For libfreebob the optimization flags make a huge difference due to the
float <-> int conversions. When specifying -march=pentium (or more
recent), the compiler uses specific instructions for these conversions,
and they are a LOT faster.

I would expect that this is the same for e.g. the ALSA backend. Unless
special type conversion code is used.

Pieter

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation flags in the jackd Debian package

Jussi Laako-2
In reply to this post by Free Ekanayaka-4
Free Ekanayaka wrote:
>  --enable-dynsimd=yes
>
> if the architecture is amd64 (it has been disabled on i386 because
> apparently not every CPU supports it).

The whole point of this functionality is that CPUID instruction is used
to determine what capabilities the CPU has, at runtime, and to select
the used algorithm accordingly. So it should work on anything which
supports CPUID instruction (486 upwards?).

> CFLAGS += -m3dnow -msse

This isn't needed on lowend arch and if dynsimd is disabled.

When building with dynsimd, something like "-march=i686 -m3dnow -msse
-O3 -ffast-math -fomit-frame-pointer" could be used.

If you like to optimize it to the max, something like "-march=pentium4
-mtune=prescott -m3dnow -O3 -mfpmath=sse -ffast-math
-fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays" would do
when arch is pentium4(or core)/athlon64 or better.

> However it seems that the use of --enable-sse=yes and -m3dnow -msse
> leads to problems on some i386 CPUs, see:

Obviously?

> How much impact has the use SSE and m3dnow in terms of performances?
> Would it be acceptable to drop them in the Debian package in order to
> get a wider support of CPUs?

"dynsimd" is designed to give near-optimal performance on most
hardwares. Only requirement is that the CPU supports CPUID instruction.
I doubt if jack would make much sense on such ancient hardware which
wouldn't support CPUID (ie. pre-486).

> different binary packages, say jackd and jackd-noopt, one built with
> these optimisations and the other not. In that case should be also the

You should make a difference here between _runtime_ optimizations and
_compile_ time optimizations. Having the first one could probably make
sense to have in generic package (that's why it's there in first place),
second probably doesn't in order to be compatible with older hardware.


BR,

        - Jussi


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel