IPB

Welcome Guest ( Log In | Register )

WavPack 4.70.0 Released
bryant
post Oct 21 2013, 01:42
Post #1


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



Some of the changes:

See the homepage or go directly to download.
Go to the top of the page
+Quote Post
3 Pages V   1 2 3 >  
Start new topic
Replies (1 - 24)
skamp
post Oct 21 2013, 09:21
Post #2





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



Finally! cool.gif

Will test and implement the changes in caudec ASAP.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
eahm
post Oct 21 2013, 19:34
Post #3





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



Thanks for your hard work.

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


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
kode54
post Oct 21 2013, 20:01
Post #4





Group: Admin
Posts: 4608
Joined: 15-December 02
Member No.: 4082



Updated my fork of Cog to this, working perfectly.
Go to the top of the page
+Quote Post
themanintheshado...
post Oct 21 2013, 21:18
Post #5





Group: Members
Posts: 28
Joined: 31-October 12
Member No.: 104212



Congrats, dude!
Go to the top of the page
+Quote Post
larryfine
post Oct 21 2013, 22:44
Post #6





Group: Members
Posts: 57
Joined: 21-September 10
Member No.: 84040



Thank you! smile.gif


--------------------
loquor mee menti: factus de materia, cinis elementi...
Go to the top of the page
+Quote Post
shadowking
post Oct 22 2013, 02:24
Post #7





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



Thank you David


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
bryant
post Oct 22 2013, 04:48
Post #8


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



Thanks, everyone! beer.gif

QUOTE (eahm @ Oct 21 2013, 11:34) *
I can't believe they took down my joke post.

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

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

This post has been edited by bryant: Oct 22 2013, 04:48
Go to the top of the page
+Quote Post
eahm
post Oct 22 2013, 06:03
Post #9





Group: Members
Posts: 1056
Joined: 11-February 12
Member No.: 97076



QUOTE (bryant @ Oct 21 2013, 20:48) *
QUOTE (eahm @ Oct 21 2013, 11:34) *
I can't believe they took down my joke post.

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

Maybe they are too w00t.gif

Completely agree for the x64 part.

This post has been edited by eahm: Oct 22 2013, 06:05


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
kode54
post Oct 22 2013, 11:02
Post #10





Group: Admin
Posts: 4608
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
NetRanger
post Oct 22 2013, 12:56
Post #11





Group: Members
Posts: 56
Joined: 2-November 03
Member No.: 9605



Thnx for the new release smile.gif
Go to the top of the page
+Quote Post
nu774
post Oct 22 2013, 13:35
Post #12





Group: Developer
Posts: 522
Joined: 22-November 10
From: Japan
Member No.: 85902



Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.
Go to the top of the page
+Quote Post
lvqcl
post Oct 22 2013, 17:14
Post #13





Group: Developer
Posts: 3358
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
bryant
post Oct 24 2013, 03:13
Post #14


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (nu774 @ Oct 22 2013, 05:35) *
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.
Go to the top of the page
+Quote Post
bryant
post Oct 24 2013, 03:18
Post #15


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (lvqcl @ Oct 22 2013, 09: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.
Go to the top of the page
+Quote Post
lvqcl
post Oct 24 2013, 16:19
Post #16





Group: Developer
Posts: 3358
Joined: 2-December 07
Member No.: 49183



QUOTE (bryant @ Oct 24 2013, 06:18) *
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).
Go to the top of the page
+Quote Post
bryant
post Oct 24 2013, 18:06
Post #17


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (lvqcl @ Oct 24 2013, 08:19) *
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.
Go to the top of the page
+Quote Post
lvqcl
post Oct 24 2013, 18:39
Post #18





Group: Developer
Posts: 3358
Joined: 2-December 07
Member No.: 49183



QUOTE (bryant @ Oct 24 2013, 21:06) *
Interesting. How do those compare to the official 64-bit version?

Official 64-bit exe: 43 sec. to encode

QUOTE (bryant @ Oct 24 2013, 21:06) *
If they're faster, I might like to get a copy of the binaries from you to compare myself.

Attached File  exe.zip ( 531.7K ) Number of downloads: 225
(original folder: original code compiled with VS 2010; modified folder: code with alternative definition of apply_weight, also compiled with VS2010).

This post has been edited by lvqcl: Oct 25 2013, 17:20
Go to the top of the page
+Quote Post
skamp
post Oct 25 2013, 13:50
Post #19





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



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.
Go to the top of the page
+Quote Post
bryant
post Oct 25 2013, 20:56
Post #20


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (lvqcl @ Oct 24 2013, 10:39) *
(original folder: original code compiled with VS 2010; modified folder: code with alternative definition of apply_weight, also compiled with VS2010).

Thanks for these! smile.gif

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.
Go to the top of the page
+Quote Post
bryant
post Oct 25 2013, 21:00
Post #21


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (skamp @ Oct 25 2013, 05:50) *
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.
Go to the top of the page
+Quote Post
skamp
post Oct 26 2013, 09:21
Post #22





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (bryant @ Oct 25 2013, 22:00) *
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.

This post has been edited by skamp: Oct 26 2013, 09:40


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
lvqcl
post Oct 26 2013, 09:45
Post #23





Group: Developer
Posts: 3358
Joined: 2-December 07
Member No.: 49183



QUOTE (bryant @ Oct 25 2013, 23:56) *
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? huh.gif
Go to the top of the page
+Quote Post
lamedude
post Oct 27 2013, 13:45
Post #24





Group: Members
Posts: 14
Joined: 2-January 12
Member No.: 96171



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.
Go to the top of the page
+Quote Post
bb10
post Oct 27 2013, 19:23
Post #25





Group: Members
Posts: 169
Joined: 8-November 06
Member No.: 37341



CPU: Core i7 2630QM
Norah Jones - 12. Nightingale [4:12] (24-bit 6ch WAV) -h -x2 option:

CODE
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
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     |
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd August 2014 - 10:41