IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Dibrom's ICS vs. MSVC compiles..., Is there an ABXable difference?
Jebus
post Apr 4 2003, 00:13
Post #1





Group: Developer
Posts: 1293
Joined: 17-March 03
From: Calgary, AB
Member No.: 5541



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?

This post has been edited by Jebus: Apr 4 2003, 18:06
Go to the top of the page
+Quote Post
Garf
post Apr 4 2003, 00:21
Post #2


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



The difference shouldn't be noticeable, but I'd never trust an ICL compile myself.
Go to the top of the page
+Quote Post
_Balint_
post Apr 4 2003, 01:40
Post #3





Group: Members
Posts: 21
Joined: 15-November 02
Member No.: 3786



QUOTE (Garf @ Apr 4 2003 - 12:21 AM)
[...] I'd never trust an ICL compile myself.

Could you please explain that a little more?
Go to the top of the page
+Quote Post
Garf
post Apr 4 2003, 15:11
Post #4


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



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.
Go to the top of the page
+Quote Post
Gabriel
post Apr 4 2003, 15:40
Post #5


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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

Those are just programs made by programmers, there can be bugs.
Go to the top of the page
+Quote Post
Garf
post Apr 4 2003, 15:58
Post #6


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



The difference is in the frequency.
Go to the top of the page
+Quote Post
PatchWorKs
post Apr 4 2003, 16:33
Post #7





Group: Members
Posts: 498
Joined: 2-October 01
Member No.: 168



I'm really curious to know speed and quality results of these compilers:

- DJGPP
- LCC-Win32
- Digital Mars
- Borland
- Open Watcom
- MinGW
- TenDRA

blink.gif

Thanx a lot ! smile.gif

This post has been edited by PatchWorKs: Apr 4 2003, 16:34
Go to the top of the page
+Quote Post
dev0
post Apr 4 2003, 16:47
Post #8





Group: Developer
Posts: 1679
Joined: 23-December 01
From: Germany
Member No.: 731



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.
Go to the top of the page
+Quote Post
Tripwire
post Apr 4 2003, 17:12
Post #9





Group: Members
Posts: 156
Joined: 28-December 02
Member No.: 4272



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?
Go to the top of the page
+Quote Post
Chun-Yu
post Apr 4 2003, 17:18
Post #10





Group: Developer
Posts: 359
Joined: 29-October 02
Member No.: 3652



QUOTE (Tripwire @ Apr 4 2003 - 11:12 AM)
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).
Go to the top of the page
+Quote Post
NumLOCK
post Apr 4 2003, 18:03
Post #11


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



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 laugh.gif

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


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
Jebus
post Apr 4 2003, 18:06
Post #12





Group: Developer
Posts: 1293
Joined: 17-March 03
From: Calgary, AB
Member No.: 5541



QUOTE (Tripwire @ Apr 4 2003 - 08:12 AM)
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?
Go to the top of the page
+Quote Post
Chun-Yu
post Apr 4 2003, 18:12
Post #13





Group: Developer
Posts: 359
Joined: 29-October 02
Member No.: 3652



QUOTE (NumLOCK @ Apr 4 2003 - 12:03 PM)
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  laugh.gif

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

Really? What is it?
Go to the top of the page
+Quote Post
NumLOCK
post Apr 4 2003, 19:15
Post #14


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



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 laugh.gif

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

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


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
Garf
post Apr 4 2003, 19:29
Post #15


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (NumLOCK @ Apr 4 2003 - 08:15 PM)
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  laugh.gif

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

Pot. Kettle. Black.
Go to the top of the page
+Quote Post
NumLOCK
post Apr 4 2003, 21:17
Post #16


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



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 biggrin.gif

QUOTE
Pot. Kettle. Black.

umm.. What do you mean? blink.gif unsure.gif

This post has been edited by NumLOCK: Apr 4 2003, 21:18


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
Bedeox
post Apr 4 2003, 22:23
Post #17





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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

This post has been edited by Bedeox: Apr 4 2003, 22:29


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post
NumLOCK
post Apr 4 2003, 22:42
Post #18


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



QUOTE (Bedeox @ Apr 4 2003 - 10:23 PM)
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).


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
Bedeox
post Apr 4 2003, 22:48
Post #19





Group: Members
Posts: 246
Joined: 20-December 02
From: Quite quiet place in Poland
Member No.: 4181



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>

This post has been edited by Bedeox: Apr 4 2003, 22:58


--------------------
I've changed only because of myself.
Remember, when you quote me, you're quoting AstralStorm.
(read: this account is dead)
Go to the top of the page
+Quote Post

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: 29th August 2014 - 01:02