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.
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.
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.
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.
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.
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
RE: Thanks for drawing my
)
The owner of the box posted here recently, btw.
CU
BRM
See here. BM
)
See here.
BM
BM
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.
RE: I noticed that around
)
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
RE: RE: I noticed that
)
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.
RE: The hot ticket if you
)
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
RE: RE: I noticed that
)
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.