Message boards :
Number crunching :
Wrong application served to my computer
Message board moderation
Author | Message |
---|---|
Send message Joined: 4 Feb 11 Posts: 86 Credit: 60,913,150 RAC: 0 |
I noticed that my computer, a self-built computer with a Core i7 980X running Windows 7 64-bit, was served the 32-bit SSE2 application in an earlier CPU (not n-body) MilkyWay@home task. Later, it was served the non-SSE2 32-bit application in a later CPU reguler (not n-body) MilkyWay@home task. Since AMD64 and Intel's clone of that guarantee SSE2, why is the server serving me up the non-SSE2 application? Personally, I would prefer if the developers would develop a 64-bit multithreaded regular MilkyWay@home application. If it can be parallelized to run on a GPU, it should be easy to turn that into a multithreaded application. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
I noticed that my computer, a self-built computer with a Core i7 980X running Windows 7 64-bit, was served the 32-bit SSE2 application in an earlier CPU (not n-body) MilkyWay@home task. Later, it was served the non-SSE2 32-bit application in a later CPU reguler (not n-body) MilkyWay@home task. Since AMD64 and Intel's clone of that guarantee SSE2, why is the server serving me up the non-SSE2 application?This was something that I remember explicitly fixing in the scheduler fix that prompted the whole server mess, but it wouldn't be surprising if it's not working correctly. Personally, I would prefer if the developers would develop a 64-bit multithreaded regular MilkyWay@home application. If it can be parallelized to run on a GPU, it should be easy to turn that into a multithreaded application. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
There shouldn't be much of a difference between 32bit + SSE2 and 64 bit performance anyway. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
Actually I looked into it and to avoid fixing the scheduler before, there are x86_64 things with the __sse2 added on. Additionally, on Windows the current separation stuff isn't actually 64 bit anyway for some related reason I don't really remember. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
This will be fixed next time I redo all the normal separation applications. |
Send message Joined: 4 Feb 11 Posts: 86 Credit: 60,913,150 RAC: 0 |
One valid reason for keeping the 32-bit version is to take advantage of the x87 FPU's native 80-bit precision. However, using SSE2 throws that advantage out the window because SSE2 does things either in 32-bit or 64-bit precision and cannot handle 80-bit precision. The x87 FPU is deprecated in 64-bit mode by both AMD's ABI (used everywhere except in Windows) and by the Microsoft 64-bit ABI (used only in Windows), so it should not be used in 64-bit mode because neither ABI are required to save the contents of the x87 FPU registers when they need to swap tasks. They are required to save the contents of the x87 FPU registers for a program running in compatibility mode (e.g. a 16-bit or 32-bit protected mode program that makes absolutely no use of real or virtual 8086 mode running on an OS running in long mode). |
©2024 Astroinformatics Group