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: Dibrom's ICS vs. MSVC compiles... (Read 8674 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Dibrom's ICS vs. MSVC compiles...

I know the MSVC compile is a bit slower and produces slightly smaller MP3s, but my question is whether or not this is ABXable with --alt-preset standard? Like, am I getting a better MP3 with the ICL compile or is it negligable? My ears just aren't good enough - anyone?

Dibrom's ICS vs. MSVC compiles...

Reply #1
The difference shouldn't be noticeable, but I'd never trust an ICL compile myself.

Dibrom's ICS vs. MSVC compiles...

Reply #2
Quote
[...] I'd never trust an ICL compile myself.

Could you please explain that a little more?

Dibrom's ICS vs. MSVC compiles...

Reply #3
ICL occasionally miscompiles stuff, you don't always notice it right away.

The 'trusted' LAME compiles have been checked though, so they should be safe.

Dibrom's ICS vs. MSVC compiles...

Reply #4
Well, I'd say that msvc also sometimes miscompiles things and gcc too.

Those are just programs made by programmers, there can be bugs.

Dibrom's ICS vs. MSVC compiles...

Reply #5
The difference is in the frequency.


Dibrom's ICS vs. MSVC compiles...

Reply #7
Both DJGPP and MinGW are based upon GCC and other GNU utils.
DJGPP = DOS port
MinGW = native Win32 port
Additionally there is cygwin, which is a UNIX compatibility layer for Win32 used to port *nix apps over with almost no modifications to the original code.

dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

Dibrom's ICS vs. MSVC compiles...

Reply #8
Err?

Isn't the same source code compiled with whatever compiler supposed to generate the same results each time? How does it come that there's a difference between ICL and MSVC compiles? That an issue with the math libraries they use?

Dibrom's ICS vs. MSVC compiles...

Reply #9
Quote
Err?

Isn't the same source code compiled with whatever compiler supposed to generate the same results each time? How does it come that there's a difference between ICL and MSVC compiles? That an issue with the math libraries they use?

No, the results will depend on the optimizations the compiler performs.  For example, one time a wrote a simple reverb that worked perfectly in VC++ and blew up in ICL release mode (worked fine in ICL debug mode).

Dibrom's ICS vs. MSVC compiles...

Reply #10
Chun-Yu:

I have a nice example, using 2 lines of integer C code without any library call, which gives the wrong result in VC++ and the right one on all other compilers 

Reported to M$ 3 years ago, still not fixed.

Dibrom's ICS vs. MSVC compiles...

Reply #11
Quote
Err?

Isn't the same source code compiled with whatever compiler supposed to generate the same results each time? How does it come that there's a difference between ICL and MSVC compiles? That an issue with the math libraries they use?

The thing is, when dealing with floating point numbers, some compilers round differently and use different precisions. as a result. MSVC tends to make mp3s a bit smaller than the recommended ICL compile.

I'm still wondering if this is an audible difference... anyone?

Dibrom's ICS vs. MSVC compiles...

Reply #12
Quote
Chun-Yu:

I have a nice example, using 2 lines of integer C code without any library call, which gives the wrong result in VC++ and the right one on all other compilers  

Reported to M$ 3 years ago, still not fixed.

Really?  What is it?

Dibrom's ICS vs. MSVC compiles...

Reply #13
I have a stronger example on my main computer (currently inaccesible / put in boxes - I'm moving places).

However, I can remember of this one:

void testing()
{
int toto=32;
int u=1<<32; // gives u=0 - ok
int v=1<<toto;  // gives u=1 instead of 0
}

Microsoft claims a correct result is not guaranteed with toto >= 32. I answered them: in this case, why do I see no compilation warning - you bunch of morons 

For the record, this behavior is related with Intel's x86 SHR and SHL instructions - which are badly implemented since the 8086 

This strange behavior (using VC++) was a major factor in the failure of digital signature authentication units for ballistic missiles in the U.S army.

Cheers

Dibrom's ICS vs. MSVC compiles...

Reply #14
Quote
Microsoft claims a correct result is not guaranteed with toto >= 32. I answered them: in this case, why do I see no compilation warning - you bunch of morons 

You are writing code that is undefined per spec and you complain the result is undefined?

Pot. Kettle. Black.

Dibrom's ICS vs. MSVC compiles...

Reply #15
Actually the spec is vague and permissive on this point. This is very much like the max_huff "bug" in winamp versions of the past..

Anyway, that was just an example I had in mind. The real one is in an obscure path on the other pc 

Quote
Pot. Kettle. Black.

umm.. What do you mean?   

Dibrom's ICS vs. MSVC compiles...

Reply #16
Well, this seems like a bug in MSVC, the behaviour is probably defined in IEEE standard...
But it might be that you've enabled some math optimizations similar to GCCs -ffast-math
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)

Dibrom's ICS vs. MSVC compiles...

Reply #17
Quote
Well, this seems like a bug in MSVC, the behaviour is probably defined in IEEE standard...

Not completely: they say that an undefined behaviour is allowed in the case "left or right shift over X bits or more" where X is the integer type's number of bits.

Quote
But it might be that you've enabled some math optimizations similar to GCCs -ffast-math

Nope.. plain default config of VC++ 6.0.  BTW, it's not floating-point stuff (so FP math optimizations would have few effect on this - if any).

 

Dibrom's ICS vs. MSVC compiles...

Reply #18
Actually -ffast-math does also fixed-point optimisations...
-funsafe-math-optimizations does only floating-point ones.
-ffast-math implies -funsafe-math-optmizations

Is there any standard which specifies proper behaviour?

<edit>
Spelling, spelling, spelling... (that should be my mantra)
</edit>
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)