Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC 1.3.0 has been released (Read 190436 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC 1.3.0 has been released

Reply #100 –
Quote from: Brand on
Quote from: GrieverV on
FLAC git 3194829 win32 and x64 compiles:
win32, x64

Built using MSVC 2013 Update 3 RC using the Windows XP toolset (v120_xp)

I decided to use the latest FLAC git instead of 1.3.0 due to various Windows/MSVC support improvements.
You can browse FLAC's git repository and view all the changes since 1.3.0 here: https://git.xiph.org/?p=flac.git;a=summary

I get a nice encoding speed improvement with an i5 CPU, but with an older AMD X2 4000+ it performs the same as the old 1.3.0 from last year. Is this normal?
(Always using x64 on Win7.)


I'm not familiar with FLAC's codebase, but AFAICT the big gains are due to adding SSE optimizations, particularly SSE4.
You should still see a small difference between 1.3.0 and 3194829 since SSE3 support was added and I believe there were a few minor improvements.

SSE3 is a very minor improvement over SSE2 while SSE4 is a significant improvement over SSE3.

FLAC 1.3.0 has been released

Reply #101 –
Quote from: GrieverV on
I'm not familiar with FLAC's codebase, but AFAICT the big gains are due to adding SSE optimizations, particularly SSE4.

I've seen speed improvements of >60% with an SSE2 compile (Only GCC 4.9 supports SSE 4 function multiversioning due to the introduction of some handy features for that), so I'd say these improvements are not only SSE4 related. Source: from the horse's mouth. As the mentioned AMD X2 4000+ has support for SSE3, I wonder what is causing this as well.

Still, for example a FLAC compile on the Raspberry Pi has no speed increase (might even be a very small decrease, but that's within measurement error), so all of the speedup is due to Intel x86/AMD64 related instruction sets being used more efficiently.
Music: sounds arranged such that they construct feelings.

FLAC 1.3.0 has been released

Reply #102 –
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).

According to http://en.wikipedia.org/wiki/SSE2#Differen...en_MMX_and_SSE2 :
Quote
Although one SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: [...] and the throughput of SSE2 instructions in older x86 implementations was half that for MMX instructions. Intel addressed [...] the last problem by widening the execution engine in their Core microarchitecture in Core 2 Duo and later products.
(emphasis mine).

SSE throughput was doubled in Intel Core 2 (released in 2006) and AMD K10 (released in 2007). Older processors won't benefit much from the new SSE code.

FLAC 1.3.0 has been released

Reply #103 –
Quote from: lvqcl on
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).

Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

FLAC 1.3.0 has been released

Reply #104 –
Quote from: Maurits on
Quote from: lvqcl on
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).

Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?

SSE2 allows you to run MMX operations on the large, 128-bit registers introduced along with SSE. (This explains only why you don't need MMX anymore when exclusively targeting platforms which support SSE2. Not sure about the SSE4.1 part.)

FLAC 1.3.0 has been released

Reply #105 –
Hello,

After some troubles, win64 binaries of latest flac.git

Code: [Select]
-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-

  Configuration summary :

    FLAC version : ........................ 1.3.0

    Host CPU : ............................ i686
    Host Vendor : ......................... pc
    Host OS : ............................. mingw64

    Compiler is GCC : ..................... yes
    GCC version : ......................... 4.9.1
    Compiler is Clang : ................... no
    SSE optimizations : ................... yes
    Asm optimizations : ................... yes
    Ogg/FLAC support : .................... no


Quick test:
Code: [Select]
Command:        flac.exe -8

CPU:            Intel i5-2520M@2.5GHz
CD Image:       44.1/16/Stereo, 58:44

john33        1.3.0        32bit: ~58.21s
john33        1.3.0        64bit: ~55.44s
GrieverV    git 3194829    32bit: ~43.41s
GrieverV    git 3194829    64bit: ~37.13s
AiZ         git 7251201    32bit: ~37.98s
AiZ         git 7251201    64bit: ~34.47s

    AiZ

FLAC 1.3.0 has been released

Reply #106 –
Quote from: Maurits on
Quote from: lvqcl on
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).

Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?

That's because SSE4.1 code isn't faster than the corresponding C code compiled for x86-64. Not sure why. Maybe SSE code is just not optimal.


It's easier to explain why SSE4.1 is faster than 32-bit code. When FLAC encodes 24-bit input files it performs:
a) int32 * int32 -> int64 multiplications
b) int64 + int64 -> int64 additions
c) int64 SHR n -> int32 shifts
d) etc.
It's easy to do them in 64-bit mode when 64-bit registers are available, but in 32-bit mode they are noticeably slower. Fortunately it's possible to perform 64-bit calculations with SSE instructions.
But the instruction for int32 * int32 -> int64 multiplication (PMULDQ) was introduced only in SSE 4.1.

FLAC 1.3.0 has been released

Reply #107 –
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...

FLAC 1.3.0 has been released

Reply #108 –
Quote from: sundance on
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...

It should be vender_string (something like "libFLAC 1.2.1 (UTC 2007-09-17)").

FLAC 1.3.0 has been released

Reply #109 –
As far as I know the vendor string hasn't been updated to 1.3.1pre yet as this is not an official alpha release. A few people just pulled the most recent code from Git and compiled it themselves. The vendor string shouldn't be any different between 1.3.0 and this recent Git code.

It is more likely the result of a change in compression code. Even the slightest change to the compression can make resulting audio have identical checksums while the flac files will be different.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

FLAC 1.3.0 has been released

Reply #110 –
Additionally, FLAC uses floating-point math during its analysis process. Builds using different compiler options (or different compilers!) may make slightly different encoding decisions.

FLAC 1.3.0 has been released

Reply #111 –
Quote from: sundance on
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?

Well, yes, of course! How else would these new versions be encoding nearly twice as fast?

Quote from: sundance on
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...

Please refer to http://xiph.org/flac/faq.html#tools__different_sizes

Quote
Why doesn't the same file compressed on different machines with the same options yield the same FLAC file?
It's not supposed to, and neither does it mean either encoding was bad. There are many variations between different machines or even different builds of flac on the same machine that can lead to small differences in the FLAC file, even if they have the exact same final size. This is normal.

This is applicable too for different FLAC versions.
Music: sounds arranged such that they construct feelings.

FLAC 1.3.0 has been released

Reply #112 –
Quote from: ktf on
Quote from: sundance on
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?

Well, yes, of course! How else would these new versions be encoding nearly twice as fast?

Well, somehow I was under the impression that the SSE optimisations alone were responsible for that, my bad...
Anyway, a new version number should be considered then.

FLAC 1.3.0 has been released

Reply #113 –
Quote from: sundance on
Anyway, a new version number should be considered then.

which would happen with official versions (as noted a few posts up) but as this is all against non-official versions taken straight from git, not everything has been changed like version numbers reported by the compiles, etc.

FLAC 1.3.0 has been released

Reply #114 –
Is it safe to use the faster git builds or just stick with the official build for now?

FLAC 1.3.0 has been released

Reply #115 –
Quote from: kareha on
Is it safe to use the faster git builds or just stick with the official build for now?

Checksum matches so, they are safe probably like any other build. 1.3.1 should be released soon anyway.

FLAC 1.3.0 has been released

Reply #116 –
But it was tested less thoroughly than regular 1.3.0. What's worse, it still writes "reference libFLAC 1.3.0 20130526" to FLAC files, so it's not possible to easily find all FLAC files that were made with this version.

FLAC 1.3.0 has been released

Reply #117 –
Quote from: lvqcl on
But it was tested less thoroughly than regular 1.3.0. What's worse, it still writes "reference libFLAC 1.3.0 20130526" to FLAC files, so it's not possible to easily find all FLAC files that were made with this version.

Yes, it would probably be a good idea to start naming anything after a release "1.3.0post" in git until an official "1.3.1pre" comes out to prevent these sort of issues. It would allow people to test git versions (a good thing) without creating flac files with untested versions that are indistinguishable from a release version (a bad thing).
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

FLAC 1.3.0 has been released

Reply #118 –
Quote from: sundance on
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?


If your question is "Does FLAC 1.3.0git compress files any more efficiently than 1.3.0?" the answer appears to be no.  Recompressing a 1.3.0 file results in a ratio of "1.000" according to the console output.  The resulting files aren't binary-identical due to differing compilers or SSE code, but you won't gain any disk space.

AFAIK, the last version of FLAC to improve compression was 1.2.x.

FLAC 1.3.0 has been released

Reply #119 –
Quote from: Heliologue on
The resulting files aren't binary-identical due to differing compilers or SSE code, but you won't gain any disk space.

The audio stream is binary-identical though and that's what's important. Don't confuse the two, audio stream and file with metadata and everything else.

FLAC 1.3.0 has been released

Reply #120 –
FLAC built from git sources should make files that are bit-identical to 64-bit flac 1.3.0.

IOW:
For modes -0 ... -7: 64bit git = 32bit git = 64bit 1.3.0 = 32bit 1.3.0
For mode -8: 64bit git = 32bit git = 64bit 1.3.0 ≠ 32bit 1.3.0
(Usually. It depends on CPU and (as Octocontrabass mentioned) a compiler)

FLAC 1.3.0 has been released

Reply #121 –
I try to increase encoding speed slightly further. Please test the attached versions (with 16-bit input files).
Also please write your CPU model name (e.g.: Intel Core i7-950).

[removed]

FLAC 1.3.0 has been released

Reply #122 –
My speed results on Intel Core i7-4771 for encoding my test file with compression level 8:
flacA : 149.19x realtime speed
flacB : 177.15x realtime speed
flacC : 155.81x realtime speed
flacD : 186.40x realtime speed
Edit: For reference FLAC 1.3.0 runs at 91.06x realtime speed.

FLAC 1.3.0 has been released

Reply #123 –
Intel i7 M640. 

Times were taken with 7Bench's timer.exe: 
Code: [Select]
timer {flac} --best test.wav

Code: [Select]
exe       Global time (s)     xRealtime
---------------------------------------
1.3.0     20.808              50.028
A         11.305              92.083
B         9.834               110.936
C         10.476              99.369
D         8.828               117.920

Reference 1.3.0 is current 64-bit ICL 13.0 compile from Rarewares.

FLAC 1.3.0 has been released

Reply #124 –
Intel Q9400 @3.2Ghz
comp. level 8

86.64x AiZ git7251201 64bit
81.47x flacA
76.18x flacB
84.41x flacC
81.06x flacD