Message boards :
Number crunching :
More of those 17_3s's...
Message board moderation
Author | Message |
---|---|
Send message Joined: 9 Sep 08 Posts: 96 Credit: 336,443,946 RAC: 0 ![]() ![]() |
I like them, I like them a lot... 50% longer running (GPU)and proper credit :) |
![]() ![]() Send message Joined: 25 Jun 10 Posts: 284 Credit: 260,490,091 RAC: 0 ![]() ![]() |
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. |
![]() Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 ![]() ![]() ![]() |
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 |
![]() Send message Joined: 14 Dec 09 Posts: 161 Credit: 589,318,064 RAC: 0 ![]() ![]() |
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. 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. |
Send message Joined: 27 Nov 09 Posts: 108 Credit: 430,760,953 RAC: 0 ![]() ![]() ![]() |
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. |
![]() ![]() Send message Joined: 24 Jul 09 Posts: 32 Credit: 18,138,696 RAC: 73 ![]() ![]() |
50% longer running (GPU)and proper credit :) 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. ![]() |
Send message Joined: 27 Nov 09 Posts: 108 Credit: 430,760,953 RAC: 0 ![]() ![]() ![]() |
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. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 ![]() ![]() |
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. |
![]() Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 ![]() ![]() |
50% longer running (GPU)and proper credit :) 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. ![]() |
©2024 Astroinformatics Group