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

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.

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

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.

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.

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.

---

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.

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.

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.

---