Even though swapping the crypto layer at runtime is unlikely, function pointers are the more flexible alternative as they allow the developer to choose his crypto layer without having to recompile the bitcoin library.
For any platform where the above would be useful, the following is sufficient: 1) declare the appropriate entry points as "extern"; 2) use the platform's native dynamic linking apparatus. Using additional layer of indirection is completely pointless and has the following disadvantages: 1) it defeats many optimizations that the tool-chain could apply. 2) it defeats many automatic static-analysis and debugging tools. 3) slows down the resulting code (especially if the CPU doesn't have a branch predictor) and increases the energy consumption during execution (more CPU instructions and more cache misses). |
|
|
|
1. So you are saying test my code works on both x86-64 and ppc architectures? Well I'm writing it in C with no dependencies or assembly so no reason why not as long as I follow the usual guidelines for programming portable C code.
What I meant to convey is the following: the Bitcoin protocol itself contains a multitude of design errors related to byte-order and word-alignment. Those errors are compounded by additional errors in the Satoshi client implementation. If you really plan on writing a portable code you'll need to fix those errors in implementation and work around the errors in protocol to maintain the wire compatibility. This is a nontrivial undertaking. If you don't have access to a native big-endian platform like SPARC or z/Arch, then the cheapest way to debug those problem is by working under OS/X. 2. You mean to keep all the components separated? Well this is the plan and I was asking if I should completely separate the cryptography code. With function pointers dependency injection can be done. I'll likely do something like that for threading functionality, without having a dependency on a threading library. I could include the cryptography with the library but it seems it might cause controversy and leaving the cryptography code outside the library satisfies portability and flexibility concerns.
What I meant to convery is the following: the Satoshi client implementation is non-deterministic and non-testable (even while single-threaded) due to to horrible architectural choice of wrapping a stochastic knapsack solver for coin selection and fee calculation inside a control-inverted subroutine that is used in sendtoaddress() API. You'll need to seriously re-architect the API to come up with a deterministic library that will produce deterministic fees with non-trivial wallets. |
|
|
|
Would people be more universally happy if my library required developers using the library to pass cryptographic functionality to the library using function pointers?
Good idea?
No, nobody is planning on swapping the low-level crypto layer at runtime. If you want to abstract it do so using preprocessor macros. I have two other important suggestions for a from-the-scratch implementation: 1) at all times maintain the code as endian-neutral and with proper alignment. If you don't have a Macintosh OSX 10.[456], then build yourself a Hackintosh with Rosetta and test your code using "gcc -arch ppc" 2) resolve the critical inversion of control issue that is present in the Satoshi client. I wrote an post about this a while back. I'll put the link directly to it once I find it. Here they are: https://bitcointalk.org/index.php?topic=44330.msg538044#msg538044https://bitcointalk.org/index.php?topic=55842.msg664634#msg664634Good luck. |
|
|
|
give it to a professional PC board design shop, along with a copy of Altera's best practices for PC board layouts for their Hardcopy devices.
I'm not up to speed on the current best practices. As far as I know they are all centered first on achieving timing closure (propagation/cycle time) with the best time-to-market. There so much emphasis on the proper design of traces as bandwidth-optimal transmission lines that you will have to explicitly ask them to design against their usual objectives. |
|
|
|
How might that change the design thermally and cost-wise?
I don't see the point. Gold is a worse heat conductor that copper. Maybe you meant silver not gold? Either way, I don't know. I only know that one can meaningfully lower the thermal resistance of an FPGA design by connecting as many pins as practical using as big traces as one could fit using the standard copper-on-epoxy low-volume PCBs. |
|
|
|
|
I've seen NIOS mentioned above and this made me to add the following comments:
1) Please don't fall into a trap of synthesizing a CPU onto the same physical chip it will be monitoring. This will be a nightmare when debugging. Ideally the monitoring CPU should be on a separate chip powered from a separate regulator and physically placed away from the chips it is monitoring.
2) The inter-chip communication on the same board should be using as many physical pins as practical. Your design will be thermally limited and physically connecting the pins to traces will allow you to evacuate the additional incremental heat from the chip. You could even create dummy busses and point-to-point connections that are connected physically but not electrically.
3) If you plan on really pushing hard the hasher chips it may be beneficial to have intermediate coding/decoding chip to provide high fan-out/fan-in between the hashing chips and the monitoring/communication CPU. This approach will give you two benefits:
3a) you will know that any hashing failure really occurred in hashing and not in a serdes/comms.
3b) you will be able to separately test and reset all hashing chips on the same board.
Please don't try to save pennies on the copper for the traces. Make the traces as wide and as thick as practical. Counteract the parasitic capacitance of abnormally wide traces with the slow but parallel inter-chip communication.
|
|
|
|
|
Doing floating-point calculations on FPGAs is quite inefficient use of the resources. Therefore most of the numerical modeling software (including Monte Carlo methods) is not easily portable into FPGAs. In order to get sensible FPGA resource utilization you have to rewrite your software to use fixed-point or other specific hardware-efficient representation. This is nontrivial undertaking.
|
|
|
|
Number of DSP48A1s: 30 out of 180 16%
Aha! Interesting. When uncle Moshe (Gavrielov) gives you DSPs, make DSPeade.  |
|
|
|
This thread is very sad. Bitcoin is seriously affected with not-invented-here-itis. I personally started to think that the current milieu here is hopeless. The only hope is that the currently involved software designers fall of the face of the Earth's Internet and get replaced by a new blood. On the other hand I also know that a lot of bright young people read this forum. So for the benefit of the young blood: 1) please learn the difference between binary floating point and decimal floating point. The good starting point is: http://speleotrove.com/decimal/2) please compile this little C program using your recent C compiler: #include <stdio.h>
int main()
{
_Decimal32 x,y;
x = 1.df;
x /= 10.df;
y = x;
y *= 10.df;
printf("%Hf %Hf\n",x,y);
return 0;
} For example: "gcc d.c -ldfp". If you get "library not found for -ldfp" error, then read the following and complain to your software vendor. 3) You became a collateral damage in the mortal combat between IBM and Intel. They are both pushing two incompatible implementations of decimal floating point: IBM's DPD (densely packed decimal) and Intel's BID (binary integer decimal). The libdfp code is out there on the Internet, you'll need to search for it in places that aren't easily accessible to lawyers of the two concerns that I named above. |
|
|
|
That would significantly reduce efficiency not boost it. Skipping nonces means you would on average find half the shares per getwork.
You gain nothing from not checking all nonce values.
Thank you very much for your explanations, gentlemen. I misunderstood the definition of efficiency. I now understand that this parameter isn't that important and pools are mostly interested in it in a statistical average way. |
|
|
|
i really wonder about that 500% efficiency, i'm thinking about making a bounty to anyone who tells me wtf that's all about.
What I wonder is the following: can a pool detect that the device is checking not an every number in the nonce range but instead every n-th number in the nonce range? Instead of doing hashing for 0,1,...,4294967294,4294967295 it would hash only (say) 1,3,...,4294967293,4294967295 or some other similar scheme of skipping through the nonce range? |
|
|
|
By the way, AVNET has its one-day X-FEST (X stands for Xilinx) again this spring (in San Jose on April 26th, check the website for other cities) and typically they offer Xilinx dev boards to attendants at a substantial discount. So, maybe I can pick up a KC705 board for, say, $1400 or so.  Thanks again for the tip. It is quite possible that I will be near Irvine,CA,USA on April 24th, 2012. https://www.weboom.com/avnet2012/ |
|
|
|
Spartan 6s do not include internal temp sensors, unfortunately. The only feedback you really get is from the number of invalids, and I'm not 100% confident that using that is completely bullet proof. It also has the problem that it can take a while to get reasonable feedback on this. At 200 MHz you're getting 1 nonce roughly every 20 seconds it would take 200 seconds to get an invalid (based on 10% invalids). Still, this is a good idea to use as a backup measure. 3 or 4 minutes at an unsafe temperature is a lot better than 3 or 4 hours.
You could interleave normal work with a pre-computed work that will immediately find a valid golden nonce. So the maximum delay for discovering the hashing failure would be about two periods of search. This is usually called "watchdog task" or "continuous self-test". |
|
|
|
|
What do you guys think about this idea? I think its about time to separate those from the general mining categories. The hardware is so intertwined with software in case of all currently available FPGA solutions.
The only big FPGA-related threads that should stay in their current section are (1) the Ufasoft miner thread & (2) CGMINER thread. I think they should stay in software because they are universal CPU&GPU&FPGA mining codes.
|
|
|
|
The KC705 board is now available (well, at least advertised on the Xilinx webpage) and costs $1700.
Thank you for pointing this out. I'm glad I didn't pull the trigger on a ML605 purchase last year. I'll get a KC705 as soon as Avnet shows them as available. Not for the mining though, for fault simulation and mixed-signals experiments. |
|
|
|
I'll be blunt: I think Luke Dashjr fits the definition of a poisonous person,
I don't disagree with the above statement, but I want to offer an alternate explanation. It is the project itself that is poisonous. It wasn't cooked long enough before it was put in a can. While in the can the bacteria producing botulism toxin grew on it. Now whoever eats a bigger portion of it develops various symptoms of neurotoxicity. Luke-Jr is the first to show acute symptoms because he ate a helping large in relation to his body mass. Next time please cook your food projects more thoroughly before canning. Edit: This food in this can could still be saved, but it will require a gamma-radiation sterilization and one-more cooking before it is safe to eat. In other words: refactor the code base before changing the protocol. |
|
|
|
I don't think he did manual placement using his hands and mouse. From my understanding he wrote a Java program that produced Verilog with explicit location constrains as well as a Tcl script that controlled the fpgaeditor to put the finishing touches in signal routing. That one! What is it?
That is "fpgaeditor" from Xilinx ISE. This is actually how FPGA started, if I recall correctly the suite was called X-ACT not ISE. But for sure it wasn't called X-Acto, although it felt like using one. The automatic circuit syntesis was an expensive upgrade. I have no personal experience beyond peeking over coworker's shoulders. |
|
|
|
So if I could get my hands on a 4x hex core server with 256GB of RAM, you FPGA guys would love me long time?
I recall somebody posting a screenshot of a control session for an Amazon EC2 farm containing over 50 machines doing the Xilinx design. I really don't think that using more brute-force would be helpful. The SHA-family of algorithms are very regular and pretty much every bit depends on every bit. This hits a weak spot in the global optimization algorithm used by the FPGA tools. I think that the way forward goes through the use of specialized synthesis tools that don't make generic assumptions about what kind of circuitry is being synthesized. |
|
|
|
My guess is that the number of possible valid transformations overwhelm the synthesis tools and they blow up either on memory usage or time.
I apologize, I'm having problem posting and editing the posts. There just so many logically-equivalent ways to synthesize the SHA-256. For example somebody earlier posted a snippet of his synthesis where he used the adders in the DSP blocks on the Virtex 6 chip. For this to be really beneficial on Spartan 6 chips one has to write a location-dependent Verilog: when near a DSP block use its adder, when far away synthesize the adder using local slice resources. The number of available trade-offs is immense. And thus far I have talked only about synthesis. But the full working design requires two more steps: place and route. This opens another of dimensions that need to be explored for optimization. One guy here on this forum is working on a design where he wrote a Java program to generate a Verilog program that does hashing. The Verilog is all location-constrained to the particular slices. Somebody else posted a code that explicitly uses ternary adders Y = A + B + C. As far as I know Xilinx ISE will always synthesize adder trees Y = (A + B) + C or Y = A + (B + C) or Y = (A + C) + B. On some other site I've found an implementation that pipelines rounds in pairs: 128-way unrolled Bitcoin hash would've had 64-way pipelining. Again, it wasn't for Spartan 6, but some other Xilinx chip. |
|
|
|
|
Show Posts
