Bitcoin Forum
August 23, 2017, 07:50:21 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
Author Topic: SolidCoin v2.0 features new hashing algorithm, faster on CPUs  (Read 11623 times)
Littleshop
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
September 20, 2011, 12:39:46 PM
 #81

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. 

1503517821
Hero Member
*
Offline Offline

Posts: 1503517821

View Profile Personal Message (Offline)

Ignore
1503517821
Reply with quote  #2

1503517821
Report to moderator
1503517821
Hero Member
*
Offline Offline

Posts: 1503517821

View Profile Personal Message (Offline)

Ignore
1503517821
Reply with quote  #2

1503517821
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503517821
Hero Member
*
Offline Offline

Posts: 1503517821

View Profile Personal Message (Offline)

Ignore
1503517821
Reply with quote  #2

1503517821
Report to moderator
1503517821
Hero Member
*
Offline Offline

Posts: 1503517821

View Profile Personal Message (Offline)

Ignore
1503517821
Reply with quote  #2

1503517821
Report to moderator
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
September 20, 2011, 07:52:48 PM
 #82

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
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 20, 2011, 08:26:28 PM
 #83

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/
Quote
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.

How often do you get the chance to work on a potentially world-changing project?
k9quaint
Legendary
*
Offline Offline

Activity: 1190



View Profile
September 21, 2011, 01:34:54 AM
 #84

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/
Quote
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. Cheesy

Bitcoin is backed by the full faith and credit of YouTube comments.
2112
Legendary
*
Offline Offline

Activity: 1932



View Profile
September 21, 2011, 03:26:05 AM
 #85

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!

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
2112
Legendary
*
Offline Offline

Activity: 1932



View Profile
September 21, 2011, 05:23:55 AM
 #86

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!

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
2112
Legendary
*
Offline Offline

Activity: 1932



View Profile
September 22, 2011, 05:08:13 AM
 #87

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
johnj
Full Member
***
Offline Offline

Activity: 154


View Profile
September 22, 2011, 05:29:19 AM
 #88

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

1AeW7QK59HvEJwiyMztFH1ubWPSLLKx5ym
TradeHill Referral TH-R120549
titbb
Jr. Member
*
Offline Offline

Activity: 40

PPLNS'ing @ RFCPOOL.com


View Profile
September 22, 2011, 05:29:12 PM
 #89

Imo,

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

I'm PPLNS'ing @ RFCPOOL.com, need more GHashies!
JoelKatz
Legendary
*
Offline Offline

Activity: 1568


Democracy is vulnerable to a 51% attack.


View Profile WWW
September 23, 2011, 03:05:53 AM
 #90

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.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
caston
Hero Member
*****
Offline Offline

Activity: 725



View Profile WWW
September 23, 2011, 02:00:33 PM
 #91

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

18jL18iH96BBhwUCQn27FQp7ocodSxvJAB
worldinacoin
Hero Member
*****
Offline Offline

Activity: 672



View Profile WWW
September 23, 2011, 02:12:55 PM
 #92

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

Activity: 2184


Linux since 1997 RedHat 4


View Profile
September 23, 2011, 02:24:04 PM
 #93

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
caston
Hero Member
*****
Offline Offline

Activity: 725



View Profile WWW
September 23, 2011, 02:46:17 PM
 #94

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.

18jL18iH96BBhwUCQn27FQp7ocodSxvJAB
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
September 23, 2011, 08:42:22 PM
 #95

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
Legendary
*
Offline Offline

Activity: 1568


Democracy is vulnerable to a 51% attack.


View Profile WWW
September 23, 2011, 11:05:23 PM
 #96

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?)

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 24, 2011, 12:09:16 AM
 #97

(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.

How often do you get the chance to work on a potentially world-changing project?
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
September 24, 2011, 12:57:13 AM
 #98

(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
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
September 24, 2011, 02:54:36 AM
 #99


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
Sr. Member
****
Offline Offline

Activity: 252



View Profile
September 24, 2011, 02:59:57 AM
 #100

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).

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.

Try SolidCoin or talk with other SolidCoin supporters here SolidCoin Forums
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!