Skip to main content

Topic: WavPack 4.70.0 Released (Read 40652 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Some of the changes:

See the homepage or go directly to download.

  • skamp
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #1
Finally! 

Will test and implement the changes in caudec ASAP.
See my profile for measurements, tools and recommendations.

  • eahm
  • [*][*][*][*][*]
WavPack 4.70.0 Released
Reply #2
Thanks for your hard work.

I can't believe they took down my joke post.

  • kode54
  • [*][*][*][*][*]
  • Administrator
WavPack 4.70.0 Released
Reply #3
Updated my fork of Cog to this, working perfectly.

WavPack 4.70.0 Released
Reply #4
Congrats, dude!
ghostman

  • larryfine
  • [*][*]
WavPack 4.70.0 Released
Reply #5
Thank you!
loquor mee menti: factus de materia, cinis elementi...

  • shadowking
  • [*][*][*][*][*]
WavPack 4.70.0 Released
Reply #6
Thank you David
wavpack -b4hhj0s0.7cc

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #7
Thanks, everyone! 

I can't believe they took down my joke post.

Haha, it's okay, I saw it... 

Speaking of binaries, I have uploaded the VS 2008 x64 binaries here in case people want to use them. As was discussed in the release candidate thread, they're faster in some cases but up to 10% slower with the "extra" modes, so I'm not sure it makes much sense and I don't want to confuse general users with them on my downloads page.

David
  • Last Edit: 21 October, 2013, 11:48:58 PM by bryant

  • eahm
  • [*][*][*][*][*]
WavPack 4.70.0 Released
Reply #8
I can't believe they took down my joke post.

Haha, it's okay, I saw it... 

Maybe they are too

Completely agree for the x64 part.
  • Last Edit: 22 October, 2013, 01:05:57 AM by eahm

  • kode54
  • [*][*][*][*][*]
  • Administrator
WavPack 4.70.0 Released
Reply #9
Although you probably missed the part from the 4.70.0 release candidate topic where bryant said that the x86_64 version is not much faster than, or sometimes even slightly slower than the x86 version.

  • NetRanger
  • [*][*]
WavPack 4.70.0 Released
Reply #10
Thnx for the new release

  • nu774
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #11
Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #12
On my Core2 9300, 64-bit encoder is noticeably slower than 32-bit one for 24-bit WAV files. As far as I can see MSVS forbids MMX intrinsics for 64-bit code, and, from a comment in pack.c:

Quote
The MMX version is significantly faster when the sample data requires the full-resolution apply_weight macro.


When I reversed the definition of apply_weight (so it simply uses 64-bit arithmetics) 64-bit encoder became noticeably faster than now, 32-bit encoder with MMX disabled - slightly faster, 32-bit with MMX enabled - no difference.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #13
Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.

Good point. I have added the x64 versions of the DLL and the LIB to that file.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #14
On my Core2 9300, 64-bit encoder is noticeably slower than 32-bit one for 24-bit WAV files. As far as I can see MSVS forbids MMX intrinsics for 64-bit code, and, from a comment in pack.c:

Quote
The MMX version is significantly faster when the sample data requires the full-resolution apply_weight macro.


When I reversed the definition of apply_weight (so it simply uses 64-bit arithmetics) 64-bit encoder became noticeably faster than now, 32-bit encoder with MMX disabled - slightly faster, 32-bit with MMX enabled - no difference.

That's weird. On my system they're both somewhat slower using the 64-bit math. Are you compiling with VS 2008? I noticed that VS 2010 has an all new compiler, although I haven't read anywhere that it generates significantly different code.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #15
That's weird. On my system they're both somewhat slower using the 64-bit math. Are you compiling with VS 2008? I noticed that VS 2010 has an all new compiler, although I haven't read anywhere that it generates significantly different code.


MSVS 2010 and 2012. I compiled the sources, then changed "#if 1" to "#if 0" in the definition of apply_weight and compiled again. Encoding time was reduced from 43 sec to 35 sec (64-bit exe, 24-bit stereo WAV, -hh option).

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #16
MSVS 2010 and 2012. I compiled the sources, then changed "#if 1" to "#if 0" in the definition of apply_weight and compiled again. Encoding time was reduced from 43 sec to 35 sec (64-bit exe, 24-bit stereo WAV, -hh option).

Interesting. How do those compare to the official 64-bit version? If they're faster, I might like to get a copy of the binaries from you to compare myself. Might be worth upgrading to the new compiler sooner rather than later.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #17
Interesting. How do those compare to the official 64-bit version?

Official 64-bit exe: 43 sec. to encode

If they're faster, I might like to get a copy of the binaries from you to compare myself.

[ Attachment Invalid Or Does Not Exist ] (original folder: original code compiled with VS 2010; modified folder: code with alternative definition of apply_weight, also compiled with VS2010).
  • Last Edit: 25 October, 2013, 12:20:48 PM by lvqcl

  • skamp
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #18
Tiny gripe, I'm sorry I didn't catch it before: "wavpack --version" shouldn't exit with code 1 (or any code other than 0, i.e. "success"). No biggie.
See my profile for measurements, tools and recommendations.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #19
(original folder: original code compiled with VS 2010; modified folder: code with alternative definition of apply_weight, also compiled with VS2010).

Thanks for these! 

Well, I see the same thing with these as with mine: the modified 64-bit version is about 4-5% slower than the unmodified, with both -hh and -x4. Very weird, because it seems our CPUs don't seem that different. And for 64-bit, the compiler doesn't make any appreciable difference.

However, for the 32-bit version (which uses MMX) the new compiler makes about a 10% improvement for 24-bit data, and I notice that now 16-bit data is actually handled slower than 24-bit, which might mean I should reëxamine the decision to not use MMX for 16-bit data.

This all reminds me why I generally stopped beating my head against the wall for a few percentage points speed improvement and try to just concentrate on features...but there's obviously room for upgrading my compiler (I actually already did this with the 7.1 SDK, but haven't switched to it) and playing around with the available options. Thanks again for bringing this up.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #20
Tiny gripe, I'm sorry I didn't catch it before: "wavpack --version" shouldn't exit with code 1 (or any code other than 0, i.e. "success"). No biggie.

Well, apart from you not catching it, that's totally my fault, and completely unintentional. I copy/pasted without thinking.

I'll fix it right away, and I also see that requesting the "help" display does the same thing. Thanks for letting me know.

  • skamp
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #21
I also see that requesting the "help" display does the same thing


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).

Edit: and it would also make sense to output to STDOUT upon "sucess" (e.g. "wavpack --help"), and STDERR upon usage error (e.g. "wavpack" without any parameters). If anything, it would discourage people from trying to parse the output of an erroneous command (by redirecting STDERR to STDOUT), which is there merely for convenience and could change in the future. The distinction should be made that the valid command for printing the help screen is "wavpack --help", and no other.
  • Last Edit: 26 October, 2013, 04:40:19 AM by skamp
See my profile for measurements, tools and recommendations.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
WavPack 4.70.0 Released
Reply #22
Well, I see the same thing with these as with mine: the modified 64-bit version is about 4-5% slower than the unmodified, with both -hh and -x4. Very weird, because it seems our CPUs don't seem that different. And for 64-bit, the compiler doesn't make any appreciable difference.


This .zip file was downloaded 14 times. Maybe anybody else wants to test and post the results? 

  • lamedude
  • [*]
WavPack 4.70.0 Released
Reply #23
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.

  • bb10
  • [*][*][*]
WavPack 4.70.0 Released
Reply #24
CPU: Core i7 2630QM
Norah Jones - 12. Nightingale [4:12] (24-bit 6ch WAV) -h -x2 option:

Code: [Select]
X           |     run 1     |     run 2      |
official 32 |     38.23s    |     38.37s     |
official 64 |     40.37s    |     40.34s     |

original 32 |     35.21s    |     35.27s     |
original 64 |     40.39s    |     40.28s     |

modified 32 |     36.59s    |     36.34s     |
modified 64 |     37.94s    |     37.88s     |

icc-mmx  32 |     37.76s    |     37.77s     |
icc-mmx  64 |     28.50s    |     28.43s     |



Norah Jones - 12. Nightingale [4:12] (16-bit 6ch WAV) -h -x2 option:

Code: [Select]
X           |     run 1     |     run 2      |
official 32 |     37.27s    |     37.34s     |
official 64 |     36.61s    |     36.81s     |

original 32 |     36.88s    |     36.77s     |
original 64 |     36.55s    |     36.53s     |

modified 32 |     38.54s    |     38.62s     |
modified 64 |     36.31s    |     36.43s     |

icc-mmx  32 |     42.49s    |     42.60s     |
icc-mmx  64 |     29.37s    |     29.56s     |