[ANN][YAC] YACoin ongoing development

[mtrlt]

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal.  Why would we want to cap the N increase before 512MB is reached?  It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now.  In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's.  Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Huh, for some reason I thought N was going up far more rapidly than that. Forgive my bad memory. Anyway, starting N at 512MB memory usage would have resulted in people being able to mine at something like 20 H/s (not tested, only approximately calculated), but I guess it would have been plenty of speed. Verifying blocks would have taken quite a long time though and would have eaten some of your hashrate, but again, it'd probably have been fine.

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

[1713616605]

1713616605

[1713616605]

1713616605

[1713616605]

1713616605

[1713616605]

1713616605

[Puycheval]

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

Do you have numbers to share with us ?

[eule]

I also have a working YAC kernel for my own miner, Reaper.

Just want to know one thing: Do GPUs throw CPUs into the water?

[procrypto]

WindMaster, what can be done to make bter remove that stupid warning they have on yac on their site? I'm not tech person and don't have a clue about that but why was yac the only one to get it and s there something it could be done to give them a proof so they can remove it?

I'm sure in good time they will remove it, once we've all been here for a while without losing our wallets or having our bank accounts raided  

For now its probably helping suppress the price, which isn't necessarily a bad thing..



 

[seleme]

Yeah, it certainly stopped the rally but maybe it's not so bad thing, I bought few more   and it didn't went to pump and dump stage like some other coins did what's good thing.

But it does hurt the image of the coin, I'd like to see it removed and if there's something that could be done with the code to make them do it I believe it should be one of the priorities.

[Dehumanizer]

I'm getting the "checkpoint is too old" with the WindMaster's client as well, I have tried to fix it in the checkpoints.cpp but it didn't help...

[Dehumanizer]

I'm getting the "checkpoint is too old" with the WindMaster's client as well, I have tried to fix it in the checkpoints.cpp but it didn't help...

What you mean with "tried to fix it"? Post the code.

as you suggested, I replaced the checkpoint block 15000 with 65000, i.e. this

Code:

( 15000, uint256("0x00000082cab82d04354692fac3b83d19cbe3c3ab4b73610d0e73397545eb012e"))

with this

Code:

( 65000, uint256("0x00000000105c73cd00aa0ba024c6ccd88b738f18bc598f5113470b7491b3df6e"))

then recompiled the client (also tried to make clean before compiling)

[Dehumanizer]

So the 15000 block hash stays there too? I'll try it but it should work with just 65000 as well, shouldn't it?

[ongle]

Its worth noting the official windows client says "WARNING: Checkpoint is too old. Wait for block chain to download or notify developers"

As far as I understand the issue there, it could be fixed by adding hash of some recent block to checkpoints.cpp file at github and compiling new client.

Code:

    // Is the sync-checkpoint too old?
    bool IsSyncCheckpointTooOld(unsigned int nSeconds)
    {
        LOCK(cs_hashSyncCheckpoint);
        // sync-checkpoint should always be accepted block
        assert(mapBlockIndex.count(hashSyncCheckpoint));
        const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
        return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
    }

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

[WindMaster]

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

Yeah, there's probably little point to the checkpoint age test remaining, unless we really want everyone needing to download a new version of the client periodically.  I'll defeat the checkpoint age test and also add a more recent checkpoint to my version of the client today.

[ongle]

What's the point of that checkpoint age test? Wouldn't the blocks eventually get old requiring an update to the hard coded checkpoint list?

Yeah, there's probably little point to the checkpoint age test remaining, unless we really want everyone needing to download a new version of the client periodically.  I'll defeat the checkpoint age test and also add a more recent checkpoint to my version of the client today.

Cool. I could see its value in testing or experimental forks, to keep people from using it beyond its intended use, but we're taking YAC to the moon!

[WindMaster]

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average.

Indeed.  You passed the test to check if you know what you're talking about.  

I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

Oh yeah, I thought I recognized the name mtrlt somewhere.  For anyone in the thread not familiar with scrypt GPU mining history, mtrlt's Reaper was the first (released) OpenCL implementation of scrypt back when everyone claimed scrypt was GPU-resistant.  The kernel in cgminer is just a rip-off of the one in Reaper.

You would indeed be one of the people I'd expect to have modified your own OpenCL code for scrypt+chacha fairly early on.  Anyway, willing to post some hash rate info for your kernel at the current N=128 for a given GPU type and lookup gap (if any)?  You can probably post that info safely without giving anyone a head-start on making the modifications themselves.

Out of curiosity, how many hours after launch or after you started modifying your OpenCL kernel did it take you to make the changes?  Mainly a point of curiosity, for comparison with how many hours it took me.  I went from scratch rather than modifying the Reaper/cgminer kernel though, so my hour comparison will differ a bit because of that.

[efx]

512MB is overkill. A HD6970 has 1536 cores. One hash needing 512MB memory would mean a HD6970 would have to have 768 GB of memory, without a TMTO, which kills performance quite rapidly. I think the N increase should be capped way before 512MB is reached. Maybe 16MB?

Killing hash rate performance rapidly is the goal.  Why would we want to cap the N increase before 512MB is reached?  It'll be reached in the vicinity of 10 years from now, and I suspect no one is going to be bothering with today's 6xxx series Radeon GPU's a decade from now.  In my opinion, the rate of N increasing is actually probably a bit low, and N started at too low a number, if the original developer's intent was to level the playing field between GPU's and CPU's.  Starting N at a level where 512MB is needed to calculate a hash actually would've been an interesting approach right from the start of the coin.

Huh, for some reason I thought N was going up far more rapidly than that. Forgive my bad memory. Anyway, starting N at 512MB memory usage would have resulted in people being able to mine at something like 20 H/s (not tested, only approximately calculated), but I guess it would have been plenty of speed. Verifying blocks would have taken quite a long time though and would have eaten some of your hashrate, but again, it'd probably have been fine.

The same TMTO that works for LTC, works for YAC.

For clarification, are we talking about the TMTO shortcut currently used by cgminer for scrypt+salsa20/8, in which a lookup gap allows you to access external RAM half as often by adding an extra salsa round20/8 to calculate the missing value 50% of the time?

Yes. It works for scrypt, is not dependent on the mixing function, and is even more general than that. You can use any integer lookup_gap, and the memory usage will be 128*N/lookup_gap bytes, and the mixing function will be called 1/2*(lookup_gap+3)*N times, per thread on average. I know this because I actually wrote the LTC kernel used by cgminer, and I also have a working YAC kernel for my own miner, Reaper.

I recognized your name, lol.

I actually still use reaper and assumed it would be first to the gate with acceptable yak hashes.

Are you still involved with RS and SC/ 'microcash' or have you moved on? For hire?


Windmaster, you are tilting at a windmill here imo. Do you honestly want a network based on relatively simple core density and cheap memory? Even IF you could keep it to CPU only (of course, you can't) you are opening yourself up to some ...unfortunate long-term propositions.

Anyways, I'm just watching from the sidelines, I'm not really interested in hashing anything except (1024,1,1) right now  

[8kmode]

for comparison with how many hours it took me.

So, correct me if I am wrong.
It appears that you are taking over development of YAC, and have modified a miner to be able to GPU mine YACoins  while the vast majority of users are only able to CPU mine.

You can probably post that info safely without giving anyone a head-start on making the modifications themselves.

Also appears you don't wish to share that knowledge..?

[WindMaster]

How about adding network hashrate?

Good thought, added to my TODO list.

[WindMaster]

for comparison with how many hours it took me.

So, correct me if I am wrong.
It appears that you are taking over development of YAC, and have modified a miner to be able to GPU mine YACoins  while the vast majority of users are only able to CPU mine.

Read earlier in the thread, I just wrote a non-Reaper/cgminer OpenCL kernel for this hashing algorithm at N=32 and benchmarked it.  I didn't integrate it into a miner.  I instead moved straight to an FPGA implementation instead since N=32 allowed a special opportunity for it to run very quickly on an FPGA implementation.  My GPU's are happily mining Litecoin.  My OpenCL kernel isn't at a stage that would be useful for mining.

To be clear, anyone that wants to screw with modifying Reaper or cgminer's OpenCL kernel is free to do so.  They're open source.  Download it and start hacking away.  I would imagine several people already have and succeeded, but we won't know for sure until everyone starts actually posting code.  Or who knows, maybe mtrlt is the only one who bothered?  We don't know at this point.

Anyway, it's not like I have insider knowledge or some unfair advantage here.  The source code for the scrypt-jane library used by the YAC client is open-source, and the source code for Reaper and cgminer are also open source, and there's even Wikipedia articles that spell out how scrypt and the salsa and chacha mixing functions work in a way that's easy to understand.  If technical skill at writing code is an unfair advantage, mtrlt has most of us beat there (me included) and has made a pretty plausible claim to have a working implementation (if anyone would've done it, mtrlt would have).  Of course, I'm not the original developer of YAC, I'm just the one stepping up to keep things rolling after the original developer went AWOL.  I didn't have any advance knowledge of what hashing algorithm would be used for YAC.  In fact, I slept through the coin launch and didn't become aware of it until 8 hours later, and didn't start mining until another 30 minutes after that after finishing waking up and getting sufficiently caffeinated.  Time will tell if stepping up and continuing to improve YAC just turns me into the YAC lightning rod though.

I suspect people think I have far more YAC than I actually do though.  I've bought more YAC on bter than I've mined, by no small margin.  If everyone is upset they didn't mine a lot of YAC, it doesn't matter because YAC is very inexpensive to buy on bter right now.

You can probably post that info safely without giving anyone a head-start on making the modifications themselves.

Also appears you don't wish to share that knowledge..?

I didn't optimize it, so my hash rates are pretty low.  So here's the dilemma.  Let's say I post a number for my unoptimized implementation, and later the YAC-enabled Reaper is released and it turns out it runs 10x faster.  Plenty of finger-pointing will occur just as happened with ArtForz when mtrlt released the version of Reaper that mined scrypt in Litecoin and the numbers blew ArtForz's (reported) Nvidia-based hash rate numbers out of the water.  We still see controversy over that to this day.

Anyway, at N=32, I benchmarked at ~360kH/sec on a 6950 (not overclocked) without any lookup gap, while my 4-year old IBM HS21 blade servers with 2x Xeon E5450's were cranking about 320kH/sec.  Not real far off of what mtrlt's kernel was doing on the same GPU for scrypt(1024,1,1) for Litecoin with a lookup gap of 2.  I didn't implement any other lookup gap so I have no idea what the % speed advantage is on GPU's for taking advantage of that TMTO shortcut.  And I imagine my hash rate was poor.  As I've said, I made no effort to optimize it beyond get something that would produce valid hashes.  Just wait for mtrlt to release actual real numbers.  If anyone optimized it well, he would've.  So, no finger-pointing if mtrlt achieved some totally ridiculously hash rate completely out of the ballpark of what I did.

That's why my GPU's are mining Litecoin, and a handful of my spare Xeon servers are mining YAC.

[tacotime]

I also have a working YAC kernel for my own miner, Reaper.

Just want to know one thing: Do GPUs throw CPUs into the water?

I told everyone...

[WindMaster]

I'm getting the "checkpoint is too old" with the WindMaster's client as well, I have tried to fix it in the checkpoints.cpp but it didn't help...

I just pushed updates to my git repository to remove the "checkpoint too old" warning (no longer needed, coin is launched and stable), and added checkpoints at 30000, 45000 and 60000.  I'm showing the same block hash at 65000 that other people posted earlier today so we're all on the same blockchain.  For the person that asked why there should be more than one checkpoint rather than just the most recent checkpoint, it speeds up checking of the blockchain in the client.

[mtrlt]

Indeed.  You passed the test to check if you know what you're talking about.  

Crafty. I like your style.

You would indeed be one of the people I'd expect to have modified your own OpenCL code for scrypt+chacha fairly early on.  Anyway, willing to post some hash rate info for your kernel at the current N=128 for a given GPU type and lookup gap (if any)?  You can probably post that info safely without giving anyone a head-start on making the modifications themselves.

The knowledge might give others incentive to do it, but oh well. Currently (N=128) it does 3.4MH/s on a core-underclocked (830->738) HD6990, with lookup_gap at 1, thus no gap. As a curiosity, at N=32, it does 7.3MH/s under the same setup.

Out of curiosity, how many hours after launch or after you started modifying your OpenCL kernel did it take you to make the changes?  Mainly a point of curiosity, for comparison with how many hours it took me.  I went from scratch rather than modifying the Reaper/cgminer kernel though, so my hour comparison will differ a bit because of that.

I was a bit late, I started coding the miner about 16h after the launch. It took me 13.5h from start, to a working implementation. It was very intensive, as you might imagine. Difficulty rising like no tomorrow, and my code only gave errors, until it finally worked. Debugging OpenCL code is horrible. :-)

[WindMaster]

What happens if you leave the code checking if checkpoint is too old? Does "checkpoint too old" warning remains? In other words, is it enough to just add newer checkpoint to list?

Yeah, but only for a while and then the warning will pop up again until more recent checkpoints have been added.  That would require everyone to update and rebuild the client again periodically (at least every 10 days with the way the check is written), which is probably something we'll want to get away from for long-term YAC adoption.  In fact, all the people running the official YAC client are seeing that warning right now, which probably won't be helping the public appearance of YAC (perhaps similar effect to the poorly worded warning on bter?).

My opinion is the check was only necessary during the early stage of the coin launch when the probability was high that someone could 51% it by mining off-network and reintroducing their chain later on, before the network hash rate increased enough to make it expensive to do so.