byuu's message board

For discussion of projects related to www.byuu.org/


1, 2  Next
$23k Drakon-level assembled Bitcoin miner that barely works 
Author Message
User avatar

Joined: Tue 13 Sep 2011, 14:54:16

Posts: 779
Post $23k Drakon-level assembled Bitcoin miner that barely works
http://buttcoin.org/butterfly-labs-mini ... ce-of-shit

_________________
Why does Link's uncles house have only one bed if they live together?

Fri 06 Dec 2013, 09:40:06

Joined: Fri 03 May 2013, 06:51:50

Posts: 410
Location: NJ
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
1. I've been in love that site ever since kode posted a link to it in an earlier forum post... it makes me feel better about myself when I'm having a bad day- "it could be worse, I could've invested in bitcoins!"

2. You really love Drakon, don't you XD?

_________________
"It wouldn't be a byuu.org forum thread if the thread topic didn't derail at least once."- Some byuu.org forum member
"Clearly the answer to [cross platform portability] is to write a DOS application and then everybody can run DOSBox. Except for [cr1901], who can run it natively."- Screwtape

Fri 06 Dec 2013, 12:56:13
User avatar

Joined: Tue 13 Sep 2011, 14:54:16

Posts: 779
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
cr1901 wrote:
1. I've been in love that site ever since kode posted a link to it in an earlier forum post... it makes me feel better about myself when I'm having a bad day- "it could be worse, I could've invested in bitcoins!"

2. You really love Drakon, don't you XD?



1. It's not that I don't like the idea of cutting the state out of my transactions. It's a great idea. I just hate the Bitcoin Foundation and a lot of the crazies on BTforums. Also, BTC is being pumped up by hedge funds and the FBI. Wouldn't be the first time merchantilists and the feds have worked together to fuck up something nice.

2. Like Drakons RGB work, I refuse to pay exorbident amounts of money for shoddy EE work. It's not like it has to be assembeled by Dave from EEV Blog, but for that amount of money I do expect a modicum of professionalism. That mining rig is a fire hazard and I'm surprised it hasn't burned something down.

_________________
Why does Link's uncles house have only one bed if they live together?

Sat 07 Dec 2013, 00:56:25

Joined: Fri 03 May 2013, 06:51:50

Posts: 410
Location: NJ
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
vxbinaca wrote:
I refuse to pay exorbident amounts of money for shoddy EE work.

I sure as hell don't use hot-glue, but I'm a big fan of electrical tape in the absence of shrink tubing and a heat gun (which is quite often). But then again, I don't think I'd ever do mods for other people...

Hell, the only PCB design I've made that I'm considering selling (a keyboard protocol converter)- people who want to make their enclosure are on their own... I simply don't have the tools, money, and time to make one of my own.

Also regarding Dave- I really do love his stuff, I really do. But sometimes I feel like he doesn't realize that not every EE makes a shitton of money. Also, as an aside, his comments on "relying on compiler optimizations to take care of everything for you, and use non-portable compiler extensions for those critical subroutines that must be written in ASM" really pissed me off.

_________________
"It wouldn't be a byuu.org forum thread if the thread topic didn't derail at least once."- Some byuu.org forum member
"Clearly the answer to [cross platform portability] is to write a DOS application and then everybody can run DOSBox. Except for [cr1901], who can run it natively."- Screwtape

Sat 07 Dec 2013, 02:47:47

Joined: Thu 05 Aug 2010, 18:46:09

Posts: 138
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
For $23k I'd expect proper packaging. Anyways, seeing how we're dealing with damaged goods here, I don't really care too much about the rest of the review, who knows what else broke besides just the case... Of course the work per joule ratio would still be far worse than expected (I'm reluctant to use "promise", since... did they, really?) even if everything were in working order, but that's what you get for trusting a startup company with no reputation whatsoever.

cr1901 wrote:
Also, as an aside, his comments on "relying on compiler optimizations to take care of everything for you, and use non-portable compiler extensions for those critical subroutines that must be written in ASM" really pissed me off.

I found I usually agree with him (though he has a tendency to go a bit over the top occasinally)... Was he pro or contra? Can't really tell from your comment. I don't mean to derail this thread, so could you just give me a pointer towards that video/post please?

Sat 07 Dec 2013, 11:48:34

Joined: Fri 03 May 2013, 06:51:50

Posts: 410
Location: NJ
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works

He's against using it except using compiler-specific (presumably GNU-specific) extensions for performance critical routines. Contrast to actually learning the assembler, linking assembly and C modules together, and learning the calling convention/ABI, etc.

We are breeding a generation of programmers where only the compiler writers are the people who TRULY have to know an architecture inside and out.

One thing on my bucket list is to write a small retargetable C compiler- ya know, because there aren't 100 of those already.

_________________
"It wouldn't be a byuu.org forum thread if the thread topic didn't derail at least once."- Some byuu.org forum member
"Clearly the answer to [cross platform portability] is to write a DOS application and then everybody can run DOSBox. Except for [cr1901], who can run it natively."- Screwtape

Sat 07 Dec 2013, 12:11:31

Joined: Tue 21 Feb 2012, 05:42:15

Posts: 2564
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
Just to be clear, buttcoin is a highly biased site. There is definitely truth in there, but sometimes they're outrageously dramatic and say dumb shit that makes no sense. Even as someone that only follows bitcoin loosley and has 0 investment, I can tell they have gained selective hearing. Not that I blame them - if you're going to run a website with an anti-"thing" rhetoric you might as well go the whole 9 yards and rake in the most ad money.

That being said, I'm in no way claiming this piece of shit machine is any less bad than they're saying. I have no idea why people would think now is a good time to start bitcoin mining - the complexity to mine will eventually trump the energy requirement and initial investment, and at that point you still need to hope the bitcoin market reacts favorably to your timing. I'm thinking this last crash might be the last one before stabilization or stagnation, though that's what everyone thought about every other bitcoin crash.

cr1901 wrote:
We are breeding a generation of programmers where only the compiler writers are the people who TRULY have to know an architecture inside and out.

I doubt that's the case. It is incredibly common for programmers to want to look at the outputted assembly code - just search for how to do so on Stack Overflow. With that being said, part of the problem is that computer architecture is currently in a rapid state of flux. A lot of optimizations that worked half a decade ago are now Terrible in terms of performance, at least on the Intel architecture. Vectorization intrinsics are not really an issue since that is just a thin layer around what the processor actually does anyway - it's better than error-prone asm blocks, where you have to tell the compiler some of your intentions or run the risk of degrading performance or creating unexpected bugs. People are still using assembly for size optimization because it is still effective for size optimization. But for performance on modern architectures with modern workloads, letting the compiler optimize is pretty much a win-win, because it lets you keep your code freer of hacks or highly platform-specific code.

If CPU architecture designers are designing their architectures to work better with C++ compilers, then that's that. Developers are just doing what they're intended to do. Give them an ARM chip and some tight performance requirements and they'll have no problems adjusting.

_________________
"It's easy to win forgiveness for being wrong; being right is what gets you into real trouble." --Bjarne Stroustrup

Sat 07 Dec 2013, 14:09:35

Joined: Thu 05 Aug 2010, 18:46:09

Posts: 138
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
Understanding assembly can be very, very helpful, but writing it - outside of maybe the odd short inline block - should not be necessary these days. Most of the time the compiler will give you equal or better output. Also, I don't think the compiler devs actually know that much more about a given CPU than an asm coder - all they need is a set of available instructions and their associated costs and side effects. They plug that into the compiler framework, and the actual magic is done by optimization algorithms - much better than any human could.

If you at any point think "I should write this in assembly", at least 95% of the time you a) are just plain wrong or b) should rather teach your optimization to the compiler, so everyone can benefit. Another upside to going with "b)" is that if an optimization only works for CPU "x", it doesn't get applied when building for "y". Yes, there might be cases when your compiler generates suboptimal code - but if it does, just do "b)".


Regarding compiler specific extensions: If Dave mentioned them I must've missed it. IMHO if it's not a public codebase and you know you'll stick with a certain compiler for some time, by all means go ahead with a bit of vendor lock-in, if it saves you some time it might very well be worth it - but keep in mind it's going to cost you extra if you're going to switch later. I can't stand seeing them in open source projects though (that reminds me, I keep forgetting to monitor the progress of how the project that tries to make the Linux kernel buildable with compilers that aren't gcc...), since you can't know what compilers your users might prefer or even have available.

Sat 07 Dec 2013, 15:24:45

Joined: Sat 18 Apr 2009, 16:06:52

Posts: 2208
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
jchadwick wrote:
A lot of optimizations that worked half a decade ago are now Terrible in terms of performance, at least on the Intel architecture.


What optimizations that worked on Nehalem (5 years ago) are terrible in terms of performance on Haswell (today)??

The biggest disturbance from Intel was Netburst, which had an awful lot of "don't do that" with respect to x86 code. But since then uarch changes have generally not changed how things should be optimized a lot. It was one of the unusual cases where the CPU really took a lot of hits with legacy code. Other than that, an optimization you perform today will usually not be this big speed hit on uarchs tomorrow; it could be less ideal, but that tends to be balanced by that newer CPU being more efficient; those optimizations are more valuable today if your code needed optimization to begin with (and yes, most probably doesn't)

greggetra wrote:
Understanding assembly can be very, very helpful, but writing it - outside of maybe the odd short inline block - should not be necessary these days. Most of the time the compiler will give you equal or better output. Also, I don't think the compiler devs actually know that much more about a given CPU than an asm coder - all they need is a set of available instructions and their associated costs and side effects. They plug that into the compiler framework, and the actual magic is done by optimization algorithms - much better than any human could.

If you at any point think "I should write this in assembly", at least 95% of the time you a) are just plain wrong or b) should rather teach your optimization to the compiler, so everyone can benefit. Another upside to going with "b)" is that if an optimization only works for CPU "x", it doesn't get applied when building for "y". Yes, there might be cases when your compiler generates suboptimal code - but if it does, just do "b)".


Basically, "your compiler sucks at vectorization, so the only sensible option is to teach it how to be great at vectorization." You have a very simplistic idea of what assembly-level optimizations are like. (Yes, intrinsics are an alternative to poor vectorization, but they're not always perfect, and I consider them at least partway like assembly code)

One thing people don't think about it when comes to assembly programming is that you're not just replacing part of a one way transformation but you're extending the range of a closed loop process. When you start coding something in assembly you will at least occasionally realize that your algorithm has weaknesses that weren't apparent at a higher level, and you will modify the algorithm the accommodate. The compiler can't do this. You might get this impression from reading compiler output, but that's a lot less legible than human written assembly.

I think the people who make these sort of comments are almost never the people writing the most efficient code...

Sat 07 Dec 2013, 19:12:54

Joined: Thu 05 Aug 2010, 18:46:09

Posts: 138
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
There's always a tradeoff between efficiency and portability, but I'm with Moore on this one and usually err on the side of portability.


For the last few month I've been working with people that do indeed write very efficient code that deals with floating point numbers. Want to know how they do it? No error checking. At all. Anywhere. Instead, they catch FPU exceptions (to the OO people: no, this is not the kind of exception you think it is! Would have been nice, but no...), look at the CPU state, emulate whatever behavior they want for the error that's occured ("division by zero? meh, let's just return infinity. close enough."), then increase the PC and continue. This part is all assembly, that's why I bring it up. A developer that doesn't have an asm fetish likely wouldn't have thought of this.

Anyways, that was OK as long as everything was on a MIPS. Nice short set of instructions, and all of the same length. I haven't had to look into the related part of the code yet, but I've been told it's basically a switch-case block.

Now it's been moved on over to x86_64, which has a lot more relevant instructions, which vary in length, and can apparently be prefixed, changing the behavior. Until today they haven't had a single idea how to solve that, short of some insubstantial "isn't there some disassembler library we could use?" whining. Did I mention that afaik, the system should've gone to final testing some weeks ago, and we don't even have a working prototype (or rather, err... "protoport"?) yet?

I don't even want to know what each line of the new error handler, should it ever see the light of day, will have cost. And with the rather low number of units they're moving, it's a good thing the customers are used to paying through the nose. Every time you (over-)optimize by relying on details specific to your current platform, you have to be aware of any potential costs that might occur if any part of your environment changes.
(Oh, and note how in this example we've moved from a rather basic CPU to one with more advanced features here. You'd expect to run into problems problems like missing features when moving "downwards", but there's lots of problems in other "directions" too.)


For practical purposes, when speeding up code I found it's usually a good idea to have two versions, one "optimal" and one "correct", and occasionally switch between them while testing. If your optimal implementation can't coexist with the correct one, it's a strong indicator your concept is f*cked.

Sat 07 Dec 2013, 20:12:57

Joined: Tue 21 Feb 2012, 05:42:15

Posts: 2564
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
Well, I assume most people optimize things when they realize there is a need to. But it's not really about having an 'asm fetish.' You can love asm, but if you don't keep up with your platform you might as well not bother.

I always found details like the performance of denormalized floating point numbers to be both incredibly interesting and incredibly obscure, and that's one of the more broad behaviors..

_________________
"It's easy to win forgiveness for being wrong; being right is what gets you into real trouble." --Bjarne Stroustrup

Sat 07 Dec 2013, 22:01:25

Joined: Thu 19 Nov 2009, 16:18:55

Posts: 1586
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
As a current owner of a bitcoin mining appliance, I may be a bit biased, but one thing BTC-haters forget (or don't even think of) is that not everyone wants BTC to convert them into USD/filthy fiat. As they've all stated many times, the cash-out process is tedious, unstable and full of crooks on both sides of the transaction. If I want BTC to actually spend them as BTC--for things like VPN hosting, usenet access, donating to hipster e-causes, etc. where the pseudo-anonymity brings its own value to the equation--mining is an effective way to procure them without dealing with said crooks and/or having to save up a ton of money to buy whole coins (because no one wants to sell you 0.002 BTC; of course, you have to buy the miner, but I imagine you can get one for peanuts once they drop out of profitability vs electricity).

_________________
My Emulator Repo for Debian/Ubuntu/Mint/etc (includes bsnes, Retroarch, libretro, VBA, Nestopia, Dolphin)

Sat 07 Dec 2013, 22:43:15

Joined: Thu 05 Aug 2010, 18:46:09

Posts: 138
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
I mined a bit back when GPUs were still somewhat profitable, but have since moved on to just buying a couple BTC whenever they seemed cheap, then trading with them. And while I can see why people are still interested in mining, personally I don't want to be part of a continuous arms race of devices, all of which are provided (or not, at their discretion...) by a handful of seemingly rather shady sellers.

hunterk wrote:
I imagine you can get one for peanuts once they drop out of profitability vs electricity).

At that point, why would you still want one? That'd only make sense if you have access to free electricity, and in that case you could also buy a bunch of used Radeon cards instead, right now. Some medium-speed GPU mining starting now will probably be more profitable in the long run than high-speed ASIC mining a year down the line, not to mention by then the ASICs will probably also be rather slow (relative to the rest of the net).

Regarding the crookery, I don't know what markets, forums or exchanges you've been to, exactly, but I don't think it's as bad as you make it sound. None of my transactions (only around ten as far as I can recall, but still...) gave me any problems whatsoever.

Sun 08 Dec 2013, 01:38:16

Joined: Thu 19 Nov 2009, 16:18:55

Posts: 1586
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
greggetra wrote:
At that point, why would you still want one?
Because it would still just be a small premium to not have to deal with other people. How much one values that convenience/anonymity determines how far into 'unprofitable' one would be willing to mine.
greggetra wrote:
Some medium-speed GPU mining now will probably be more profitable in the long run than high-speed ASIC mining a year down the line, not to mention by then the ASICs will probably also be rather slow then (in relation to the rest of the net).
I'm not sure I follow your logic here. For one thing, GPUs actually have other uses (e.g., computer games), which keeps the price for hardware above a certain minimum. FPGAs are/were in the same boat, since they're reprogrammable.

In contrast, an ASIC, by definition, has only one purpose and will be essentially useless once it drops out of profitability, unless you're willing to accept the aforementioned premium, which means they will likely plummet in cost (admittedly, I have nothing to back this up, just idle supposition). For the miner I have, the difficulty will have to increase by 100x (probably at least 6 more months based on historical difficulty changes) before it's as unprofitable (that is, an additional cost in electricity of approx. 50% beyond the BTC value it earns) as a good GPU is currently.

I don't know what the theoretical maximum mining speed of ASICs is vs the maximum number of mine-able bitcoins, but I guess the difficulty could eventually be such that *no* device is profitable and the only people still mining either don't care about the price of electricity (i.e., idiots and criminals) or they value the anonymity so much that no premium is too high (again, idiots and criminals).
greggetra wrote:
Regarding the crookery, I don't know what markets, forums or exchanges you've been to, exactly, but I don't think it's as bad as you make it sound. None of my transactions (only around ten as far as I can recall, but still...) gave me any problems whatsoever.
You're right, it's probably much safer than people make it out to be. I haven't had any problems in my handful of interactions, either. The way haters like Buttcoins make it sound, though, the entire market is just a bunch of people trying to fuck each other over.

_________________
My Emulator Repo for Debian/Ubuntu/Mint/etc (includes bsnes, Retroarch, libretro, VBA, Nestopia, Dolphin)

Sun 08 Dec 2013, 02:26:16

Joined: Thu 05 Aug 2010, 18:46:09

Posts: 138
Post Re: $23k Drakon-level assembled Bitcoin miner that barely works
hunterk wrote:
I don't know what the theoretical maximum mining speed of ASICs is vs the maximum number of mine-able bitcoins, but I guess the difficulty could eventually be such that *no* device is profitable and the only people still mining either don't care about the price of electricity (i.e., idiots and criminals) or they value the anonymity so much that no premium is too high (again, idiots and criminals).

In the end-game phase, the absolute speed of your hardware probably won't matter much as long as it's competitive with the rest of the net. We might be having a bit of a terminology problem/misunderstanding here, I think: "mining speed" is based on the performance of your hardware as well as the rest of the network, so even with a constant hashing speed, your mining speed can vary greatly.
Either way, the payout (as in "newly minted coins") for each block will have dropped close to zero, so the majority of profits for mining will have to come from transaction fees. For that system to work, you'd need either lots of people paying small fees (e.g. through widespread everyday use of BTC), or fewer people paying higher fees (I have no idea how much a crook would pay for this kind of service). We'll just have to wait and see... And it's going to be a while, since so far hasn't been a need to pay any fees just yet.

hunterk wrote:
the entire market is just a bunch of people trying to fuck each other over.

That applies to pretty much every market I can think of, not just BTC. It's just that this one, as a very young market, doesn't yet have as many regulations and/or safety nets in place as others.

Sun 08 Dec 2013, 13:34:11
1, 2  Next

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum