I would love to volunteer to be a beta tester. Cheers!
Hi just keep an eye on the official forum or IRC channel for the public beta testnet. Although I will likely also post about it here (no guarantees though).
Topic: SolidCoin v2.0 features new hashing algorithm, faster on CPUs - page 3. (Read 12200 times)
September 24, 2011, 02:18:24 AM
Hi just keep an eye on the official forum or IRC channel for the public beta testnet. Although I will likely also post about it here (no guarantees though).
September 24, 2011, 02:17:15 AM
(If there was nothing CPUs do best, why would be using them?)
Sure, CPUs do all sorts of things better than GPUs. CPUs are great at managing interrupts from multiple devices like USB, PCI, etc. CPUs are great at managing memory spaces, protecting system resources from other threads of execution. And so on. None of those have anything to do with hashing algorithms that make the blockchain secure.The beauty of the Bitcoin hashing system is the asymetric nature combined with robust security. Incredible amount of computing power to find a hash, but trivial to verify the hash. I suspect that this new SC "design" is going to mess it up.
The final hash of the SC2.0 system is a SHA256. This means the security is the same as in Bitcoin, it's just done differently to get there. The reason why I decided to stick with SHA256 as the final hash is it's known to work well as a difficulty modifier. So I'm not quite sure what you're talking about in regards to "Security". The worst case if my new "algorithm" is broken is a faster way to generate hashes. Making hashes faster does not equal a broken system, or Bitcoin could be considered broken since a modern CPU can do nearly 2 million hashes per second.
A modern CPU can do 20000-35000 SC2.0 hashes per second per core. No node is receiving that many blocks to verify a second.
September 24, 2011, 12:30:55 AM
I would love to volunteer to be a beta tester. Cheers!
September 24, 2011, 12:12:53 AM
(If there was nothing CPUs do best, why would be using them?)
Sure, CPUs do all sorts of things better than GPUs. CPUs are great at managing interrupts from multiple devices like USB, PCI, etc. CPUs are great at managing memory spaces, protecting system resources from other threads of execution. And so on. None of those have anything to do with hashing algorithms that make the blockchain secure.The beauty of the Bitcoin hashing system is the asymetric nature combined with robust security. Incredible amount of computing power to find a hash, but trivial to verify the hash. I suspect that this new SC "design" is going to mess it up.
September 23, 2011, 09:59:57 PM
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.
Quote
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).
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.
September 23, 2011, 09:54:36 PM
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.
September 23, 2011, 07:57:13 PM
(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.
September 23, 2011, 07:09:16 PM
(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.
September 23, 2011, 06:05:23 PM
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?) September 23, 2011, 03:42:22 PM
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.
September 23, 2011, 09:46:17 AM
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.
September 23, 2011, 09:24:04 AM
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. September 23, 2011, 09:12:55 AM
Wonder when can we start the new Solidcoin mining on CPUs? Would love to make full use of my excess inventories 
September 23, 2011, 09:00:33 AM
I predict someone will use FPGA's to mine solidcoin 2.0 and get faster than CPU hashing.
September 22, 2011, 10:05:53 PM
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.But my predictions are often wrong.
September 22, 2011, 12:29:12 PM
Imo,
if people are stupid enough to go mine ShittyCoins again, they deserve to be scammed ...
if people are stupid enough to go mine ShittyCoins again, they deserve to be scammed ...
September 22, 2011, 12:29:19 AM
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
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
September 22, 2011, 12:08:13 AM
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.
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.
September 21, 2011, 12:23:55 AM
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!
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!
September 20, 2011, 10:26:05 PM
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!
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!
Jump to: