SolidCoin v2.0 features new hashing algorithm, faster on CPUs

[Littleshop]

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. 

[dree12]

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

http://vimeo.com/9516301

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.

[Gavin Andresen]

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.

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/

CUDA-enabled GPU offers up to 8X the speed of main memory and 4X the speed of L1-cache compared to a moderne CPU...

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.

[k9quaint]

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.

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/

CUDA-enabled GPU offers up to 8X the speed of main memory and 4X the speed of L1-cache compared to a moderne CPU...

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.

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

[2112]

Hi SolidCoin developers!

Take the Gavin Andresen challenge.

Your weapon against OpenCL will be recursion. Implement something along the suggestions of JoelKatz where MESS() is a highly recursive function. I don't have my textbooks of the computability theory anywhere near, but I would suggest to start your search for an appropriate candidate with:

http://en.wikipedia.org/wiki/Ackermann_function

In the worst case the OpenCL vendors will come up with greatly improved implementations.

Good luck!

[2112]

Hi again, SolidCoin developers!

After a dinner I came up with another two ideas:

1) Instead of evaluating a total recursive function over a commutative ring of integers you could try a simpler thing. Require evaluating a specific value of primitive recursive function over the field of reals that has fractional dimension. Good starting example:

http://en.wikipedia.org/wiki/Logistic_map

just pick the value of r that is in the chaotic region.

Implement reals as long double that is 80-bit (10-bytes) on the Intel/AMD CPUs. Not all the C++ compilers really support long double, but the logistic map function is so trivial that you can include in-line assembly which will be in the order of 10 lines.

2) This is a variant of the above that embraces the enemy instead of fighting it. Implement (1) with reals as cl_double which is supported in OpenCL by NVidia cards but not by AMD cards. Then short AMD stock and go long NVDA for additiona gains.

Again, good luck!

[2112]

I was hoping that someone will critique (or at least criticize) my suggestions. In any case I'm going to try to poke holes in my own arguments:

1) Find how OpenCL deals with recursion manually converted to iterations with continuations and explicit stack.
2) I recall that during Pentium processor recall somebody posted bit-by-bit accurate implementation of Intel floating point in Mathematica, complete with a flag to simulate the Pentium flaw. I'll see if I can port that to OpenCL.

I need to learn a bit of OpenCL and experience its strengths and limitations first hand.

[johnj]

Hmmm

I'm kinda curious (honestly) if this could run SC 2.0

Guy made a working cpu in Minecraft.  Another video of a 16-bit ALU is out there too.

http://www.youtube.com/watch?v=7sNge0Ywz-M

[titbb]

Imo,

if people are stupid enough to go mine ShittyCoins again, they deserve to be scammed ...

[JoelKatz]

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.

There's a good chance you're right. While it's trivial in theory, it's quite difficult in practice. It's in many ways analogous to coming up with a secure encryption algorithm, but more difficult.

[caston]

I predict someone will use FPGA's to mine solidcoin 2.0  and get faster than CPU hashing.

[worldinacoin]

Wonder when can we start the new Solidcoin mining on CPUs?  Would love to make full use of my excess inventories

[kano]

I predict someone will use FPGA's to mine solidcoin 2.0  and get faster than CPU hashing.

Doubt it, no one would waste that much money on a short term chain.

[caston]

I predict someone will use FPGA's to mine solidcoin 2.0  and get faster than CPU hashing.

Doubt it, no one would waste that much money on a short term chain.

If they had an FPGA already it wouldn't be a waste of money and 100 megahash would be god-like in the land of the CPUs.

[dree12]

I predict someone will use FPGA's to mine solidcoin 2.0  and get faster than CPU hashing.

Doubt it, no one would waste that much money on a short term chain.

If they had an FPGA already it wouldn't be a waste of money and 100 megahash would be god-like in the land of the CPUs.

My 2 core CPUs ran at 17kHps at peak.

[JoelKatz]

If they had an FPGA already it wouldn't be a waste of money and 100 megahash would be god-like in the land of the CPUs.

An FPGA couldn't run a memory-hard algorithm at those kinds of speeds. If this is done right, you carefully design the algorithm so that a CPU is the ideal platform to implement it on. That is, you specifically design it around the things that CPUs do best. (If there was nothing CPUs do best, why would be using them?)

[Gavin Andresen]

(If there was nothing CPUs do best, why would be using them?)

Well, CPUs are easy-to-program general purpose hardware that can do lots of things (and several things at the same time, in these days of multicore CPUs) pretty darn fast.

GPUs are hard-to-program more-specialized hardware. These days they can do pretty much any raw calculation a CPU can do, faster-- it just takes a lot more effort on the programmer's part to figure out how. That extra effort is only worthwhile for the most performance-critical code.

When I worked at Silicon Graphics I saw several interesting algorithms implemented using OpenGL operations reading and writing to texture memory and/or the accumulation buffer and/or the framebuffer. That was before OpenCL and GPU programming languages, but the experience gave me a lot of respect for the ability of good programmers to look at problems sideways and come up with ... interesting ... solutions.

[dree12]

(If there was nothing CPUs do best, why would be using them?)

Well, CPUs are easy-to-program general purpose hardware that can do lots of things (and several things at the same time, in these days of multicore CPUs) pretty darn fast.

GPUs are hard-to-program more-specialized hardware. These days they can do pretty much any raw calculation a CPU can do, faster-- it just takes a lot more effort on the programmer's part to figure out how. That extra effort is only worthwhile for the most performance-critical code.

When I worked at Silicon Graphics I saw several interesting algorithms implemented using OpenGL operations reading and writing to texture memory and/or the accumulation buffer and/or the framebuffer. That was before OpenCL and GPU programming languages, but the experience gave me a lot of respect for the ability of good programmers to look at problems sideways and come up with ... interesting ... solutions.

No. GPUs are faster at parallelizing things, but if I told you to do a long, state-dependent task (modelling weather, for example) CPUs would excel.

[Littleshop]

No. GPUs are faster at parallelizing things, but if I told you to do a long, state-dependent task (modelling weather, for example) CPUs would excel.

There seems to be an ongoing misunderstanding of what is possible with GPU computing.  Weather modeling is a GREAT GPU application.

http://www.vizworld.com/2010/03/weather-modeling-80x-faster-gpu/

Not everything does well on a GPU, but tasks that can be broken apart and rely on a small data source are usually GPU candidates.  Even large data sets are fine if all of the processors can look at the same data.   With almost any sort of mining you are working with a small data and all of the work is done on the same data for a while.  I fail to see what can be done to alter mining that will make it WORSE on a gpu.  It may not accelerate as well, but once someone smart does the work, it will accelerate. 

All of this work to try to de-gpu the mining process actually makes the end product less secure by making botnets the new problem.  Even if it works, you are trading one (known issue) with a worse unknown one. 

[CoinHunter]

When I worked at Silicon Graphics I saw several interesting algorithms implemented using OpenGL operations reading and writing to texture memory and/or the accumulation buffer and/or the framebuffer. That was before OpenCL and GPU programming languages, but the experience gave me a lot of respect for the ability of good programmers to look at problems sideways and come up with ... interesting ... solutions.

It's a bit different when you design something which goes against what good GPU programming practices are. The latency for video cards for instance is relatively large compared to CPU.

2.4 CPU Has Larger Cache and Lower Latency than GPGPU

T7500 has 32K L1 and 256K L2 per compute unit and 4M unified L3 while C2050 has 16K L1 per compute unit and 768K unified L2, which means that CPU is more lenient to the requirement on spatial locality than GPGPU and also has lower memory access latency than GPGPU.
However GPGPU is optimized for high-throughput by hiding the latency for memory access and other instructions through fast context switching to ready threads in the scheduling queue, which assumes, in addition to there being a large number of in-flight thread, the number of arithmetic operations per memory operation is also high (Imagine if you only perform one arithmetic per memory load, context switching doesn’t make much sense).

Read more here

I'm surprised as a seasoned developer you are unaware of such things. If you want to take an existing algorithm and optimize it for GPU then it's a different story, most things aren't designed to execute 100% in linear order with low latency, so you can break the problem into many. Not so with SolidCoin 2.0

Like JoelKatz said, if GPU could do everything as well as a CPU can we would have no reason for a CPU and we'd be running OSes on a GPU.