The fact that my optimizations improve the speed on your CPU in some circumstances by over 50% will have to be enough for me right now. The bar that I set for myself before was that I didn't want situations where the new code was worse than before, and we've still met that goal.
I usually just run the programs directly in the cli directory (and never install except for a final release). The build will create a tiny script there for each command-line program that runs the executable linked to the correct libwavpack. The cleanest way is to add --disable-shared on the configure line and then when you build it will create stand-alone binaries in the cli directory that have libwavpack built in (so there's no doubt about what's what). I would not install after building like that though.
but I'm running the cli\.libs\wavpack.exe, because the cli\wavpack.exe is only 36kb small and doesn't seem to do anything.
Quote from: ChronoSphere on 08 May, 2015, 02:55:01 PMbut I'm running the cli\.libs\wavpack.exe, because the cli\wavpack.exe is only 36kb small and doesn't seem to do anything.That one is, at least on my setup, using the old libs, which would indeed explain why you were seeing 4.70 as the version number.You can use ldd <executable name> to check which libraries are being used.
fakeroot-i386-linux-gnu.conf i386-linux-gnu.conf libc.conf
--enable-rpath use rpath to allow installing libraries in paths use rpath when linking programs [USE WITH CARE]
My first idea to fix this was to bump the libtool versioning so that (I thought) my command-line programs would require the newer library (even though there was really no missing dependency in the old library). I was surprised when this did not work. I even added a new function to the library and now I get a runtime error when I try to run the programs, because it still won't use the new library. So either that feature, or my understanding of it, is broken.
readelf -d /usr/local/lib/libwavpack.so | grep SONAMEreadelf -d `which wavpack` | grep NEEDED
So, they are loaded in this filename order. /usr/local/lib is written in libc.conf, so it is loaded after i386-linux-gnu.conf. If x86_64-linux-gnu.conf is present, it will be loaded at the end. Hence the strange, seemingly inconsistent library search order. I can change library search order simply by renaming them (I confirmed it).
As for rpath thing, I don't think setting rpath in build process is common. However, I found this option in configure script of ffmpeg:Maybe you could offer similar option and let user decide. However, I don't think users blame you without it.
/usr and /usr/local are different prefixes.Are you sure you are running the right executable?
What's relevant here is the soname.Code: [Select]readelf -d /usr/local/lib/libwavpack.so | grep SONAMEreadelf -d `which wavpack` | grep NEEDEDIf you did actually bump the soname version to 2. And you are running the right binary. Then both greps should include libwavpack.so.2.
If two libraries have identical current and age numbers, then the dynamic linker chooses the library with the greater revision number.
To set the version of the library, libtool provides the -version-info parameter, which accepts three numbers, separated by colons, that are called respectively, current, revision and age. Both their name and their behaviour, nowadays, have to be considered fully arbitrary, as the explanation provided in the official documentation is confusing to say the least, and can be, in some cases, considered completely wrong.
Great to see a new Wavpack release. For the foreseeable future, I picture myself using it more and more, as Android devices abound.
X | run 1 | run 2 |icc-mmx 4.70.0 64 | 29.46s | 29.32s |4.75.0-rc 64 | 34.29s | 34.09s |gcc 4.75.0-rc 64 | 31.01s | 30.75s |
X | run 1 | run 2 |icc-mmx 4.70.0 64 | 30.35s | 30.34s |4.75.0-rc 64 | 34.04s | 33.94s |gcc 4.75.0-rc 64 | 30.82s | 30.88s |
I'm curious to see how much faster a 64bit ICC compile of 4.75.0 would be.
// Version 2.12 - May 10, 2015 (library ver 4.75.1)
Quote from: bb10 on 19 May, 2015, 04:16:48 PMI'm curious to see how much faster a 64bit ICC compile of 4.75.0 would be.How about GCC compile from post #8?
CPU: Core i7 2630QMNorah Jones - 12. Nightingale [4:12] (24-bit 6ch WAV) -h -x2 option: Code: [Select]X | run 1 | run 2 |icc-mmx 4.70.0 64 | 29.46s | 29.32s |4.75.0-rc 64 | 34.29s | 34.09s |gcc 4.75.0-rc 64 | 31.01s | 30.75s |
version encode decode------------------------------4.70.0 21.53s 7.63s4.70.0 x64 25.46s 7.30s------------------------------4.75.0 19.19s 5.27s4.75.0 x64 18.39s 5.12s
A big thank you to everyone for all your testing, help, advice and support. It is greatly appreciated!!The new released version is currently up on wavpack.com and available for download here.--David
Quote from: bb10 on 19 May, 2015, 04:16:48 PMCPU: Core i7 2630QMNorah Jones - 12. Nightingale [4:12] (24-bit 6ch WAV) -h -x2 option: Code: [Select]X | run 1 | run 2 |icc-mmx 4.70.0 64 | 29.46s | 29.32s |4.75.0-rc 64 | 34.29s | 34.09s |gcc 4.75.0-rc 64 | 31.01s | 30.75s |I have to admit that I can't really explain your results.