Topic: C# mining library (Read 5243 times)
Same... Maybe I can then adapt it for XNA and have an Xbox360 miner. Or a silverlight miner perhaps ? (which I would assume would be faster than javascript)
Have you published it yet. I would like to take a look in the code.
Bump
Hey I'm a c# coder. I'd be interested in contributing.
When do you think you'll have the git repo up?
When do you think you'll have the git repo up?
Have you published it yet. I would like to take a look in the code.
Did you ever post the git repository?
No, I have a backlog of projects I'm trying to get ready for release and this is one of them.
Did you ever post the git repository?
Well, if all you did was compile from source for your miner, you could add the -O=all flag. Then again, the documentation says generics suck on AOT so I guess you could profile the AOT vs non-AOT and see how the milage varies.
The difference, if there is any, will be negligible. JITting a method is a one-time operation in the life of an AppDomain; AOT will reduce startup time, but will not improve runtime performance (and may degrade it).
Are you going to support any of the new parallelism / async stuff? If so, I wouldn't mind getting in this just to try the new sexiness out 
Probably not, just Thread objects. The parallel stuff is more for doing efficient processing of sequences or starting up a few discrete tasks and firing them off... it's not really well-suited for mining, where performance is critical.
I have a worker-pooling class that will manage the workers automatically, whether they are CPU miners running on different threads or GPU miners running on different GPUs.
You could probably use MS's NGen or Mono's --full-aot / --aot=full flag to compile it to a native build. I expect that would bump up the hashes a bit.
That would actually worsen performance. All AOT does is perform the bytecode-to-native translation ahead of time. The JIT-compiler will perform the same process at runtime when each method is first entered -- so this step only happens once per method for each instance of the program.
The difference is that the JIT knows what CPU it is running on and can use optimizations specific to the features your CPU has. Since AOT code is designed to be distributed with the corresponding assembly, the AOT-compiler has to assume a generic CPU and so it will create compatible but slower code.
Well, if all you did was compile from source for your miner, you could add the -O=all flag. Then again, the documentation says generics suck on AOT so I guess you could profile the AOT vs non-AOT and see how the milage varies.
Are you going to support any of the new parallelism / async stuff? If so, I wouldn't mind getting in this just to try the new sexiness out
You could probably use MS's NGen or Mono's --full-aot / --aot=full flag to compile it to a native build. I expect that would bump up the hashes a bit.
That would actually worsen performance. All AOT does is perform the bytecode-to-native translation ahead of time. The JIT-compiler will perform the same process at runtime when each method is first entered -- so this step only happens once per method for each instance of the program.
The difference is that the JIT knows what CPU it is running on and can use optimizations specific to the features your CPU has. Since AOT code is designed to be distributed with the corresponding assembly, the AOT-compiler has to assume a generic CPU and so it will create compatible but slower code.
You could probably use MS's NGen or Mono's --full-aot / --aot=full flag to compile it to a native build. I expect that would bump up the hashes a bit.
Hey all.
I've started working on a C# mining library. I've seen the idea tossed around a few times, and as a newer Bitcoin user with a strong background in programming (it's my job after all) I figured I'd dive in.
Three git commits later and I have a working, purely managed implementation optimized a tiny bit by using unsafe code. It's getting ~200khash/sec on a mostly-idle 2.66Ghz core. So not great, but not terrible for a JITed language either. It's mostly an exercise for me, but hopefully the community will have some use for it...
The miner and data source are hidden behind interfaces; I'm trying to make it easy for someone to come along with an OpenTK-based GPU miner, for example, and allow it to be used with my miner with no modifications to the core library. Or even write a mining routine in C and p/invoke it. Likewise, it'll be easy for someone to come along and write a data source that doesn't use JSON-RPC if they wanted to, for whatever reason, and have it work with any of the miner libraries installed on the system. Since the large majority of the expense in terms of computing power isn't getting into the mining routine, but actually running the mining routine, a native or GPU-based miner should see close to zero overhead, even running in a managed environment (.NET or Mono).
Further, since it's a library and managed, it can be easily consumed by other software and should run ~everywhere. (The managed miner only supports little-endian architectures at this point, but that doesn't mean addin miners won't work on big-endian.)
The source isn't yet released. I'm hoping to release the git repo in the next week or so, under the MIT license.
Thoughts on this idea are welcome. Note that, as someone interested in this kind of thing, I'll probably keep writing it even if you all think it's a horribly stupid idea.
I've started working on a C# mining library. I've seen the idea tossed around a few times, and as a newer Bitcoin user with a strong background in programming (it's my job after all) I figured I'd dive in.
Three git commits later and I have a working, purely managed implementation optimized a tiny bit by using unsafe code. It's getting ~200khash/sec on a mostly-idle 2.66Ghz core. So not great, but not terrible for a JITed language either. It's mostly an exercise for me, but hopefully the community will have some use for it...
The miner and data source are hidden behind interfaces; I'm trying to make it easy for someone to come along with an OpenTK-based GPU miner, for example, and allow it to be used with my miner with no modifications to the core library. Or even write a mining routine in C and p/invoke it. Likewise, it'll be easy for someone to come along and write a data source that doesn't use JSON-RPC if they wanted to, for whatever reason, and have it work with any of the miner libraries installed on the system. Since the large majority of the expense in terms of computing power isn't getting into the mining routine, but actually running the mining routine, a native or GPU-based miner should see close to zero overhead, even running in a managed environment (.NET or Mono).
Further, since it's a library and managed, it can be easily consumed by other software and should run ~everywhere. (The managed miner only supports little-endian architectures at this point, but that doesn't mean addin miners won't work on big-endian.)
The source isn't yet released. I'm hoping to release the git repo in the next week or so, under the MIT license.
Thoughts on this idea are welcome. Note that, as someone interested in this kind of thing, I'll probably keep writing it even if you all think it's a horribly stupid idea.
Jump to: