 Show Posts
|
|
Pages: « 1 2 3 4 [5] 6 »
|
|
This is a _sensible_ change. We don't need a hundred currency pairs.
|
|
|
|
|
Vircurex has done a very sensible thing. It was getting way too crazy.
|
|
|
|
Let's hope mtrlt either holds on to his GPU kernel like it appears he has to this point, or if released, it's released to all. Anything else risks the stability of the YaCoin network.
This is indeed my plan. |
|
|
|
GPU: HD6990 underclocked from 830/1250 to 738/1250
CPU: WindMaster's 4 year old dual Xeon E5450
Amazon says that's a $1000 card vs a $400 CPU, and Google says it's ~400 Watts vs 80 Watts (just a quick search, these numbers may be off), if anyone wants to calculate corrected ratios. Good point! I'll fix my numbers. ^^ Have you tried playing with the lookup gap more? You should still hit faster GPU performance as by 8192 you will have moved off the CPU cache and are writing to RAM (maybe also L3).
I've played with it quite a bit. Also, nothing helped with 8192, it's all invalids. |
|
|
|
Here are all my GPU benchmarking results, and also the speed ratio of GPUs and CPUs, for good measure. GPU: HD6990 underclocked 830/1250 -> 738/1250, undervolted 1.12V -> 0.96V. assuming 320W power usage CPU: WindMaster's 4 year old dual Xeon, assuming 80W power usage. In reality it's probably more, but newer processors achieve the same performance with less power usage. N GPUspeed CPUspeed GPU/CPU power-efficiency ratio
32 10.02 MH/s 358.8 kH/s 6.98
64 6.985 MH/s 279.2 kH/s 6.25
128 3.949 MH/s 194.0 kH/s 5.1
256 2.004 MH/s 119.2 kH/s 4.2
512 1.060 MH/s 66.96 kH/s 3.95
1024 544.2 kH/s 34.80 kH/s 3.9
2048 278.7 kH/s 18.01 kH/s 3.88
4096 98.5 kH/s 9.077 kH/s 2.72
8192+ 0 H/s 4.595 kH/s 0
GPUs are getting comparatively slower bit by bit, until (as I've stated in an earlier post) at N=8192, GPU mining seems to break altogether. EDIT: Replaced GPU/CPU ratio with a more useful power-efficiency ratio. |
|
|
|
I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.
a) why do you think it stopped working at 8192 (physical GPU limitation with current gen GPUs, or more a limitation of the code that can be more easily overcome)? I don't know yet. It just stops working on its own. b) does CPU mining still work at 8192 and beyond? (if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).
Yes, in fact I tested CPU mining up to N=2^19=524288, where my puny Phenom x6 1055T got around 12 H/s. |
|
|
|
|
I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.
|
|
|
|
I'm mining with GPU now, works great.
Testing it for 2-3 weeks for stability, then release.
How fast is it? Mine is, with N=128, 4MH/s on a core-underclocked (830->738) HD6990. |
|
|
|
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.
I can't believe that hasn't already happened. There was OneCoin, but the developer couldn't figure out how to compile for Windows, and gave up. Also - is the mtrit in this thread famous mtrit or famous original mtrit?
I have trouble parsing this sentence. |
|
|
|
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.
But for what purpose, if we all achieved way shittier hash rates than you did? 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.  |
|
|
|
|
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.
|
|
|
|
How do you feel your YAC GPU kernel performance will hold up off of those adjustments (in absolute terms and in relative terms to a high end CPU)?
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. |
|
|
|
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. :-) |
|
|
|
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. |
|
|
|
On question (a), I doubt 512MB needed to hash is enough to exclude GPU's, especially a decade out
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? The possibility also exists that other technologies other than CPU and GPU options come into existence and widespread application during that timeframe that we can't yet anticipate, or that someone could identify a TMTO shortcut in scrypt+chacha20/8, as happened with the TMTO shortcut for scrypt+salsa20/8 that made GPU's practical for calculating Litecoin hashes.
The same TMTO that works for LTC, works for YAC. |
|
|
|
|
I'd like to help develop Yacoin further. I have C++ experience from 2005, I've made some GPU miners (notably the first open source LTC GPU miner), but not much anything specifically coin-development-related. Do you use IRC?
|
|
|
|
Selling 1k YAC for 25 LTC.
i would like to buy your 1k for 25 ltc - please contact me via PM Trade happily completed, sold 1000 YAC for 25 LTC. Thanks! |
|
|
|
|
Selling 1k YAC for 25 LTC.
|
|
|
|
|
rEZDpphT63A1qPgEWJYXJvpXShmqpUNFSp
|
|
|
|
|
Yes. Stupid. I have to blabber like an idiot to be able to make worthwhile posts.
|
|
|
|
|
