Topic: Nexus - Pure SHA3 + CPU/GPU + nPoS + 15 Active Innovations + More to Come - page 316. (Read 785531 times)
October 22, 2014, 03:19:50 AM
Sorry, but I didn't get it - how should we mine on GPU channel? Is there a specific port or...?
October 22, 2014, 03:05:05 AM
GPU CUDA Miner Release
So it appears the extension to the GPU launch will not be possible since someone decided to start mining on that channel. I can't let this one individual rape the channel while nobody gets the benefits, so this is as fair as I can make it. Here are the miners as they stand right now. Keep in mind the difficulty you'll get from getmininginfo will not be correct for this channel, I will release a fix in 1.0.1c.
Windows CUDA Binaries
Windows CUDA Source - This source code needs to be ported for linux.
OpenCL:
I asked Bitslapper to post his source, that will be coming soon.
I wish I could make this more fair, but my hands are tied.
Viz.
So it appears the extension to the GPU launch will not be possible since someone decided to start mining on that channel. I can't let this one individual rape the channel while nobody gets the benefits, so this is as fair as I can make it. Here are the miners as they stand right now. Keep in mind the difficulty you'll get from getmininginfo will not be correct for this channel, I will release a fix in 1.0.1c.
Windows CUDA Binaries
Windows CUDA Source - This source code needs to be ported for linux.
OpenCL:
I asked Bitslapper to post his source, that will be coming soon.
I wish I could make this more fair, but my hands are tied.
Viz.
October 21, 2014, 11:20:08 PM
GPU Launch Extended. Will release the SKMiners this Friday, 10/24/14 @ 12:00 GMT - 7
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
Not sure why that is ironic... CUDA miners are better than OpenCL ~50% of the time. Or is it just ironic because more time was spent on the OpenCL one?
Anyway, glad to see things are going well here.
Irony is that we were short a CUDA miner come last GPU Activation, and now it is the OpenCL lacking
Performance difference was 100x which I'm sure could be improved.
Thank You,
Viz.
October 21, 2014, 05:44:35 PM
GPU Launch Extended. Will release the SKMiners this Friday, 10/24/14 @ 12:00 GMT - 7
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
Not sure why that is ironic... CUDA miners are better than OpenCL ~50% of the time. Or is it just ironic because more time was spent on the OpenCL one?
Anyway, glad to see things are going well here.
October 21, 2014, 01:55:16 PM
Ok friday seems more suitable...
October 21, 2014, 01:35:13 PM
GPU Launch Extended. Will release the SKMiners this Friday, 10/24/14 @ 12:00 GMT - 7
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
The reason for this extension, is that ironically the OpenCL miner is not as efficient as the Cuda miner. More time will be required to get them up to par with each other. This is for the fairest distribution possible.
Thank You,
Viz.
October 21, 2014, 01:22:48 PM
October 21, 2014, 10:14:21 AM
////////////////////////
...
all lib looks good, but probably bad version for one. any idear to solve this on V1.2 mining code?
Best regards
...
all lib looks good, but probably bad version for one. any idear to solve this on V1.2 mining code?
Best regards
In types.h the Timer class should start like this:
class Timer
{
private:
boost::posix_time::ptime TIMER_START, TIMER_END;
bool fStopped;
public:
Timer()
{
fStopped = false;
}
inline void Start() { TIMER_START = boost::posix_time::microsec_clock::local_time(); fStopped = false; }
and in the miner.cpp at the beginning of the MinerThread class should be look like this:
class MinerThread
{
public:
CBlock* BLOCK;
bool fBlockFound, fNewBlock;
LLP::Thread_t THREAD;
boost::mutex MUTEX;
unsigned int nSearches, nPrimes;
MinerThread() : BLOCK(NULL), fBlockFound(false), fNewBlock(true), THREAD(boost::bind(&MinerThread::PrimeMiner, this)) { nSearches = 0; nPrimes = 0; }
Thx, Thx, I solved that quickly
Best
October 21, 2014, 09:13:48 AM
GPU tool where to download?
What time GPU mining?
What time GPU mining?
October 21, 2014, 07:51:59 AM
October 21, 2014, 07:05:45 AM
hi viz, are gpu miners ready for tonight's channel launch?
October 21, 2014, 04:58:58 AM
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize.
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
BUT.... this is not inefficient to parallize and doesn't require much RAM per thread: all threads could work on the same sieve...
The sieve of Eratosthenes is highly parallelizable: just use one different prime per thread. After that, testing the remaining candidates is also a highly parallelizable task.
After all, the PoW has to be a parallelizable thing by nature, since all miners try to solve a block in parallel. So it's hard to make an algo that's more efficiently mined by a CPU than a GPU.
Sure, you are able to parallize the algorithm itself. But you need many memory-accesses...
And yes, you can also try to solve multiple blocks at a time, but here comes the high memory usage (if you wanna find a fair amount of candidates)...
I don't know, how efficient this would be
October 20, 2014, 09:32:05 PM
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize.
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
...
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
BUT.... this is not inefficient to parallize and doesn't require much RAM per thread: all threads could work on the same sieve...
The sieve of Eratosthenes is highly parallelizable: just use one different prime per thread. After that, testing the remaining candidates is also a highly parallelizable task.
After all, the PoW has to be a parallelizable thing by nature, since all miners try to solve a block in parallel. So it's hard to make an algo that's more efficiently mined by a CPU than a GPU.
October 20, 2014, 12:36:45 PM
Hiho,
I followed your discussion here and I also wanna write down some lines:
First things first: I believe, nobody will be able to write an algorithm that can be executed on a CPU but not on a GPU or an ASIC. Why? Because both are only some pieces of silicium
that can do some low-level bitoperations. And both are programmable. So, basically it's useless to declare something as "CPU only". The meaning behind this term is to say "nobody is able to execute this algorithm on a high parallel computer (the GPU) more efficent, than on an sequential computer (the CPU)". And many algorithms out there are only "CPU only", because they make a hugh effort to become ported. (maybe including the seach for primeclusters)
So, what's an argument against a gpu-miner for prime-clusters? The proof that it is posible (or not) worths more than the native belief, that this algorithm is "CPU only". Why? Because this is very important for the belief in the coin. Imagine, what would be, if bitcoin were declared as "CPU only" and nearly nobody ever checked it? thousands of people would mine with a CPU, and maybe one or two hidden with ASICs...
On the other side, if there is a real "CPU only" coin that worth something, what will happen? First, the powercosts are very different from country to country. So, people from countrys with high power-costs arn't able to get in the power-costs (that's also for GPU-miners, but with an eye on the "fairness"...).
The second problem is, that CPU-power is easier and cheaper (in compare with the hardware-costs) to rent than GPU-power. So, some people will rent many servers and the "small miner" will never be able get any coins.
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize. The best way (in my opinion) is to use a high amout of memory per thread. This isn't a problem for CPUs, but for GPUs, where you wanna have hundreds of threads running parallel.
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
So, don't worry, all we do is playing around with this. Our miner will never become "dominating", we are still at a point where mondern CPUs are more efficent. But we wanna take a look, how fast we can become (that is our hobby).
I followed your discussion here and I also wanna write down some lines:
First things first: I believe, nobody will be able to write an algorithm that can be executed on a CPU but not on a GPU or an ASIC. Why? Because both are only some pieces of silicium
that can do some low-level bitoperations. And both are programmable. So, basically it's useless to declare something as "CPU only". The meaning behind this term is to say "nobody is able to execute this algorithm on a high parallel computer (the GPU) more efficent, than on an sequential computer (the CPU)". And many algorithms out there are only "CPU only", because they make a hugh effort to become ported. (maybe including the seach for primeclusters)
So, what's an argument against a gpu-miner for prime-clusters? The proof that it is posible (or not) worths more than the native belief, that this algorithm is "CPU only". Why? Because this is very important for the belief in the coin. Imagine, what would be, if bitcoin were declared as "CPU only" and nearly nobody ever checked it? thousands of people would mine with a CPU, and maybe one or two hidden with ASICs...
On the other side, if there is a real "CPU only" coin that worth something, what will happen? First, the powercosts are very different from country to country. So, people from countrys with high power-costs arn't able to get in the power-costs (that's also for GPU-miners, but with an eye on the "fairness"...).
The second problem is, that CPU-power is easier and cheaper (in compare with the hardware-costs) to rent than GPU-power. So, some people will rent many servers and the "small miner" will never be able get any coins.
So, if a coin developer really wants a "CPU only" coin, what should he do? He should use an algorithm, that is proofed to be inefficent to parallize. The best way (in my opinion) is to use a high amout of memory per thread. This isn't a problem for CPUs, but for GPUs, where you wanna have hundreds of threads running parallel.
As far as I know, searching for primeclusters is only efficent with wheel factorization + sieve of erastosthenes. But the quality of this is bound to the use of much memory. From this point, choosing this proof-of-work isn't a bad idea and GPU-miners will never become nearly such efficient like on sha256 (or similar).
So, don't worry, all we do is playing around with this. Our miner will never become "dominating", we are still at a point where mondern CPUs are more efficent. But we wanna take a look, how fast we can become (that is our hobby).
October 20, 2014, 03:57:43 AM
I would agree with Videlicet's intent to properly (and completely) launch this coin before making hardforks in order to improve on existing features (like a more GPU resistant CPU mining channel).
In particular I'd like to see how the "assimilation" feature of this coin will play out. Will it really be able to eradicate other coins from the markets? What if some whale decides to play games with CoinShield, trying to defend the coins that CoinShield targets for assimilation? This will be fun to observe.
In particular I'd like to see how the "assimilation" feature of this coin will play out. Will it really be able to eradicate other coins from the markets? What if some whale decides to play games with CoinShield, trying to defend the coins that CoinShield targets for assimilation? This will be fun to observe.
October 19, 2014, 11:54:20 PM
so quiet here recently 
October 19, 2014, 05:04:41 PM
Everyone,
Supercomputing is on that as far as I understand [He said by the end of the year]; we are working within the circumstances presented before us. Our plans is to develop a CPU only channel with some GPU developers who will know how to make it deliberately difficulty to build a GPU miner for. This is of course down the line. I said to Supercomputing I am more concerned with getting the GPU Channel Activated before worrying about GPU miners for CPU Channel. Most likely the course that is going to become final is the Hashing Channel being the ASIC, Prime Channel being GPU, and new CPU channel being CPU only. I want with my efforts and others combined to be able to develop a stable CPU channel so that the little miners can eat too; my goal is to make it as fair as possible, but possible here is a very strong word.
Thank You,
Viz.
Supercomputing is on that as far as I understand [He said by the end of the year]; we are working within the circumstances presented before us. Our plans is to develop a CPU only channel with some GPU developers who will know how to make it deliberately difficulty to build a GPU miner for. This is of course down the line. I said to Supercomputing I am more concerned with getting the GPU Channel Activated before worrying about GPU miners for CPU Channel. Most likely the course that is going to become final is the Hashing Channel being the ASIC, Prime Channel being GPU, and new CPU channel being CPU only. I want with my efforts and others combined to be able to develop a stable CPU channel so that the little miners can eat too; my goal is to make it as fair as possible, but possible here is a very strong word.
Thank You,
Viz.
October 19, 2014, 01:59:14 PM
Quote from: vedran82
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version.
Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all.
It doesn't matter if it is you or someone else, although I admire your work. You didn't get me. Supercomputing asked Viz in this thread should he make GPU miner for CPU channel. Viz posted that he wants this to remain CPU only. So I am asking him how fair would it be when he knows that multiple devs already use GPU miner.
EDIT: and of course, like I told before, I think you have to be payed for your time and knowledge, it just not fair from coin devs side not to allow public GPU miner. Personally, I'm fine with this too.
October 19, 2014, 01:51:44 PM
Quote from: vedran82
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version.
Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all.
personally i find you guys inspiring, I've even started trying to code again!!
October 19, 2014, 08:48:02 AM
Quote from: vedran82
Do you still plan on not letting one dev, who asked you here, to develop open source GPU miner for CPU channel, while we all know that other developers already have GPU miner?
It's two developers, ChrisH (Chris84 on bitcointalk) and cbuchner1 - The C&C hash factory. I'd bet Mr. Supercomputing is also working on an OpenCL Version.
Power efficiency wise our miner isn't better than a couple of good Intel CPUs. The compute density is higher - needs less (consumer grade) mainboards for same performance. If you don't like what we do, write your own miner or improve the existing CPU miner... Mining is a competitive sports after all.
Jump to: