HN Gopher Feed (2017-07-02) - page 1 of 10 ___________________________________________________________________
Bitcoin mining on a vintage Xerox Alto: very slow at 1.5
hashes/second
142 points by darwhy
http://www.righto.com/2017/07/bitcoin-mining-on-vintage-xerox-al...___________________________________________________________________
indescions_2017 - 4 hours ago
It actually puts compute power in perspective for me quite nicely,
as GigaHashes per second (GH/s) is the most common metric in mining
pools. My core i5 laptop gets around 10MH/s. A gaming desktop with
GTX1050 pushes above 100MH/s.Compare that to a state-of-the-art
Antminer at ~11Th/s using 1.1kW. Estimating a large pool size of
~250 Ph/s. And the Alto's rough payout calculation of about a
billionth of a penny for 2017 looks right!Any chance ethereum and
zcash mining are up next for that poor old Alto that just wants to
retire and dream of electric sheep?
kens - 4 hours ago
If I understand etherium and zcash mining, they use algorithms
designed to require a lot of RAM so it is ASIC-resistant. (I.e.
they want mining to be practical on a PC, not requiring custom
hardware.)Unfortunately for the Alto, the gigabytes of data
required for mining won't fit into the 512kB memory. Even
swapping to the hard disk won't work, since that only holds
2.5MB. Thus, while Bitcoin would have been possible in the 1970s,
etherium and zcash wouldn't have been.
miahi - 3 hours ago
Not only lots of RAM but lots of very fast RAM. This is what
makes it ASIC-resistant for now (it's not hard to attach a huge
RAM to an ASIC, but going for hundreds of GB/s is really
expensive). So unfortunately it's GPUs for now.
xj9 - 2 hours ago
\> unfortunatelyi think you are missing the point. the idea
is to prevent ASICs from taking over. if you could build one
that could mine ETH or zcash, it would be a failure from
their perspective.
JohnTHaller - 1 hours ago
I think parent means it's unfortunate for those of us that
are looking to buy a video card for gaming. Or actual
work.
miahi - 2 hours ago
It's unfortunate because the GPU prices and availability
right now are going nuts. I wanted to buy a GTX 1070 and
it's out of stock with weeks of waiting on preorders on
most European websites, with price increases of 40-50% in
the last 30 days.
ven_bug_trap - 1 hours ago
In the short term it may seem more unfortunate, but the
problem with expensive ASICs is that they make
centralisation far easier, by making it less feasible for
ordinary people to do the mining.
paulmd - 2 hours ago
> Thus, while Bitcoin would have been possible in the 1970s,
etherium and zcash wouldn't have been.Not with current DAG
sizes, but if this system had been available in the 70s it
wouldn't have the current DAG sizes. If you assume a DAG that
numbers in tens/hundreds of kbyes then it would have been
workable.
[deleted]
le-mark - 2 hours ago
$2500 BTC makes spending a lot of money on asics reasonable,
because if prices hold, you can earn back a large spend in 6
months or so. Finding the asics to purchase becomes the problem.
[deleted]
dijit - 5 hours ago
To be fair. I'm impressed it's able to do it at all.I compiled a
"hello world" in C staticly on my laptop the other week as a demo
of how things have grown; to my horror it wouldn't have even fit in
memory of my first computer.
arthurcolle - 5 hours ago
same environment other than memory constraints?... I'd think this
wouldn't even work at all
userbinator - 5 hours ago
SHA256 doesn't require all that much storage nor code --- a few
KB at most for a simple, not very fast implementation.
kens - 5 hours ago
Well, I got SHA-256 running on a 1960s punched card machine with
16K of memory so the hardware requirements aren't too
much.http://www.righto.com/2015/05/bitcoin-mining-on-55-year-
old-...
yuhong - 5 hours ago
I wonder about Ryzen's new SHA1/SHA256 instructions, not only for
Bitcoin but also things like SHA1 collisions.
mschuster91 - 5 hours ago
Hmm. In contrast to a GPU / ASIC implementation, where thermal
load is spread equally across the die, I'd guess that coin-mining
usage levels will lead to local overheating and thus throttling -
or worse, if there's no thermal sensor for this area, even
permanent damage.
ryan-c - 5 hours ago
Intel's chips have those too - but I highly doubt the speedup
will provide even close to gpu power efficiency.
yuhong - 5 hours ago
Only Goldmont Atoms I think.
dom0 - 4 hours ago
Cannon Lake is supposed to bring them to Intel desktops some
time 2017 or 2018.The performance of these is in the 2-3 cpb
range per core on Zen.
rjsw - 5 hours ago
My copy of The TTL Data Book suggests that the ALU was able to do
XOR, an earlier blog post stated that microcode opcode bits go
through a table instead of being fed directly to the 74181 function
pins.I wonder why Xerox didn't want to use all the ALU features.
kens - 5 hours ago
In microcode, the Alto provides the 16 most useful functions of
the 74181 (calling most of the 74181's operations "mostly
useless"). This includes XOR and OR. However, the Alto copied the
Data General Nova's instruction set, which doesn't include OR and
XOR, so you can't use these instructions from machine code. I
think there's extended microcode that provides "extra"
instructions for XOR and OR and an improved BCPL compiler to make
use of them, but I haven't tracked it down.See the Alto hardware
manual (page 4) on bitsavers for details:
http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/...
zkms - 1 hours ago
Is there documentation/examples for how to program the Alto's
microcode?
kens - 44 minutes ago
The Alto hardware manual explains how the microcode works
(see sections 2 and 9 and try to memorize Figure 1). For
examples, see the existing Alto microcode. The subsystem
manual p90 describes the MU microcode assembler and the
syntax. See also RPRAM in the subsystem manual that describes
how to load microcode into control RAM. I haven't seen
anything like a howto/tutorial for microcode in the Alto
documentation.http://bitsavers.informatik.uni-
stuttgart.de/pdf/xerox/alto/... http://bitsavers.informatik
.uni-stuttgart.de/pdf/xerox/alto/... http://www.mirrorservice
.org/sites/www.bitsavers.org/pdf/xer...If you want to try
this stuff out for yourself (and don't have an Alto handy),
use the ContrAlto emulator:
https://github.com/livingcomputermuseum/ContrAlto
userbinator - 4 hours ago
Here is a document I found on the DG Nova instruction
set:http://users.rcn.com/crfriend/museum/doco/DG/Nova/base-
instr...If you scroll down to "Arithmetic/Logic Instructions"
you'll see that they did not have room for XOR nor OR, since
several of the 8 opcodes that fit into the 3-bit field are what
we'd normally think of as "one-operand", but have been expanded
to be "two-operand" (oddly enough, there is an increment but no
decrement instruction either.)It's interesting to compare to
two other well-known CPUs with a 3-bit ALU opcode field:The
Z80's (and 8008/8080/8085) ALU opcodes are:
ADD/ADC/SUB/SBC/AND/XOR/OR/CPThe x86's ALU opcodes are:
ADD/OR/ADC/SBB/AND/SUB/XOR/CMP
kens - 4 hours ago
That's an interesting comparison with microprocessor ALU
operations. (6502 is similar to Intel but doesn't have
add/subtract without carry.)Note that the Nova uses two
additional instruction bits for the carry. Thus, the Intel
instruction sets use two of the 8 opcodes for add with carry
and subtract with borrow/carry, but the Nova doesn't. So it
should be easier for the Nova to fit in additional useful ALU
instructions. (Not to mention the Nova has 16-bit
instructions.)
rjsw - 4 hours ago
From your link there looks to be two functions spare, I guess
you would need a new PROM to make use of them though.The MIT
Lisp Machine does just map microcode instruction bits onto the
74181 function pins but it has much wider microinstructions
than the 32-bit Alto ones.
Animats - 3 hours ago
They're using the British Cruddy Programming Language? Don't they
have the Mesa compiler up?BCPL is about halfway between assembler
and C.
kens - 2 hours ago
Still working on getting Mesa running...BCPL isn't as primitive
as I expected. It's surprisingly similar to C, except lacking
types. C's structs, unions, bitfields are almost a direct copy of
BCPL, along with the ternary ? operator. C's lvalues, rvalues,
and pointers are also just like BCPL.BCPL has way more control
flow statements than C: if EXP do STATEMENT, unless EXP do S,
test EXP then S1 or STAT2, test EXP ifso S1 ifnot S2, while EXP
do S, until E do S, S repeatwhile EXP, S repeatuntil EXP, S
repeat, switchon EXP into CASES, etc. The C language trimmed out
a lot of the redundancy. BCPL's switchon statement is just like
C's with fall-through cases unless you use a break.