Topic: [ANN][YAC] YACoin ongoing development - page 172. (Read 380060 times)

I can't believe that hasn't already happened.

Also - is the mtrit in this thread famous mtrit or famous original mtrit?

Only the last page or two, and there's a bunch of client-related stuff dealing with checkpoints and the warning the original client is showing mixed in.  Certainly a discussion about GPU mining and the first people to post hash rates and implementation details is of interest to ongoing YACoin development.

Just my 2 cents here:

Congratulation to mtrlt, you deserve all your litecoins

For the rest:

I understood that you wanted to continue to develop yacoin for it's "uniqueness" being cpu-only (AFAIK FPGA from the start)
What I see here it's quite different, maybe you should change thread title as it's not about the client, it's about the miner.
If you are up to multiply your daily crypto income there are easier available-to-eveybody way to do this.
Don't take this as an attack 

Just download the latest WindMaster's client and compile it and you won't get any warnings. Running the old client won't do any harm though.

I just want to see how others think. So far, except for BTC, I've always been the first to make an open source GPU miner for a currency that has had a new hash function. (My list only contains Solidcoin 2.0 and Litecoin, though. Maybe I've missed some altcoins?) I've not seen the OpenCL development practices of anyone else. I'm just curious, that's all. You don't have to send me code if you don't want to.

I can post my code but it's still buggy (the hash not accepted):
http://sourceforge.net/projects/hnindev/files/scrypt130302.cl

The bug might involved in mem copy from registers to memory or from memory to registers (the endian problem).

But for what purpose, if we all achieved way shittier hash rates than you did?



Oh, I think I have a good idea what everyone will probably ask for in return, and it's not something you're likely to give.    It's sorta like everyone that keeps PM'ing me asking for my Verilog implementation for FPGA's, thinking they're going to run it on off-the-shelf BTC mining FPGA boards, or not reading close enough that it was an implementation for N=32 specifically.  I'm saving that especially for the next altcoin that gets the bright idea to fork YACoin into yet another useless copy-pasta altcoin launch with difficulty set to 0.

Right now, I'm hesitant to reveal details. I'd absolutely love it you (FlyLord, WindMaster, hanzac, others?) could PM me your OpenCL code, but I don't know what I could give in return.

mtrlt, want to give us a hint as to what you optimized?

I've not yet tested high N values extensively, however I know that N=512 is the first N where lookup_gap=2 is faster than lookup_gap=1.

;-) for chacha I ported to this:

I also port directly from scrypt-jane source code. For ROTL64 & ROTL32, I use rotate(x,y) function of CL. I also use some vector types. That's why I need to care much more about the endian problems ... Maybe I should start with little change.

Yeah.  Their hard forks came about through incompatible changes to the client though, if I understand correctly.  I kinda hold hard forks of the blockchain to be generally bad policy unless absolutely necessary, because it enforces changes upon the whole of a coin's population to change the parameters of the coin to something different than they understood the coin to be when they adopted the coin.  For example, the Elacoin miners trying to hard fork their blockchain and change their client so their mining reward is even higher for late adopter miners than what everyone understood it to be when they adopted Elacoin and started mining it (effectively, jacking up their rate of inflation).  And some mention of trying to get all the Elacoin mining pools onboard with the change to gain majority hashpower and try to force the change on everyone using Elacoin.  That really rubbed me the wrong way how they were going about that.



Perhaps.  Here's what's in there now:


So, after 10 days it throws that particular warning.  Changing it to 60 days could be workable but we definitely need to rewrite the warning, I'd think.  As it is, it already leaves someone with no clue whether their client is even working anymore.

Anyone have any thoughts on what it should actually say?  Perhaps something like "WARNING: Your YACoin client is more than 60 days old and may not contain the most recent checkpoints.  You may want to check if a more recent version of the YACoin client is available."

If I had to guess he read the keccak whitepaper which talks about optimizing the code, there's apparently some instructions that are not necessary or something. I'm also not taking advantage of the vector types. The core ChaCha code as an example, takes 16 uint's and could be done using either a uint4 [4] or uint8 [2] or uint16 -- but, as I mentioned, I've got no clue if that would actually make it faster.

After reading the PBKDF2 specs and pseudocode, I also think there are too many steps in the scrypt-jane code -- maybe I'm just reading it wrong -- that are not necessary for what we're doing.

Also, to figure out endianess query the "CL_DEVICE_ENDIAN_LITTLE" property through OpenCL, that way you'll know for sure.

I searched on google, there're some page saying "Radeon GPUs are big-endian" ...

Interestingly, your hash rate is right in the same ballpark as mine for N=6 on a 6950.  Guess that makes 2 of us in the catastrophically unoptimized OpenCL implementation club..  Probably won't surprise anyone that I'm staring at my OpenCL code right now trying to figure out what I did wrong, as I'd consider mtrlt to be a reliable source (as the first person to publicly write an OpenCL scrypt implementation, and just about everyone mining Litecoin on GPU's is using his OpenCL code).

I don't think resistance to any technology in mind is a good way. The key point is the strength of the network, the security of the network and the fair reward for maintaining the network efficiency.

? The Radeon HD's are Little Endian, easiest way to check is to query the props via OpenCL

Also you can make a coin GPU resistant by requiring a lot of memory to get good speed. The thing about gpus is that they're highly paralellization but slow in serial processes. So if you can modify scrypt to remove the tmto and force all N precalculated spaces to be required it would reduce the effectiveness. Go even further and make N *and* r increase over time

I tried last weekend to port the scryp jane code to open cl, but I only achieved at 60kH with 7950, besides the hash is not valid. So I give up because at that point I don't think it's worthwhile to keep on.

I think the main problem is that Radeon GPU uses big-endian, I might not treat it correctly at some point.

I used the cgminer, but I have very little knowledge about its implementation and I also new to these open cl and its system calls (too much functions ... that's why I don't like to use them).

The way I debug it is that I compiled the cl kernel source (modified slightly) with gcc directly. It actually produce the same hash in comparison with the original one. But the endian problem still exists ...

This is likely true.  I think the best one can hope for is to narrow the performance gap between CPU's and GPU's by making the memory usage large enough that it gets pushed out to significant amounts of external RAM.  At that point, external RAM bandwidth is the deciding factor.  We're already seeing GPU's with wider external memory busses than many CPU's however.

At best it's an arms race.  It appears that with YAC, the lag time for people to implement it on OpenCL still gave early CPU miners a significant head-start (I just wish I was one of those that actually got the head-start).