Topic: SolidCoin v2.0 features new hashing algorithm, faster on CPUs - page 4. (Read 12200 times)

That banging you hear in the background is Coinhunter mashing his backspace key.

GPUs suck at accessing main memory.

But they're very, very good at accessing on-board memory.  See, for example (from a couple of years ago)
 http://blog.cudachess.org/2009/07/cpu-vs-cuda-gpu-memory-bandwidth/
I predict it'll take... mmm... 3 weeks after source code is released for the first faster-on-a-GPU solidcoin 2.0 closed-source miner to come out.  8 weeks until there's an open-source one available.

But my predictions are often wrong.

He never stated it's faster. And it likely isn't if the pattern is big enough: GPU's can't access memory nearly as well as CPUs.

We are again still talking about what COULD be possible with the new algorithm.  None of the better ideas are trivial.  Just because coinhunter makes HIS algorithm unfriendly to GPU's does not mean someone will figure out how to RECODE it into something that is quite GPU friendly.  So he can use memory in wasteful ways, but someone else can figure out why it really was not necessary and code it tighter. 

Half of the ideas presented could expose vulnerabilities as well, or at least unforeseen shortcuts that could give some individuals in the know a huge advantage. 

The argument that we still have CPUs instead of GPUs isn't really a good one. ~ two decades ago, all algorithms were faster on Dec Alphas and by quite a margin, not everyone shifted to Alpha workstations...

GPUs have a reputation of being less powerful on some tasks, but I don't buy this argument blindly. For example, GPUs have far more memory bandwidth than CPUs as long as they use local memory (and why shouldn't they : I have 7x more local memory on my rig's GPUs than on its CPU).
I don't think there's any computation it can't do (as long as you have branching, registers for integers and floats even with lower precision and basic math operations on them you should be fine). So you can slow down a GPU thread, but I bet that you can't slow it down *enough* to counteract the sheer number of them. You could make each thread use large amounts of memory to force GPUs to use the PCIE bus but using large amounts of memory is often an implementation detail : you take the risk of someone finding an optimisation trading computing power for memory space and you're toasted.

Not to mention that you'll have to tune the algorithm to work good enough to make running a miner on a used desktop the most attractive solution (so it shouldn't prevent other tasks to run efficiently : not much RAM used, niced CPU threads, ...).

Lets take a look at the advantages listed by the OP :

1) ok a plus, but not so interesting if SolidCoin is the next big thing.
2) don't see how cpu mining gets into that
3) no way you can do that without disturbing other processes or make it GPU friendly

So it seems that this annoucement was just for saying that you can mine SolidCoin while mining BitCoin on your rigs. Not bad, I'll wait and see how CoinHunter makes sure the miner fits in the small amount of RAM left on a rig after the OS is loaded (especially for Windows users) while preventing it from being GPU-friendly... By the way people will appreciate if they can use the 2 or 4 cores of their CPUs (so using what's left of a 1GB stick might not be able to use so much RAM per thread too...).

would a ton of botnets protect the network?

By the way, if you want a good argument to use, it's this: Mining algorithms that work most efficiently on CPUs would tremendously increase the incentive to create bot nets and use malware to mine.

The best counter-argument to that is that we're already starting to see botnets that do GPU mining. But I still think it's a downside.

No. There are two cases. One is mining, the other is validating PoW. In the case of mining, yes, you have to compute many hashes. But it makes no difference how easy or hard that is. If we make it ten times harder, the difficulty will just be ten times less.

The only case where performance matters is validating PoW. That only takes a single hash.

Why is that stupidity? The whole point is to make the mining algorithm difficult. We currently do that by raising the difficulty number, but it's just as reasonable to simply make the algorithm itself difficult to compute. There is no inherent benefit to one method over the other.

The GPU can't deal with the expansion problems. The GPU may have a large number of computation units, but its memory bandwidth is only so high, and it's not optimized for the kind of random accesses the algorithm would require. The reason GPU mining works so absurdly well is because the Bitcoin mining algorithm uses so little memory.

Look, if GPUs could do everything better than CPUs, why would we have CPUs?

You do keep repeating that, but you've yet to form anything resembling an argument. I wonder what you will you say that when some entity makes an ASIC that can mine dozens of times more efficiently than any GPU.

Well you may be able to do a single hash in a 'split second' but the point is to produce a function that can compute many hashes.
And if the resulting function has difficulty doing 1,000 a second because it accesses and processes a large amount of RAM - then that is just plain stupidity.

Also don't forget that the actual process of using memory will not involve transferring it across the PCIe bus.
Unless the block size has suddenly become some totally stupid size and thus the chain takes up ridiculous amounts of disk space, the hash of a block should only require a small amount of memory transfer and then the GPU can deal with the issue of using silly expansion algorithms to generate a large amount of data to hash - though more likely someone would come up with a simplification unless it's done well - note that SC all these ideas you'll need in your paper that you can pretend are yours

Anyway - the bottom line is that wasting that much power on generating a single hash just to attempt (note: attempt - not guarantee) that a GPU cannot do the hash - is as I said before - stupid.

e.g. a 6950 can currently do something like 360 MHash/s on the current algorithm (mine do) and used somewhere under 200Watts of power and costs around $250
To expand this you can add more cards (my MB can take 4x6950 with it's 4 PCIe slots, 2 are 1x and 2 are 16x, and was not at all expensive)
So yeah if someone wants to double/quadruple that middle of the road setup they can with just getting new cards.

Suggesting that people should spend that same amount ($250) on a middle of the road CPU that would also use around 60Watts of power plus the power requirement to have an actual GPU in the computer and use a lot of RAM your really not saving a lot - at BEST maybe a 1/3 of the power
But then to increase performance, you will need a multi-CPU motherboard (expensive and few have them just to get 2 CPU's) or another whole computer.
Then to top it off you can't use the computer easily when it is mining unless you slow mining down to a crawl.

If you GPU mine you can also use the computer and even have VERY little effect on your use
(there are ATI bugs with some versions on window where it will use a whole core in your CPU, but the rest hardly use any CPU - mine uses 2% of a single core with the CPU auto down-clocked to 1200MHz)
With a dual card GPU setup you can actually have mining running at half speed and still have a FULLY functioning computer to use or even play high performance FPS games at the same time.

It just seems ludicrous to even consider and more so is just a waste of a computer to do this.
... and again, if anyone bothers (yeah I don't know if anyone would bother) but if anyone bothers to produce a GPU version of the hash, you suddenly are telling everyone who spent any extra money on whole extra computers so they could hash faster - that they wasted their money - bad luck your hash power is trash.

Bottom line, as I keep saying, its a stupid idea.

Good post.

/ignore CH

How so?
These are quite sound ideas. If you know something wrong with them, do tell.

A CPU can trivially use 128MB for a split-second to validate a block header. Trying to do that on a GPU would slow you down to a crawl -- it doesn't parallelize well because the GPU doesn't have as many memory paths as it has execution units.

There is really nothing complicated about making a mining algorithm that works much better on a CPU than a GPU. After all, the algorithm -- so long as it is concatenated into a hash -- can be anything at all so long as it's deterministic. If all deterministic computing tasks could be done better on GPUs than CPUs, we wouldn't have any CPUs.

Botnet owners will certainly be happy!
Everybody else?  Not so much.

My guess is that the new hashing algorithm will be ROT26. Any GPU that attempts it will run so fast that it melts, leaving only CPU hash power!

But does it run faster than on a CPU of approximately same "price and time range" ?

Great idea. That'll surely never run in OpenCL...

http://vimeo.com/9516301

Conway's Game of Life is an example. There is a lot of memory access and decision making. Although not a cryptographic hash, it is trivial to do
SHA256(SHA256(header) + CGoL(header))
where CGoL is a certain amount of generations of Conway's Game of Life.

Well, there has been some work (in adjacent fields) on types of cryptographic functions that are hostile to pretty much anything but CPUs and verily complex FPGA designs.

Methinks that making something run way worse on any modern GPU than on CPU is definitely possible, though whether CH will succeed in actually ensuring GPU-hostility is something that has yet to be seen.

Ok.  It may be possible.  But possible isn't going to happen in this case.  This is simply not a single threaded type of work.  So even if a GPU is bad at it, it still will be possible to break it up.  Use lots of ram?  Ok, so some (or even 3/4's) of the GPU processing units will be idle, but that will still be many times faster then a CPU.  Floating point?   SC miners will switch to nvidia vs ATI.  The profit motive will break this thing. 

Not necessarily.

There exist numerous tricks and treats that render certain types of hardware relatively inefficient.

It is certainly possible to write a crypto-PoW in a manner that is outright hostile to any modern, and for the immediately foreseeable future, possible, GPU.