Want one for OrangePi
Topic: RaspberryPi litecoin CPU and GPU miner bounty (Read 19259 times)
Nice. I like the continuation.
Want one for OrangePi
Want one for OrangePi
Hi!
Uauh, It has been a while since Anyone posted here...and the bitcoin scene has changed so much. I think that actually anyone would care about this but I've started developing a gpu (well, qpu) miner for the raspberry pi. In theory (It is not finished yet) it should reach 1.5Mhash/second which is quite slow cause nowadays everyone talks about ghash/s. It is based on the excellent work made by Eric Lorimer (https://github.com/elorimer/rpi-playground). If anyone wants to take a look at the code or event write some of it, perfect!
Sergio.
Uauh, It has been a while since Anyone posted here...and the bitcoin scene has changed so much. I think that actually anyone would care about this but I've started developing a gpu (well, qpu) miner for the raspberry pi. In theory (It is not finished yet) it should reach 1.5Mhash/second which is quite slow cause nowadays everyone talks about ghash/s. It is based on the excellent work made by Eric Lorimer (https://github.com/elorimer/rpi-playground). If anyone wants to take a look at the code or event write some of it, perfect!
Sergio.
The first SoC I think thay may be capable of real GPU mining might be the Tegra 4. iirc it will have a more programmable GPU.
With today's news may the bounty get back on track?
Pi's are now generally available. Plus I want to thrash the fuck out of my iPhone before the rumored release of the iPhone 5 (and the expiry of my warranty)
Is development still alive? Still require funding?
Is development still alive? Still require funding?
The ARMv6 implementation of scrypt in cpuminer 2.2.3 is to be considered mature and stable. It can do 320 hashes/s on a Raspberry Pi, and 190 hashes/s on an iPhone 3G.
While I mainly did this for the fun of it, I'll be happy to take a fraction of the bounty if nobody has any objections.
Regarding the GPU, let me quote a thread from the Raspberry Pi forum.
Quote
GLSL ES (the stripped down version of the OpenGL Shader Language) does not have proper support for integers. See paragraph 4.1.3 in the GLSL ES specification. Integers are only supported as a programming aid (in loops, for instance). They have very loosely defined semantics and precision, and many typical integer operations are not supported. Most OpenGL ES implementations simply map int to float.
Applications that rely on integers simply won't work on the GPU. Good examples for that are bitcoin mining, cryptography in general and compression.
In case you are wondering, this also applies to scrypt, which is based on integer arithmetics. Applications that rely on integers simply won't work on the GPU. Good examples for that are bitcoin mining, cryptography in general and compression.
Pi's are now generally available. Plus I want to thrash the fuck out of my iPhone before the rumored release of the iPhone 5 (and the expiry of my warranty)
Is development still alive? Still require funding?
Is development still alive? Still require funding?
Maybe this with a A10 single-core 1.5GHz ARM CPU and a Mali 400 GPU would hash better plus it's only $74 again probably using only a few watts. http://arstechnica.com/gadgets/2012/05/new-74-android-mini-computer-is-slightly-larger-than-a-thumb-drive/
The CPU certainly would, being a Cortex-A8. The current code should do over 1 khash/s on it, and that's without NEON optimizations.
Maybe this with a A10 single-core 1.5GHz ARM CPU and a Mali 400 GPU would hash better plus it's only $74 again probably using only a few watts. http://arstechnica.com/gadgets/2012/05/new-74-android-mini-computer-is-slightly-larger-than-a-thumb-drive/
After some more optimization, I think I have finally broken the 300 hashes/sec barrier for the ARM11 at 700 MHz.
I say "I think" because I have only tested the code on my iPhone 3G at 412 MHz, which can now do 181 hashes/sec.
I don't know if anybody is actually interested in ARM11 mining, but this sure is challenging!
P.S. Sorry but NEON optimizations will take longer than expected, as my Cortex-based device is currently away for repair.
I say "I think" because I have only tested the code on my iPhone 3G at 412 MHz, which can now do 181 hashes/sec.
I don't know if anybody is actually interested in ARM11 mining, but this sure is challenging!
P.S. Sorry but NEON optimizations will take longer than expected, as my Cortex-based device is currently away for repair.
That was before the reaper LTC GPU miner was released and the LTC rate dropped to nil...
I don't think the GPU miner had much of an effect (to be honest).
It isn't nearly as optimized as the bitcoin ones.
That was before the reaper LTC GPU miner was released and the LTC rate dropped to nil...
Hi!
Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
I agree, it's already so fragile, you will only break it. This is why uninformed people shouldn't request things. Sorry if I sound harsh, but it's true.Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
Nothing makes me think the Pi is fragile. Its developers say it is perfectly safe to have it running 24/7 under heavy loads.
Also consider that ARM processors are way more power efficient than Intel CPUs, so heat dissipation is much less of a problem.
As for the why: mining is not all about the profit. It is both interesting and useful to assess the capabilities of a given hardware platform.
And it's fun.
Also why am I uniformed when LTC mining has already been ported to iPhone and Android. Arm CPU's are way more efficient per watt than x86 there is even ARM based super-computers and servers being built. So it makes sense to mine LTC which is supposed to be CPU biased on the most power efficient CPU family. Sorry to sound harsh but maybe uninformed people shouldn't claim to be a font of knowledge on the subject.
Hi!
Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
I agree, it's already so fragile, you will only break it. This is why uninformed people shouldn't request things. Sorry if I sound harsh, but it's true.Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
Nothing makes me think the Pi is fragile. Its developers say it is perfectly safe to have it running 24/7 under heavy loads.
Also consider that ARM processors are way more power efficient than Intel CPUs, so heat dissipation is much less of a problem.
As for the why: mining is not all about the profit. It is both interesting and useful to assess the capabilities of a given hardware platform.
And it's fun.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Hi!
Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
I agree, it's already so fragile, you will only break it. This is why uninformed people shouldn't request things. Sorry if I sound harsh, but it's true. Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
Hi!
Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
Why do you want to mine on such a machine? Better use it to run a tradebot 24/7...
This might not be the case for rbp, but are you planing to use neon instruction set?
Yes, I plan to start working on a NEON-based implementation later on this week.
I've just finished writing some optimized assembly code for the ARM11. Here are the results for scrypt on my iPhone-3G, running at 412 MHz:
C implementation* (cpuminer 2.2): 103 h/s
New hand-optimized assembly: 160 h/s
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
This might not be the case for rbp, but are you planing to use neon instruction set? C implementation* (cpuminer 2.2): 103 h/s
New hand-optimized assembly: 160 h/s
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
I've just finished writing some optimized assembly code for the ARM11. Here are the results for scrypt on my iPhone-3G, running at 412 MHz:
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
| C implementation* (cpuminer 2.2): | 103 h/s |
| New hand-optimized assembly: | 160 h/s |
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
Cool but the bounty is still very small maybe we could apply for DevCoin funding to keep it a work in progress?
I've just finished writing some optimized assembly code for the ARM11. Here are the results for scrypt on my iPhone-3G, running at 412 MHz:
C implementation* (cpuminer 2.2): 103 h/s
New hand-optimized assembly: 160 h/s
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
C implementation* (cpuminer 2.2): 103 h/s
New hand-optimized assembly: 160 h/s
Of course a 55% speedup is not bad at all, but still if we assume that hash rate scales linearly with CPU clock speed, we can only expect the Raspberry Pi to do about 270 h/s.
I still have to do some testing to make sure that the code behaves well on more recent ARM processors like the Cortex-A8, but I'm pretty sure this new code will get included in the next release of cpuminer, which will probably be out in a week or two.
* The C implementation was compiled with gcc 4.2.1; I know that's not exactly recent, but it's all I can get on this device. It is possible that more recent versions of gcc produce faster code.
LTC donation address - LKQ9ZKKBNHYcPjSkSK2GnkbYb7PeFgnSj7
BTC donation address - 1JooT9sKj3YG2k8i6MrH5DTo72g8rF7gKb
NMC donation address - NCvUBqH8bPGwybfWHWycF8dYiLYb8gg3VN
On the case the project not getting developed all donations will go to projects on http://litebit.co/
BTC donation address - 1JooT9sKj3YG2k8i6MrH5DTo72g8rF7gKb
NMC donation address - NCvUBqH8bPGwybfWHWycF8dYiLYb8gg3VN
On the case the project not getting developed all donations will go to projects on http://litebit.co/
I have received some interest on the RaspberryPi forums - http://www.raspberrypi.org/forum/projects-and-collaboration-general/raspberrypi-litecoin-cpu-and-gpu-miner-bounty#p62032
"I'll put it another way:
The ONLY people that can write code that runs on the GPU is the manufacturer (Broadcom).
The manufacturer provides users info so we can make OpenGL API calls. We, the users, don't get to write any code that runs on the GPU. All we can do is send requests to draw stuff. We can try and fake some elements of parallel processing but there are inherent limitations that don't make it worthwhile.
I think your colleagues assement on your linked thread of Bitcointalk of this thread:
http://www.raspberrypi.org/for…..n-the-r-pi
pretty much sums up the situation – when you re-read it, bear in mind that JamesH is a Broadcom employee and therefore really knows his stuff about such things.
However, if there is going to be some money offered for anything, I'll start pledging for porting the X display driver to OpenGL ES for the RaspberryPi."
So get the donations coming
Jump to: