Windows Beta Test App 4.24 available

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,027
Credit: 215,662,186
RAC: 76,719

Thanks for drawing my

Thanks for drawing my attention back to this one.

Pretty weird, the "Required frequency-bins" should be positive integers, but "[-8, 8]" is listed in most of these errors. Looking into it...

BM

BM

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 468,679,238
RAC: 58,045

RE: Thanks for drawing my

Message 69342 in response to message 69341

Quote:

Thanks for drawing my attention back to this one.

Pretty weird, the "Required frequency-bins" should be positive integers, but "[-8, 8]" is listed in most of these errors. Looking into it...

BM

The owner of the box posted here recently, btw.

CU

BRM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,027
Credit: 215,662,186
RAC: 76,719

See here. BM

See here.

BM

BM

Jesse Viviano
Jesse Viviano
Joined: 8 Jun 05
Posts: 31
Credit: 66,039,676
RAC: 0

I noticed that around the

I noticed that around the time Visual Studio .NET 2003 was released, the programmers at the Folding@home project noticed that their science code in their clients, which was written in hand-crafted assembly code and takes advantage of SSE and 3DNow!, were causing earlier revisions of Athlons with SSE to crash, while Pentium III's and Pentium 4's were not crashing on the same code. Therefore, Microsoft was forced to add this code to avoid writing code that crashes because no one knew at the time what was causing this behavior. Later on, somebody found out that the Folding@home code was using non-aligned memory accesses in its SSE code, and that was causing the Athlons to crash and was slowing the other chips down. Since almost no commercially-released compiler would be stupid enough to generate any code with the mistake of non-aligned memory accesses anyways, maybe it is time to upgrade the compiler to Visual Studio 2005, which might have the detection code removed because a compiler will never make the mistake that will cause the chip bugs to crash those Athlons.

Sometimes, it takes assembly coders to generate unusual code to detect chip bugs.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 468,679,238
RAC: 58,045

RE: I noticed that around

Message 69345 in response to message 69344

Quote:

I noticed that around the time Visual Studio .NET 2003 was released, the programmers at the Folding@home project noticed that their science code in their clients, which was written in hand-crafted assembly code and takes advantage of SSE and 3DNow!, were causing earlier revisions of Athlons with SSE to crash, while Pentium III's and Pentium 4's were not crashing on the same code. Therefore, Microsoft was forced to add this code to avoid writing code that crashes because no one knew at the time what was causing this behavior. Later on, somebody found out that the Folding@home code was using non-aligned memory accesses in its SSE code, and that was causing the Athlons to crash and was slowing the other chips down. Since almost no commercially-released compiler would be stupid enough to generate any code with the mistake of non-aligned memory accesses anyways, maybe it is time to upgrade the compiler to Visual Studio 2005, which might have the detection code removed because a compiler will never make the mistake that will cause the chip bugs to crash those Athlons.

Hi!

Interesting, is there a source where one could read more about this?

Visual Studio 2005 indeed does no longer have this detection code, but anyways one would have expected MS to correct this "issue" in one of their service packs to Visual Studio 2003.

Very much has changed in the floating point department between VS 2003 and 2005, and you can bet that also some new bugs have been introduced, so changing the compiler always comes at a certain risk. Anyway, the long term plans seem to be to compile the Windows version under gcc as well once that works.

CU

BRM

ohiomike
ohiomike
Joined: 4 Nov 06
Posts: 80
Credit: 6,453,639
RAC: 0

RE: RE: I noticed that

Message 69346 in response to message 69345

Quote:
Quote:

I noticed that around the time Visual Studio .NET 2003 was released, the programmers at the Folding@home project noticed that their science code in their clients, which was written in hand-crafted assembly code and takes advantage of SSE and 3DNow!, were causing earlier revisions of Athlons with SSE to crash, while Pentium III's and Pentium 4's were not crashing on the same code. Therefore, Microsoft was forced to add this code to avoid writing code that crashes because no one knew at the time what was causing this behavior. Later on, somebody found out that the Folding@home code was using non-aligned memory accesses in its SSE code, and that was causing the Athlons to crash and was slowing the other chips down. Since almost no commercially-released compiler would be stupid enough to generate any code with the mistake of non-aligned memory accesses anyways, maybe it is time to upgrade the compiler to Visual Studio 2005, which might have the detection code removed because a compiler will never make the mistake that will cause the chip bugs to crash those Athlons.

Hi!

Interesting, is there a source where one could read more about this?

Visual Studio 2005 indeed does no longer have this detection code, but anyways one would have expected MS to correct this "issue" in one of their service packs to Visual Studio 2003.

Very much has changed in the floating point department between VS 2003 and 2005, and you can bet that also some new bugs have been introduced, so changing the compiler always comes at a certain risk. Anyway, the long term plans seem to be to compile the Windows version under gcc as well once that works.

CU

BRM

The hot ticket if you want performance is the Intel ICC/IPP combination. It produces code that is about 40% faster than gcc on Intel and 25% faster on other cpu's. Supports Linux, Windows (icc called by VS is an option), and Mac.


Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 468,679,238
RAC: 58,045

RE: The hot ticket if you

Message 69347 in response to message 69346

Quote:

The hot ticket if you want performance is the Intel ICC/IPP combination. It produces code that is about 40% faster than gcc on Intel and 25% faster on other cpu's. Supports Linux, Windows (icc called by VS is an option), and Mac.

But is it fair to AMD CPUs now? It used to cripple the code on AMD CPUs, much like what we saw with Microsoft VS 2003 here.

CU

BRM

Jesse Viviano
Jesse Viviano
Joined: 8 Jun 05
Posts: 31
Credit: 66,039,676
RAC: 0

RE: RE: I noticed that

Message 69348 in response to message 69345

Quote:
Quote:

I noticed that around the time Visual Studio .NET 2003 was released, the programmers at the Folding@home project noticed that their science code in their clients, which was written in hand-crafted assembly code and takes advantage of SSE and 3DNow!, were causing earlier revisions of Athlons with SSE to crash, while Pentium III's and Pentium 4's were not crashing on the same code. Therefore, Microsoft was forced to add this code to avoid writing code that crashes because no one knew at the time what was causing this behavior. Later on, somebody found out that the Folding@home code was using non-aligned memory accesses in its SSE code, and that was causing the Athlons to crash and was slowing the other chips down. Since almost no commercially-released compiler would be stupid enough to generate any code with the mistake of non-aligned memory accesses anyways, maybe it is time to upgrade the compiler to Visual Studio 2005, which might have the detection code removed because a compiler will never make the mistake that will cause the chip bugs to crash those Athlons.

Hi!

Interesting, is there a source where one could read more about this?

Visual Studio 2005 indeed does no longer have this detection code, but anyways one would have expected MS to correct this "issue" in one of their service packs to Visual Studio 2003.

Very much has changed in the floating point department between VS 2003 and 2005, and you can bet that also some new bugs have been introduced, so changing the compiler always comes at a certain risk. Anyway, the long term plans seem to be to compile the Windows version under gcc as well once that works.

CU

BRM

I actually made a reasonable guess at what was happening with VS 2003 and SSE, but the rest of this can be found somewhere in the Folding@home forums at http://forum.folding-community.org/. The temporary workaround was to fall back to 3DNow! mode whenever an Athlon was detected. Incidentally, 3DNow! mode was slower on an Athlon than SSE mode when both modes are able to function properly. This happened many years ago, so I do not want to spend hours searching that forum.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.