Hi,

did anyone here try (and succeed) to compile Lame with the latest ICL?

I can't get it to work, when I run the exe it gives me something like:
The instruction at "0x00416fb4" referenced memory at "0x4fe4b3f4". The memory could not be "read".

I turned off all optimizations, but the problem remained.
As soon as I used the MS compiler the lame.exe works flawlessly.

bye,
Michael

I just recompiled here using ICL9.0 with the same optimisations used with 4.5 and the .exe runs fine. (3.97alpha)

hey john33, do u know if the ICL 9 slows down code when it's run on an AMD CPU?
(something like this)

Hmmm, a somewhat horrifying if interesting contention. I don't know because I haven't tried but if it can be demonstrated to be the case I, for one, will cease using the Intel compilers immediately. I am also interested as I am about to move to an AMD Athlon64 platform.

Which source did you use? I got it from cvs yesterday.
Did you use the latest MS-Platform SDK?

I never had this problem before, very strange :/.

bye,
Michael

@katharsis
do you use Makefile.MSVC or the studio project files?

Current 3.97alpha CVS. I compiled using the VC6 IDE with ICL4.5 and 9.0 integrated.

http://www.heise.de/ct/inhverz/search.shtm...t&Suchen=suchen
It seems the intel compiler has some optimization switch for Prescott CPUs (mainly SSE3, plus some other optimizations). If no Prescott CPU is detected, the code does not run. In above article they used a patched compiler and saw some improvements for AMD CPUs. One benchmark test showed some 36 percent performance boost.

First I tried MSVC 6 and the dsw, when I only got crashes I switched to the makefile, didn't make a difference .

The switches used in the Intel compiler enable optimisations specifically for Intel CPU's, regardless of whether another CPU would be compatible. It's an "only guaranteed to work on" thing. The letters of the switches match the codenames for the respective CPU cores where the features used were introduced in, -xW(illamette), -xP(rescott), etc. I'm not sure how much of a case AMD has here, but the binaries produced are indeed remarkably "intelligent" when it comes to detecting CPU's.