Looks like there error message for the "-f" parameter accidentally calls it "-d".
The OpenCL code looks based on the SPH implementation. Is that the case?
sorry, i changed -d to -f to use -d for "device", but forgot the error. About the code, it is a "pruned" SPH code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation. Ha! I ran into that as well! Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks. I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results. BTW, before releasing the GPU miner I was thinking to port back my optimizations to the CPU version, do you think it's still worth it? My code was so slow on my GPU that i thought CPU mining would still be possible. What do you think? I think it'd totally be worth it from a development point of view. I'll make optimizing the code way easier, especially considering the "debugging" tools for OpenCL. I actually pushed a few new optimizations to my CPU miner fork today. Feel free to check them out: https://github.com/llamasoft/xptminer-linux/commits/masterAlso, as far as the metis/fugue thing goes, I'm almost 100% certain they're the same. The original source even calls it "fugue" in the comments. I'll drop you a message sometime tomorrow. I've got some optimizations I want to test out with the GPU code that I'll share with you. |
|
|
|
Looks like there error message for the "-f" parameter accidentally calls it "-d".
The OpenCL code looks based on the SPH implementation. Is that the case?
sorry, i changed -d to -f to use -d for "device", but forgot the error. About the code, it is a "pruned" SPH code (removed all that was not used, removed all possible forks and loops, etc). I tried the reference implementation for shavite (the slower one) but could not make it compatible with the code from xptminer/SPH (for some reason hashes were always different, no matter what i did, even the "init" held different initial values). So i just gave up on other implementations and assumed they had changed something in the SPH for metiscoin. Metis "looks" vaguely like "fugue", but after the lack of success with shavite i didn't even try to use another implementation. Ha! I ran into that as well! Apparently as part of round 2 of the SHA-3 competition some of the submitted algorithms had a few tweaks. I don't think SPH is using the "correct" version, so using reference code results in "incorrect" results. |
|
|
|
|
Looks like there error message for the "-f" parameter accidentally calls it "-d".
The OpenCL code looks based on the SPH implementation. Is that the case?
|
|
|
|
huh strange, best hashrate i can get from FX-6300 is 650
Using xpt-bdver1 I'm getting 740 Kh/s out of this same CPU, but at 4Ghz. My rig is fucked CPU mining wise though, memory in single channel Try favorBlend and AVX_favorBlend. You might be able to get a few more khash out of it. |
|
|
|
I took the time to finally get xptMiner to compile with GCC for Windows. It was a nightmare for me, but what does that mean for you? Christmas may have come early. I've compiled my optimized code for each of the following architectures: generic, core2, corei7, corei7-avx, k8, k8-sse3, and barcelona (k10). The Windows x64 binaries are available from here:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) Use whichever corresponds to your processor architecture. If you're unsure, here's a quick guide based on your CPU manufacturer and age: Intel: [Older] core2 -> corei7 -> corei7-avx [Newer] AMD: [Older] k8 -> k8-sse3 -> barcelona (k10) [Newer] Worst case scenario, use generic. I will not be releasing any 32-bit builds. "High performance 32-bit" is an oxymoron. Let me know what sort of improvements you see! Some builds may be slightly slower than the stock jh00 miner. It all depends on your CPU.I've added another 5-10% optimization to the code and hopefully fixed the issue with AMD builds. It seems that mingw-gcc thinks that AMD processors don't support SSE, so it left them disabled. I've fixed that. The code optimizations have been pushed to the github repo. The new binaries have been uploaded. (same URLs) More good news! I've added support for more processor architectures! I've added support for core-avx-i (ivybridge), core-avx2 (haswell / 4th gen i7), bdver1 (Bulldozer), and bdver2 (Piledriver). Also, the optimized miner now has it's own thread: https://bitcointalk.org/index.php?topic=436583Hey hey! I've got an update on this little project. I've made a few cache and memory tweaks and squeezed out another 5%. I've also added AVX builds for Intel and AMD processors that support them. (I haven't fully tested these, so feedback is appreciated) The changes have been pushed to github. The files are now available for download. The Windows x64 binaries are available from here:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) |
|
|
|
|
I've made some memory and cache optimizations. I'm now getting an extra 25 kh/s on my Phenom II x4 965.
Was averaging 610 kh/s, now I'm at 635 kh/s.
I've also added Visual Studio AVX builds for your folks with AVX capable processors! Feel free to give them a try.
The changes have been pushed to github and the downloads updated.
|
|
|
|
107 kHash/s on No Support VPS Hosting with 8CPU (15 dollars per month)  Whoa, that sounds way off. What do the following commands show? and |
|
|
|
huh strange, best hashrate i can get from FX-6300 is 650
Try the favorAMD and favorBlend builds. On newer AMD models the favorBlend version should be faster. For some reason favorAMD means "favor older AMD models" like Opteron and Athlon. |
|
|
|
It seems ypool is the only one finding blocks oO
Is that the case or am I reading their stats the wrong way ?
Nope, they're correct. They're probably >90% the network power for Metiscoin right now. To be fair, there's not exactly another viable pool running and ypool managed to pump out a miner within 48 hours of release. |
|
|
|
I took the time to finally get xptMiner to compile with GCC for Windows. It was a nightmare for me, but what does that mean for you? Christmas may have come early. I've compiled my optimized code for each of the following architectures: generic, core2, corei7, corei7-avx, k8, k8-sse3, and barcelona (k10). The Windows x64 binaries are available from here:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) Use whichever corresponds to your processor architecture. If you're unsure, here's a quick guide based on your CPU manufacturer and age: Intel: [Older] core2 -> corei7 -> corei7-avx [Newer] AMD: [Older] k8 -> k8-sse3 -> barcelona (k10) [Newer] Worst case scenario, use generic. I will not be releasing any 32-bit builds. "High performance 32-bit" is an oxymoron. Let me know what sort of improvements you see! Some builds may be slightly slower than the stock jh00 miner. It all depends on your CPU.I've added another 5-10% optimization to the code and hopefully fixed the issue with AMD builds. It seems that mingw-gcc thinks that AMD processors don't support SSE, so it left them disabled. I've fixed that. The code optimizations have been pushed to the github repo. The new binaries have been uploaded. (same URLs) More good news! I've added support for more processor architectures! I've added support for core-avx-i (ivybridge), core-avx2 (haswell / 4th gen i7), bdver1 (Bulldozer), and bdver2 (Piledriver). Also, the optimized miner now has it's own thread: https://bitcointalk.org/index.php?topic=436583 |
|
|
|
Can you post a avx2 version for 4th generation i7？Thanks!
I've added support for Intel processors with AVX2 support. I've also added builds for Bulldozer and Piledriver versions of AMD processors. Enjoy! |
|
|
|
I've compiled my optimized code for each of the following architectures: core2, corei7, corei7-avx, core-avx-i, core-avx2, k8, k8-sse3, barcelona, bdver1, and bdver2 I've also compiled it via Visual Studio 2010 with performance guided optimizations for AMD, Intel, and blend processors (with and without AVX). The end result is a 10 - 25% speed increase over the stock jh00 miner from yPool! (Even more if you're on Linux) Donations appreciated! MTC: MEu8jBkkVvTLwvpiPjWC9YntyDH2u5KwVy
Which version is for me?For Linux users: compile the code from githubgit clone https://github.com/llamasoft/xptminer-linux.git
cd xptminer-linux
CFLAGS="-flto -funroll-loops" make Alternately, check out my All-In-One EZ Setup Script. For Windows users:For starters, you cannot go wrong with any of the "favor" versions. They are compiled in a generic format that should work on all processor architectures. If you have an Intel processor, use "favorIntel". If you have an AMD processor, try "favorBlend" then "favorAMD". Architecture Specific Builds: (oldest to newest) Intel - core2
- corei7
- corei7-avx - a.k.a. "sandybridge"
- core-avx-i - a.k.a. "ivybridge"
- core-avx2 - a.k.a. "haswell / 4th generation i7"
AMD - k8 - a.k.a. "opteron / athlon64"
- k8-sse3
- barcelona - a.k.a. "k10"
- bdver1 - a.k.a. "bulldozer"
- bdver2 - a.k.a. "piledriver"
Start with the oldest architecture of your processor manufacturer. If the program works, write down the hash rate after 5-10 minutes* and try the next version. If the program crashes, stop and use the previous version with the highest hash rate. *: Seriously. At least 5 minutes. Before then and the hash rate is very inaccurate.Compare the results to the corresponding "favor" version. Keep whichever is best!
Where do I get the binaries?The Windows 64-bit binaries are available for download from two locations: https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) There is no 32-bit version of the optimized code for Windows.Part of the optimizations force the hash algorithms to use 64-bit mode. For more info, see this post.
Benchmarks| User | CPU | Miner Version | kHash/s | | ============ | ======================== | ============ | ============ | | gigawatt | AMD Phenom II x4 965 @ Stock | favorBlend | 637 | | gigawatt | Intel i5-3210M @ Stock | favorIntel | 292 | | gigawatt | Amazon AWS - c1.xlarge | github | 690 |
Want your benchmark added? Just post it in the thread and I'll update the list. |
|
|
|
My machine has 16 cores. When I specify -t 32, it got this error periodically. Setting to -t 16, in the beginning same error msg, but later all went to normal. what is the cause of this? I thought multi-threading could be used? I will try your version. Thank you for your reply! Is that 16 cores and hyperthreading? (e.g. 2 threads per core?) I've noticed on the Intel processors it's better to take it down a thread or two from maximum. For example, if you have 4 cores + hyperthreading, -t 7 works better than -t 8. |
|
|
|
The "-m" flags are for mining Protoshares and have no effect when mining Metiscoin.  thanks for u answer，and i run u Script at amz't1.micro,and i get kHash/s: 10.68 Shares total: 0 Yeah, the free t1.micro only get a fraction of a CPU. You might be interested in the "power of 60" promo. It's $100 free AWS credit. That'll get you ~60 c1.xlarge spot instances for 24 hours. |
|
|
|
NEW PROGRAM FAST++ ypoolcryptsy LIKE exchangeWin32/64bit + Ubuntu 13.04 x64NewKhash 300 -->> 400-500 Shares 1,5x Fast Did I miss something? I took a look at the source code and it seems to be identical to my modified version of metiscoinMiner.cpp. It seems like you took the stock v1.1 from jh00, called it v1.2 and copy/pasted my code. What else did you change? (aside from the developer fees) |
|
|
|
I took the time to finally get xptMiner to compile with GCC for Windows. It was a nightmare for me, but what does that mean for you? Christmas may have come early. I've compiled my optimized code for each of the following architectures: generic, core2, corei7, corei7-avx, k8, k8-sse3, and barcelona (k10). The Windows x64 binaries are available from here:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) Use whichever corresponds to your processor architecture. If you're unsure, here's a quick guide based on your CPU manufacturer and age: Intel: [Older] core2 -> corei7 -> corei7-avx [Newer] AMD: [Older] k8 -> k8-sse3 -> barcelona (k10) [Newer] Worst case scenario, use generic. I will not be releasing any 32-bit builds. "High performance 32-bit" is an oxymoron. Let me know what sort of improvements you see! Some builds may be slightly slower than the stock jh00 miner. It all depends on your CPU.I've added another 5-10% optimization to the code and hopefully fixed the issue with AMD builds. It seems that mingw-gcc thinks that AMD processors don't support SSE, so it left them disabled. I've fixed that. The code optimizations have been pushed to the github repo. The new binaries have been uploaded. (same URLs) I've added a few more performance tweaks and pushed the kHash overflow fix to github. The other performance tweaks I have not pushed because they hard code 64-bit mode for some of the hash algorithms. For the sake of openness, here's the changes: keccak.c#define SPH_KECCAK_64 1
#define SPH_KECCAK_UNROLL 0
#define SPH_KECCAK_NOCOPY 0
#define SPH_KECCAK_NOCOPY 0
#define SPH_64 1
I've also compiled the code through Visual Studio 2010 with performance guided optimization and the windows builds now regularly meet or exceeds the jh00 speeds. I've built two versions: one with the /favor:INTEL64 flag and one with /favor:AMD64. Pick whichever matches your processor. edit: AMD users! Try the favorAMD build first, then the favorBLEND build. Apparently /favor:AMD64 prefers older AMD processors (Athlon, Opteron, and Sempron). See which works best for you! Download Links:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror)  (My AMD Phenom II x4 955 @ stock clock) |
|
|
|
I got very strange problem: (See) Share found! (Blockheight: 22917) kHash/s: 1034.78 Shares total: 71 kHash/s: 1034.79 Shares total: 71 kHash/s: 0.36 Shares total: 71 kHash/s: 2.36 Shares total: 71 Share found! (Blockheight: 22917) kHash/s: 4.34 Shares total: 72 Share found! (Blockheight: 22917) kHash/s: 6.29 Shares total: 73 kHash/s: 8.27 Shares total: 73 Share found! (Blockheight: 22917) kHash/s: 10.22 Shares total: 74 Some how the kHash/s goes to lowest (from 1000kHash to 0.5kHash) and then gradually go up to a few hundert. But the share value in ypool doesn't change so I assume it is just a glitch  On the linux build there's an issue with the average hash rate calculation. Long story short, because it calculates the average hash rate as "total hashes / total time", after a long enough period the value of "total hashes" overflows back to zero. It's just a graphical bug (you can check your shares/hour on yPool if you're not sure). I just updated the github to fix it, so rebuild and you should be good to go. |
|
|
|
40kHash/s in my vps 4core@850mhz btw i use -m512 and default 4 threads, but in web Control i see 54.7 MB of 2 GB Used / 1.9 GB Free, why? ./xpt -o ypool.net -u ziliao.vps -p x -m512 O--------------------------------------------------O | xptMiner (v1.1g) Linux | | author: jh00 | | modified by GigaWatt | | Donation: MEu8jBkkVvTLwvpiPjWC9YntyDH2u5KwVy | | http://ypool.net | O--------------------------------------------------O Launching miner... Using 4 threads Connected to server using x.pushthrough(xpt) protocol xpt: Logged in with ziliao.vps New block data - height: 21989 tx count: 4 kHash/s: 32.77 Shares total: 0 kHash/s: 38.91 Shares total: 0 kHash/s: 38.23 Shares total: 0 kHash/s: 40.96 Shares total: 0 kHash/s: 39.32 Shares total: 0 kHash/s: 40.96 Shares total: 0 kHash/s: 39.79 Shares total: 0 kHash/s: 40.96 Shares total: 0 kHash/s: 40.05 Shares total: 0 kHash/s: 40.96 Shares total: 0 kHash/s: 40.22 Shares total: 0 Share found! (Blockheight: 21989) kHash/s: 40.96 Shares total: 1 kHash/s: 41.59 Shares total: 1 kHash/s: 40.96 Shares total: 1 kHash/s: 41.51 Shares total: 1 kHash/s: 41.98 Shares total: 1 kHash/s: 42.41 Shares total: 1 New block data - height: 21990 tx count: 8 The "-m" flags are for mining Protoshares and have no effect when mining Metiscoin. |
|
|
|
I took the time to finally get xptMiner to compile with GCC for Windows. It was a nightmare for me, but what does that mean for you? Christmas may have come early. I've compiled my optimized code for each of the following architectures: generic, core2, corei7, corei7-avx, k8, k8-sse3, and barcelona (k10). The Windows x64 binaries are available from here:https://mega.co.nz/#F!YsZSHYKA!IC8LK_MBGwqC-gWOpO7zoQhttps://www.dropbox.com/sh/wtxvxvkirxax2vj/9P_Rxb9V1y (dropbox mirror) Use whichever corresponds to your processor architecture. If you're unsure, here's a quick guide based on your CPU manufacturer and age: Intel: [Older] core2 -> corei7 -> corei7-avx [Newer] AMD: [Older] k8 -> k8-sse3 -> barcelona (k10) [Newer] Worst case scenario, use generic. I will not be releasing any 32-bit builds. "High performance 32-bit" is an oxymoron. Let me know what sort of improvements you see! Some builds may be slightly slower than the stock jh00 miner. It all depends on your CPU.I've added another 5-10% optimization to the code and hopefully fixed the issue with AMD builds. It seems that mingw-gcc thinks that AMD processors don't support SSE, so it left them disabled. I've fixed that. The code optimizations have been pushed to the github repo. The new binaries have been uploaded. (same URLs) |
|
|
|
|
Show Posts
