Re: Cuda client

Why not have NVIDIA code the client for us? D.net is open for new cores!
Always has been.
I think Mike's reply was fair enough on the topic!
Regards,
t_wolf

On Fri, Feb 1, 2013 at 7:27 AM, Matt Ruthenbeck <[email protected]> wrote:

> i will say this tho and have encountered similar arguments with other
> things NVIDIA that i myself use em, dont really mind current stuff as it
> is, but then again *keep in mind im not a programmer* do at times think
> programming for specific hardware is a pain but at the same time people
> that do program need to smarten up on how to for very specific things, not
> putting them down of course, its just in my view NVIDIA does surpass ATI in
> alot of ways, but again i dont know how u guys program with regards to
> CUDA, but i think its time for NVIDIA to get it but kicked in terms of
> actual programming and not be forced to use CUDA...  cause ive seen things
> using NVIDIA that is far sepurior to CUDA, but its all closed source so u
> guys will never see it....  this does include using the cores a bit
> better...  just something to think about...
> Matt Rafter/Ruthenbeck
> Email: [email protected]
> http://www.google.com/profiles/toffuuu
> http://www.hickorytech.net/~toffuuu/
> http://www.facebook.com/toffuuu
> http://www.last.fm/user/mac2010
> http://www.youtube.com/TheMac6010 <http://www.youtube.com/TheMac4010>
> http://www.boincstats.com/signature/user_29296.gif
> There may be fairies at the bottom of the garden. There is no evidence for
> it, but you can't prove that there aren't any, so shouldn't we be agnostic
> with respect to fairies? Richard Dawkins
>
>
> On Fri, Feb 1, 2013 at 12:02 AM, Andrew Hime <[email protected]>wrote:
>
>> Bert,
>>
>> With all due respect to all involved, the brick wall has been around for
>> probably a decade or more. I'm pleasantly surprised when something happens
>> every two years or so. The whole project has pretty much been on autopilot
>> for a LONG time at this point.
>>
>>
>>
>> On 01/31/13, bert<[email protected]> wrote:
>>
>> So apparently anyone who buys a 600 or 700 series Nvidia card(when the
>> 700 comes out or any later cards) is screwed and it would be no use to
>> run the distributed.net client even when Cuda has moved far away from
>> 3.1 which is old? Distributed.net NEEDS to put this information on their
>> front page that they no longer can put out a client that can support the
>> newer cards. What a damn waste and to think after 13 years the brick
>> wall is beginning to appear....
>>
>>
>> Bert
>> On 1/31/2013 1:18 PM, Décio Luiz Gazzoni Filho wrote:
>> > On Jan 31, 2013, at 3:52 PM, Joseph Kaye <[email protected]> wrote:
>> >
>> >> On 1/30/2013 2:18 PM, bert wrote:
>> >>> The Cuda client is still at 3.1 and the with the latest Nvidia
>> >>> driver(310.90) using version 5,could this be the reason my son's GTX
>> 680
>> >>> is slower than his old GTX 580(which is in use on my other son's
>> >>> computer)? I was kind of shocked and was expecting a much quicker pace
>> >>> in going through 64 stats units(the GTX 580 is averaging about 3
>> minutes
>> >>> or so vs almost 8 minutes with the GTX 680!) Any help or suggestions
>> >>> would be appreciated.
>> >>>
>> >>> Bert
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> rc5 mailing list
>> >>> rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>> >>> http://lists.distributed.net/mailman/listinfo/rc5
>> >>>
>> >> It doesn't look like the 6xx series is working so well for dnetc.
>> >>
>> >> http://bugs.distributed.net/show_bug.cgi?id=4507
>> >>
>> >> Apparently they changed the design of the GPU, and while they do have
>> >> more cores now, they removed instructions (or something) that DNETC
>> >> needs for faster computations. IIRC, it's kinda like when Intel removed
>> >> the ROT function from the P4 CPU's. They had a higher clock speed, but
>> >> because of the ROTate function was not there, the keyrate was much
>> slower.
>> > Just to clear up a common misconception: Intel never *removed* an
>> instruction from a new processor that was present in an earlier processor,
>> including rol. That would break up backward compatibility which is a main
>> selling point of the x86 architecture (and by extension the Wintel
>> platform).
>> >
>> > What did happen is that there is a piece of hardware used for efficient
>> (usually single-cycle) implementation of variable-sized shifts and
>> rotations (the shl, shr, sar, rol, ror, rcl and rcr instructions) -- that
>> hardware is called a barrel shifter. it has historically been implemented
>> on every Intel processor since the 80386 or so, but don't quote me on that.
>> Certainly the classic 1993-era Pentium did have it. The barrel shifter is
>> what wasn't present on the Pentium 4, and the reason why the rol
>> instruction executed slower (I believe it took 4 cycles).
>> >
>> > So the instruction has always existed, even on the Pentium 4 -- it had
>> to because of backward compatibility reasons -- but the hardware for
>> efficiently implementing it didn't exist only on the P4 chips, and Intel
>> has added it back on the newer Core chips, which is why they perform better.
>> >
>> > Décio
>> > _______________________________________________
>> > rc5 mailing list
>> > rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>> > http://lists.distributed.net/mailman/listinfo/rc5
>>
>> _______________________________________________
>> rc5 mailing list
>> rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>> http://lists.distributed.net/mailman/listinfo/rc5
>>
>> _______________________________________________
>> rc5 mailing list
>> rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
>> http://lists.distributed.net/mailman/listinfo/rc5
>>
>>
>
> _______________________________________________
> rc5 mailing list
> rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
> http://lists.distributed.net/mailman/listinfo/rc5
>
>

_______________________________________________
rc5 mailing list
rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/rc5