32bit ICC & 64bit ICC w/MMX and alt def of apply_weight.32&64bit w/o MMX was slower on 16bit but faster on 24bit. The apply weight mod is <1% slower on my i5-3330.
Well, running "wavpack --help" should exit with code 0 (because that's a valid action), but running "wavpack" on its own, without any parameters, should exit with a non zero code, even if that displays a short help screen, because it's actually a "usage error". The exit code for that, btw, is 64, as far as I can tell (from /usr/include/sysexits.h).
official 32-bit:16-bit: 78,35212648x24-bit: 77,01991355xofficial 64-bit:16-bit: 78,62632693x24-bit: 63,22435532xlvqcl original 32-bit:16-bit: 78,14190364x24-bit: 86,93761979xlvqcl original 64-bit:16-bit: 79,32029858x24-bit: 63,45351647xlvqcl modified 32-bit:16-bit: 78,17297656x24-bit: 86,952771xlvqcl modified 64-bit:16-bit: 78,65516379x24-bit: 76,97832292xintel 32-bit:16-bit: 69,03704896x24-bit: 89,67199856xintel 64-bit:16-bit: 98,29642284x24-bit: 90,80626081xgcc 4.82 32-bit:16-bit: 77,13143698x24-bit: 72,1682216xgcc 4.82 64-bit:16-bit: 79,48867848x24-bit: 72,89575572x
The other thing is that bb10's tests show a huge improvement for 64-bit executables! It's almost too good to be true...did you try the new -v option for make sure you were really getting valid output? BTW, thanks for running those tests.David
GCC 4.82 compilesgcc 4.82 32-bitgcc 4.82 64-bit
I think I'm starting to understand why Xiph lets other people provide their binaries...
I don't think it's unreasonable to provide a "reference" set of binaries and let sites like RareWares handle specialized compiles like ICL. This approach seems to work well enough for FLAC, but it doesn't look like RW has provided Wavpack binaries since 4.32.
Is there any reason we all should use ICL compiles? Or, are there other reasons to use different compiles other than compatibility and speed?
I think it would be nice if they were built with the official, unmodified sources.
Quote from: bryant on 30 October, 2013, 07:17:12 PMI think it would be nice if they were built with the official, unmodified sources.To tell the truth, qaac has been using modified wavpack header (not implementation) due to conflicting typedefs against standard stdint.h provided by MSVC >= 10 .They introduced stdint.h at MSVC10 (but no inttypes.h), and now introduced inttypes.h at MSVC12. I sent pullreq on github repos.
Many minor bug fixes (especially on non-Windows platforms)
BTW: I notice that the "doc" directory and foremost it's content are gone from the *nix tarball..... Just my two cents; it could have stayed, some distros install that documentation too....
Hi bryant.Maybe you know about this already.In wavpack.pc change 'exec_prefix' to 'prefix' then it's OK (with Linux).I didn't work this out myself, Doctor Google found it here ---> linky
Now I've compiled the git version, it is different.It has failed to build for me "No rule to make target `wavpack.1', needed by `all-am'"But no sweat, the modified wavpack-4.70 from the wavpack.com website provides the library I needed.
it has been fixed in Git (although not exactly like you have here).