Welcome to MilkyWay@home

More of those 17_3s's...


Advanced search

Message boards : Number crunching : More of those 17_3s's...
Message board moderation

To post messages, you must log in.

AuthorMessage
JAMC

Send message
Joined: 9 Sep 08
Posts: 96
Credit: 336,443,946
RAC: 0
300 million credit badge13 year member badge
Message 43979 - Posted: 19 Nov 2010, 19:22:20 UTC

I like them, I like them a lot... 50% longer running (GPU)and proper credit :)
ID: 43979 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profilemdhittle*
Avatar

Send message
Joined: 25 Jun 10
Posts: 284
Credit: 260,490,091
RAC: 0
200 million credit badge11 year member badge
Message 43987 - Posted: 20 Nov 2010, 2:20:47 UTC - in response to Message 43979.  

I like them, I like them a lot... 50% longer running (GPU)and proper credit :)


I like them, also. I wish I could fill my cache up with just them. At least until, the new "even longer" workunits come out.
ID: 43987 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Zydor
Avatar

Send message
Joined: 24 Feb 09
Posts: 620
Credit: 100,587,625
RAC: 0
100 million credit badge12 year member badgeextraordinary contributions badge
Message 44001 - Posted: 20 Nov 2010, 13:33:32 UTC - in response to Message 43987.  

Gets my vote - with cards getting ever faster, the 20-30 second load up time into the GPU becomes more and more significant. Already a twin 5970 setup does a GPU in the same time as loading one up, at times quicker. I suspect the impending 6990s will be quicker in crunching them for a twin 6990 than loading it into the GPU in the first place :) So longer WUs will mean much better throughput of completed work from the higher end cards.

Regards
Zy
ID: 44001 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ProfileArif Mert Kapicioglu

Send message
Joined: 14 Dec 09
Posts: 161
Credit: 589,318,064
RAC: 0
500 million credit badge11 year member badge
Message 44002 - Posted: 20 Nov 2010, 15:00:38 UTC - in response to Message 44001.  

Gets my vote - with cards getting ever faster, the 20-30 second load up time into the GPU becomes more and more significant. Already a twin 5970 setup does a GPU in the same time as loading one up, at times quicker. I suspect the impending 6990s will be quicker in crunching them for a twin 6990 than loading it into the GPU in the first place :) So longer WUs will mean much better throughput of completed work from the higher end cards.

Regards
Zy


I couldn't agree more. It takes couple of seconds to load/unload and longer wus would provide a better/longer utilization of the GPU. Like DNETC@Home, it would be much more efficient than current, in macro sense.
ID: 44002 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Priebe

Send message
Joined: 27 Nov 09
Posts: 108
Credit: 430,760,953
RAC: 0
300 million credit badge11 year member badgeextraordinary contributions badge
Message 44162 - Posted: 24 Nov 2010, 8:59:22 UTC - in response to Message 43979.  

50% longer running (GPU)and proper credit :)

True for the GPU WU's. But all of the 17_3s's I've seen processed by CPU app 0.45 (SSE2) fail instantly on an access violation.
ID: 44162 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ProfileWhite Mountain Wes
Avatar

Send message
Joined: 24 Jul 09
Posts: 31
Credit: 13,651,724
RAC: 6,631
10 million credit badge12 year member badge
Message 44165 - Posted: 24 Nov 2010, 10:33:16 UTC - in response to Message 44162.  

50% longer running (GPU)and proper credit :)

True for the GPU WU's. But all of the 17_3s's I've seen processed by CPU app 0.45 (SSE2) fail instantly on an access violation.

All of the 17_3s WUs sent to my CPU have crashed and burned in about 10 seconds. The last one I ran generated "exit code -1073740940 (0xc0000374)". It's not a big deal since they are not wating much of my CPU time, but I'm sure that these WU's were not intended to work that way.
ID: 44165 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Priebe

Send message
Joined: 27 Nov 09
Posts: 108
Credit: 430,760,953
RAC: 0
300 million credit badge11 year member badgeextraordinary contributions badge
Message 44169 - Posted: 24 Nov 2010, 13:50:06 UTC - in response to Message 44165.  

The last one I ran generated "exit code -1073740940 (0xc0000374)"

Sounds like something is very wrong with version 0.45. Your error indicates the dynamic memory heap has become corrupted.
ID: 44169 · 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
10 million credit badge11 year member badge
Message 44177 - Posted: 24 Nov 2010, 17:33:15 UTC - in response to Message 44165.  

50% longer running (GPU)and proper credit :)

True for the GPU WU's. But all of the 17_3s's I've seen processed by CPU app 0.45 (SSE2) fail instantly on an access violation.[/quote]I'm pretty sure I know why this is happening. It's in the horrible input file code which I really want to kill with fire. Those workunits use multiple cuts, which I didn't have a test of for a while. On Windows, for the OpenCL stuff I use _aligned_malloc, which then happens to get plain realloc'd in the case of multiple cuts. There's a greater chance that it will explode on Windows since it makes you treat pointers from _aligned_malloc sort of differently.
ID: 44177 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ProfileTravis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
10 thousand credit badge14 year member badge
Message 44272 - Posted: 26 Nov 2010, 7:08:21 UTC - in response to Message 44177.  
Last modified: 26 Nov 2010, 7:09:19 UTC

50% longer running (GPU)and proper credit :)

True for the GPU WU's. But all of the 17_3s's I've seen processed by CPU app 0.45 (SSE2) fail instantly on an access violation.


I'm pretty sure I know why this is happening. It's in the horrible input file code which I really want to kill with fire. Those workunits use multiple cuts, which I didn't have a test of for a while. On Windows, for the OpenCL stuff I use _aligned_malloc, which then happens to get plain realloc'd in the case of multiple cuts. There's a greater chance that it will explode on Windows since it makes you treat pointers from _aligned_malloc sort of differently.



the Input file really does suck. If we could get the GPU applications updated (hint hint), we'd be able to modify it and make it sensible.

It'd also make the server a bit more snappy as we wouldn't have to process the results from the files the current GPU applications are still returning.
ID: 44272 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : More of those 17_3s's...

©2021 Astroinformatics Group