Welcome to MilkyWay@home

Wrong application served to my computer

Message boards : Number crunching : Wrong application served to my computer
Message board moderation

To post messages, you must log in.

AuthorMessage
Jesse Viviano

Send message
Joined: 4 Feb 11
Posts: 86
Credit: 60,913,150
RAC: 0
Message 47606 - Posted: 11 Apr 2011, 16:39:21 UTC

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.
ID: 47606 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matt Arsenault
Volunteer moderator
Project developer
Project tester
Project scientist

Send message
Joined: 8 May 10
Posts: 576
Credit: 15,979,383
RAC: 0
Message 47745 - Posted: 12 Apr 2011, 23:50:41 UTC - in response to Message 47606.  

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.
ID: 47745 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matt Arsenault
Volunteer moderator
Project developer
Project tester
Project scientist

Send message
Joined: 8 May 10
Posts: 576
Credit: 15,979,383
RAC: 0
Message 47746 - Posted: 12 Apr 2011, 23:53:00 UTC - in response to Message 47606.  

There shouldn't be much of a difference between 32bit + SSE2 and 64 bit performance anyway.
ID: 47746 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matt Arsenault
Volunteer moderator
Project developer
Project tester
Project scientist

Send message
Joined: 8 May 10
Posts: 576
Credit: 15,979,383
RAC: 0
Message 47749 - Posted: 13 Apr 2011, 0:14:02 UTC - in response to Message 47606.  

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.
ID: 47749 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Matt Arsenault
Volunteer moderator
Project developer
Project tester
Project scientist

Send message
Joined: 8 May 10
Posts: 576
Credit: 15,979,383
RAC: 0
Message 47750 - Posted: 13 Apr 2011, 0:15:27 UTC - in response to Message 47749.  

This will be fixed next time I redo all the normal separation applications.
ID: 47750 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Jesse Viviano

Send message
Joined: 4 Feb 11
Posts: 86
Credit: 60,913,150
RAC: 0
Message 47754 - Posted: 13 Apr 2011, 1:42:24 UTC
Last modified: 13 Apr 2011, 1:47:10 UTC

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).
ID: 47754 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : Wrong application served to my computer

©2024 Astroinformatics Group