Optimized vorbis encoder for Linux (SSE instructions), I have built the binary - any interest ? Options

[The_Sven]

A quick look around the forum seemed to indicate that no-one has ever attempted to build Vorbis with Lancer optimisations for Linux ?!

So I spent a few hours fiddling and produced an executable:
- Linux
- aoTuV-beta5
- Lancer optimisations for SSE
- 32 bit (x86)
- statically linked
- around 3x faster compared to the standard aoTuV-beta5 build

I did not attempt to port Lancer's SSE2/SSE3 instructions to Linux because the difference between SSE/SSE2/SSE3 is minimal on the PCs I use.
(Intel Celeron M and AMD Turion 64x2)

Any interest? If so, I will post the binary.

[Mr_Rabid_Teddybe...]

I compiled your snapshot vorbis-lancer-gcc-master.tar.gz locally by running ./build-script. The result here are not a static build and seems to have compiled my systems libogg in dynamically:

CODE

~/src/lancer/vorbis-lancer-gcc$ file oggenc
oggenc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
~/src/lancer/vorbis-lancer-gcc$ ldd oggenc
    linux-gate.so.1 =>  (0xb7fae000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0xb7f63000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f3d000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ddf000)
    /lib/ld-linux.so.2 (0xb7f94000)
~/src/lancer/vorbis-lancer-gcc$

[The_Sven]

I compiled your snapshot vorbis-lancer-gcc-master.tar.gz locally by running ./build-script. The result here are not a static build and seems to have compiled my systems libogg in dynamically:

You're absolutely right: my build script doesn't generate a completely static binary. To do that, I would have to modify the autoconf build script and I don't know how, being a Windows person. I've posted a question about it on LinuxQuestions:
http://www.linuxquestions.org/questions/li...utoconf-769088/

If you want to get a statically linked binary, do the following from the ogg-aoTuVb5-lancer directory (i.e. the root):
1. $ ./build-script (if you haven't done this already)
2. $ cd vorbis-tools-1.2.0/oggenc/
3. $ make clean; make
4. Copy the last gcc line on your console, paste it on your command line and add the -static switch. Execute it.
5. $ cd ..
6. $ make install
7. The binary is now in ogg-aoTuVb5-lancer/out/bin

Any help with fixing this is very welcome!!

This post has been edited by The_Sven: Nov 15 2009, 14:44

[Mr_Rabid_Teddybe...]

If you want to get a statically linked binary, do the following from the ogg-aoTuVb5-lancer directory (i.e. the root):
1. $ ./build-script (if you haven't done this already)
2. $ cd vorbis-tools-1.2.0/oggenc/
3. $ make clean; make
4. Copy the last gcc line on your console, paste it on your command line and add the -static switch. Execute it.
5. $ cd ..
6. $ make install
7. The binary is now in ogg-aoTuVb5-lancer/out/bin

That last gcc line also had a pointer to /usr/lib/libogg.so instead of to ${WORKDIR}/out/lib/libbogg.a which made it fail with:

CODE

/usr/bin/ld: attempted static link of dynamic object `/usr/lib/libogg.so'
collect2: ld returned 1 exit status

Correcting that bit I succeeded in making the build static.
Neither I know enough to fix this...

EDIT:
My build fails anyway, somethings wrong with it, trying to encode a file:

$ ./oggenc -q5 Luckie.wav -o Luckie.ogg
Open with wav-module: WAV file reader
Encoding "Luckie.wav" to
"Luckie.ogg"
at quality 5,00
Mode initialisation failed: invalid parameters for quality

Well, well...



This post has been edited by Mr_Rabid_Teddybear: Nov 15 2009, 16:16

[The_Sven]

Well, well...

Does your build machine have libogg, liborbis and libflac installed? Mine doesn't. I suspect that vorbis-tools's makefile prefers installed libraries, and simply ignores the --with-ogg, --with-vorbis switches. I already had to do a work-around for the --with-flac switch, which didn't work.

As an aside: I'm a Windows person, and know very little of the Linux dev world. It's completely baffling to me why *anyone* would use a tool like autoconf/automake. For starters, I haven't yet found a single software developer who understands these tools. Is this really the state-of-the-art in Linux? With Visual Studio, build maintenance consists of a mouse click here and there. Time saved there is time gained for important things, such as code development/debugging/test etc.

The --with-flac switch bug was discussed by its developers on a Xiph.org forum as early as 2007(!!). Are we the only ones struggling with the build system? I doubt it...

[[JAZ]]

autoconf/automake works in linux x86, linux ARM, UNIX x86, UNIX Sparc, .... list goes on.
Not only that, but autoconf is old and tested.

Visual studio needs visual studio, and everything that visual studio provides (runtimes, etc..).

The truth is that nowadays, autoconf is still used (because it exists everywhere), but more and more projects use other tools, like scons or other python based ones.


Now, about your comment of not being able to update b5 to b5.7... Is that because you think you cannot do as good as lancer is, or because you don't know about intrinsics?
I haven't looked at the code, but did some work on intrinsics a few years ago (for a windows/linux project, dsp related, but mostly mixing)