[XPM] [ANN] Primecoin High Performance | HP14 released! - page 31.

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: paulthetafy on August 26, 2013, 08:15:15 AM

Quote from: mikaelh on August 26, 2013, 07:55:49 AM

Quote from: arnuschky on August 26, 2013, 06:07:03 AM

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value.

I can confirm this.

Yup, it looks like the actual speedup doesn't match the chains/day estimate. I never did a full comparison between hp9 and hp10 myself on mainnet because it's pretty expensive to do that. So big thanks to the guys who did. I did try to adjust the chains/day estimate to account for effects of extending the sieve. It's possible there are some bugs with that. Of course the estimate isn't fully accurate in the first place either.

The CPD is a good reference point though. I think the key here is that we need a stable metric that we can use to benchmark performance, whether it's accurate in what it is attempting to measure or not. The downside now is that if you change the chains/day estimate to accurately reflect the sieve extension, when you release the next version people are going to complain that's its slower than HP10 Cheesy

With regards to the sieveextensions factor, will changing this value be reflected in the CPD? i.e. if I change it and I see CPD increase, can I take that as a positive thing, regardless if the increase % is inaccurate?

Do you have any other ideas for performance improvements in the pipeline?

I agree that it would be nice to have a stable metric. The issue is that if the metric is broken then it's simply misleading. The 'sieveextensions' parameter is reflected in chains/day but I have a feeling that it may be broken. And if it's broken, then you can't really trust it.

There are still things on my to-do list but I'm not sure if there's going to be anything big anymore.

paulthetafy

hero member

Activity: 820

Merit: 1000

Quote from: mikaelh on August 26, 2013, 07:55:49 AM

Quote from: arnuschky on August 26, 2013, 06:07:03 AM

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value.

I can confirm this.

Yup, it looks like the actual speedup doesn't match the chains/day estimate. I never did a full comparison between hp9 and hp10 myself on mainnet because it's pretty expensive to do that. So big thanks to the guys who did. I did try to adjust the chains/day estimate to account for effects of extending the sieve. It's possible there are some bugs with that. Of course the estimate isn't fully accurate in the first place either.

The CPD is a good reference point though. I think the key here is that we need a stable metric that we can use to benchmark performance, whether it's accurate in what it is attempting to measure or not. The downside now is that if you change the chains/day estimate to accurately reflect the sieve extension, when you release the next version people are going to complain that's its slower than HP10 Cheesy

With regards to the sieveextensions factor, will changing this value be reflected in the CPD? i.e. if I change it and I see CPD increase, can I take that as a positive thing, regardless if the increase % is inaccurate?

Do you have any other ideas for performance improvements in the pipeline?

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: arnuschky on August 26, 2013, 06:07:03 AM

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value.

I can confirm this.

Yup, it looks like the actual speedup doesn't match the chains/day estimate. I never did a full comparison between hp9 and hp10 myself on mainnet because it's pretty expensive to do that. So big thanks to the guys who did. I did try to adjust the chains/day estimate to account for effects of extending the sieve. It's possible there are some bugs with that. Of course the estimate isn't fully accurate in the first place either.

arnuschky

hero member

Activity: 518

Merit: 502

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value.

I can confirm this.

paulthetafy

hero member

Activity: 820

Merit: 1000

Quote from: Trillium on August 26, 2013, 05:33:20 AM

---

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value. About an hour after HP10 came out I spun up 500 x 8 core VPS instances and ran them for 6 hours. That was ~1000 CPD. I'm aware that the diff is now rising which will skew things, but in that time I got about the same block rate (average 4 an hour) as I did when I last tested a week ago with HP9 when diff was 9.75. Allowing for some luck variation (which should be largely eliminated due to the high number of instances), I can say it is not twice as fast at finding blocks. I can't say how much faster it is without more testing, which I'm not doing as running those 500 instances is NOT profitable by a long way

My limited anecdotal experience suggests that same: it's not really ~100% improved mining. It sounds too good to be true anyway, but I'm sure the optimizations help somewhat. Out of curiosity how much did those 6 hours cost?

Also we would expect to see changes in network diff and blocks found if there was really such a huge improvement from HP10: http://192.241.170.170/ Instead we see this is not the case.

yeah the charts do suggest a decrease in block time since HP10, which is why diff is rising. It looks to be around the 25% mark.... https://www.google.com/fusiontables/DataSource?docid=1XuJ-YSvvcWL-po53ra7UDy1u04Rprc-pclD8uwA#chartnew:id=7

500 x 8 cores for 6 hours was about $250 and I found 23 blocks, which works out somewhere around $170 worth. It was worth the test though - had it have been 100% increase it would have given a positive ROI

Trillium

hero member

Activity: 546

Merit: 500

Quote from: skaffen on August 26, 2013, 05:32:38 AM

Quote from: Trillium on August 26, 2013, 05:13:02 AM

For example, what do you think would be faster:

A server with one dual-core AMD Opteron CPU @ 2.4 GHz

or,

A server with two physical intel Xeon CPUs, each single core, with hyper threading @ 3.6 GHz

As it turns out, the AMD will GREATLY outperform the intel CPUs.

I respectfully disagree, sir or madam. I believe Intel has been ahead in the CPU race since the core 2, or even the core duo, and since the i3/5/7, they have been getting further ahead. Including instructions per clock.

I am not saying that one company offers superior tech to the other. I am just saying that generally speaking, especially from a historical point of view, AMD tend to do more ops per cycle. Of course there will be exceptions though, and I admit I am not really familiar with the models from either company that are less than a year old.

Trillium

hero member

Activity: 546

Merit: 500

Quote from: cryptrol on August 26, 2013, 05:19:10 AM

Some stats for hp10 :

2 x Opteron 2376 = "chainsperday" : 2.54092020 <- Really old CPU
1 x Intel i7 3770K = "chainsperday" : 2.77305771

Still no blocks found though in almost 24h.

Hope others will share their stats so we can build a nice performance thread.

It would not work well, because it varies with difficulty.

---

Quote from: paulthetafy on August 26, 2013, 05:25:40 AM

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value. About an hour after HP10 came out I spun up 500 x 8 core VPS instances and ran them for 6 hours. That was ~1000 CPD. I'm aware that the diff is now rising which will skew things, but in that time I got about the same block rate (average 4 an hour) as I did when I last tested a week ago with HP9 when diff was 9.75. Allowing for some luck variation (which should be largely eliminated due to the high number of instances), I can say it is not twice as fast at finding blocks. I can't say how much faster it is without more testing, which I'm not doing as running those 500 instances is NOT profitable by a long way

My limited anecdotal experience suggests that same: it's not really ~100% improved mining. It sounds too good to be true anyway, but I'm sure the optimizations help somewhat. Out of curiosity how much did those 6 hours cost?

Also we would expect to see changes in network diff and blocks found if there was really such a huge improvement from HP10: http://192.241.170.170/ Instead we see this is not the case.

skaffen

full member

Activity: 124

Merit: 100

Quote from: Trillium on August 26, 2013, 05:13:02 AM

For example, what do you think would be faster:

A server with one dual-core AMD Opteron CPU @ 2.4 GHz

or,

A server with two physical intel Xeon CPUs, each single core, with hyper threading @ 3.6 GHz

As it turns out, the AMD will GREATLY outperform the intel CPUs.

I respectfully disagree, sir or madam. I believe Intel has been ahead in the CPU race since the core 2, or even the core duo, and since the i3/5/7, they have been getting further ahead. Including instructions per clock.

paulthetafy

hero member

Activity: 820

Merit: 1000

I'm fairly certain that HP10 does NOT find blocks at 2 x the rate of HP9, despite the 2 x increase in chains per day value. About an hour after HP10 came out I spun up 500 x 8 core VPS instances and ran them for 6 hours. That was ~1000 CPD. I'm aware that the diff is now rising which will skew things, but in that time I got about the same block rate (average 4 an hour) as I did when I last tested a week ago with HP9 when diff was 9.75. Allowing for some luck variation (which should be largely eliminated due to the high number of instances), I can say it is not twice as fast at finding blocks. I can't say how much faster it is without more testing, which I'm not doing as running those 500 instances is NOT profitable by a long way

cryptrol

hero member

Activity: 637

Merit: 500

Some stats for hp10 :

2 x Opteron 2376 = "chainsperday" : 2.54092020 <- Really old CPU
1 x Intel i7 3770K = "chainsperday" : 2.77305771

Still no blocks found though in almost 24h.

Hope others will share their stats so we can build a nice performance thread.

Trillium

hero member

Activity: 546

Merit: 500

Quote from: BChydro on August 26, 2013, 01:02:54 AM

I run 3 computers with shitty Athlon II X4 640s and together they seem to produce a block every 2 days using the latest hp client. Individually they seem to out perform my main computer with a mid level sandy bridge i5. Are AMD CPUs better for xpm mining?

Probably not. I will leave it to OP to confirm support for various instruction sets / types.

A lot of people think an AMD is 'better' than a intel CPU because they arn't aware that AMD CPUs complete more computational operations per cycle than intel CPUs. This allows them to do 'more work' in any period of time compared to a intel CPU, even one that has a faster frequency (GHz).

For example, what do you think would be faster:

A server with one dual-core AMD Opteron CPU @ 2.4 GHz

or,

A server with two physical intel Xeon CPUs, each single core, with hyper threading @ 3.6 GHz

As it turns out, the AMD will GREATLY outperform the intel CPUs.

---

In reality even comparing frequency is meaningless now. There are other important differences like bus / HT speed, cache size and allotment (shared or dedicated between cores etc).

I would recommend this page: http://www.cpubenchmark.net/cpu_list.php

as a reasonably good source of estimates for comparing CPUs. Be careful though: if you must make an important comparison (eg when buying things) then click the link of each CPU listed and check that the score is a good average of several submitted scores. CPUs with only a handful - or worse only one - submitted score can have huge score variances (20%+) and mislead you.

BChydro

hero member

Activity: 1426

Merit: 506

I run 3 computers with shitty Athlon II X4 640s and together they seem to produce a block every 2 days using the latest hp client. Individually they seem to out perform my main computer with a mid level sandy bridge i5. Are AMD CPUs better for xpm mining?

cabin

sr. member

Activity: 604

Merit: 250

Quote from: mikaelh on August 25, 2013, 06:16:16 PM

Well, you probably compiled a 32-bit version. I checked the instructions you linked. They are pointing towards the 32-bit version of MinGW. You need a MinGW-w64 compiler to produce 64-bit binaries. I haven't installed that on Windows so I can't really help you there.

ya both GMP and the whole project had to be using 32 bit compilers. GMP doesn't want to compile using the 64 bit compilers either.. so I guess it is not simple to switch at all. When you make a win64 binary do you just make it from Linux somehow?

If someone is knowledgeable about GMP on win64 this is the type of errors I get:

Code:

configure: summary of build options:
  Version: GNU MP 5.1.2
  Host type: x86_64-w64-mingw32
  ABI: 64
  Install prefix: /c/data/miner2/deps/gmp
  Compiler: gcc -std=gnu99
  Static libraries: yes
  Shared libraries: no

/c/data/miner2/deps/gmp-5.1.2
$ make
make all-recursive
make[1]: Entering directory `/c/data/miner2/deps/gmp-5.1.2'
Making all in tests
make[2]: Entering directory `/c/data/miner2/deps/gmp-5.1.2/tests'
Making all in .
make[3]: Entering directory `/c/data/miner2/deps/gmp-5.1.2/tests'
make[3]: Nothing to be done for `all-am'.

...

Making all in cxx
make[3]: Entering directory `/c/data/miner2/deps/gmp-5.1.2/tests/cxx'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/c/data/miner2/deps/gmp-5.1.2/tests/cxx'
make[2]: Leaving directory `/c/data/miner2/deps/gmp-5.1.2/tests'
Making all in mpn
make[2]: Entering directory `/c/data/miner2/deps/gmp-5.1.2/mpn'
/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fib_table | sed 's/_$//'` -O2
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -c -o fib_table.lo fib_t
able.c
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I
.. -DOPERATION_fib_table -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -marc
h=k8 -c fib_table.c -o fib_table.o
In file included from ../gmp-impl.h:135:0,
   from fib_table.c:4:
../fib_table.h:4:1: warning: data definition has no type or storage class [enabl
ed by default]
Error, error, this data is for 32 bits

mpir DOES compile in x64 and is similar.. I'll see if that can be substituted...

mikaelh

sr. member

Activity: 301

Merit: 250

Well, you probably compiled a 32-bit version. I checked the instructions you linked. They are pointing towards the 32-bit version of MinGW. You need a MinGW-w64 compiler to produce 64-bit binaries. I haven't installed that on Windows so I can't really help you there.

cabin

sr. member

Activity: 604

Merit: 250

Quote from: mikaelh on August 25, 2013, 05:47:35 PM

Quote from: cabin on August 25, 2013, 05:07:10 PM

Quote from: mikaelh on August 25, 2013, 11:07:29 AM

Quote from: cabin on August 25, 2013, 10:39:06 AM

Quote

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

I think I'm close to being able to build it. I've gone through all the steps from here:
https://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479

But I have a problem halfway through the compile with primecoin/src/compat.h

c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ws2tcpip.h:38:2: error
: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
In file included from compat.h:18:0,
   from netbase.h:11,
   from net.h:19,
   from rpcnet.cpp:7:

I tried commenting out:
//#include in compat.h

but that didn't work.

I think I had a similar issue with mingw64. Try adding -DWIN32_LEAN_AND_MEAN to the compiler flags. I think the cause of the issue was some boost header file including windows.h. If WIN32_LEAN_AND_MEAN is not defined, then winsock.h would also be included.

I can build primecoind, however the performance of my build is bad. There must be some compiler flags or other things that matter a lot. Here are rough results though:
mikaelh build, 9 chain sieve, chainsperday: 0.76 (Blocks per day: 0.152)
cabin build, 9 chain sieve, chainsperday: 0.40 (Blocks per day: 0.08)
cabin build, 10 chain sieve, chainsperday: 0.15 (Blocks per day: 0.15)

So there is a huge hit for sure to start sieving for 10 chains, but in terms of blocks per day it might be worth it.

Did you compile a 32-bit or 64-bit version? Where did you get your libgmp?

I got the source from here and compiled it myself:
http://ftp://ftp.gnu.org/gnu/gmp/gmp-5.1.2.tar.bz2

I'm embarrassed to say to I don't know if it is 32 or 64 bit.. it is whatever the default is in github

These build scripts aren't really my thing.. is it easy to find out and change? I've got -march=i686 in the CFLAGS but that was to fix something else and I don't think that's it.

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: cabin on August 25, 2013, 05:07:10 PM

Quote from: mikaelh on August 25, 2013, 11:07:29 AM

Quote from: cabin on August 25, 2013, 10:39:06 AM

Quote

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

I think I'm close to being able to build it. I've gone through all the steps from here:
https://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479

But I have a problem halfway through the compile with primecoin/src/compat.h

c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ws2tcpip.h:38:2: error
: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
In file included from compat.h:18:0,
   from netbase.h:11,
   from net.h:19,
   from rpcnet.cpp:7:

I tried commenting out:
//#include in compat.h

but that didn't work.

I think I had a similar issue with mingw64. Try adding -DWIN32_LEAN_AND_MEAN to the compiler flags. I think the cause of the issue was some boost header file including windows.h. If WIN32_LEAN_AND_MEAN is not defined, then winsock.h would also be included.

I can build primecoind, however the performance of my build is bad. There must be some compiler flags or other things that matter a lot. Here are rough results though:
mikaelh build, 9 chain sieve, chainsperday: 0.76 (Blocks per day: 0.152)
cabin build, 9 chain sieve, chainsperday: 0.40 (Blocks per day: 0.08)
cabin build, 10 chain sieve, chainsperday: 0.15 (Blocks per day: 0.15)

So there is a huge hit for sure to start sieving for 10 chains, but in terms of blocks per day it might be worth it.

Did you compile a 32-bit or 64-bit version? Where did you get your libgmp?

Trillium

hero member

Activity: 546

Merit: 500

Random tip if you have more than one machine and if your client wont sync. Just use

Code:

addnode add

And it will begin to sync within a few seconds. Port not required in my experience..

cabin

sr. member

Activity: 604

Merit: 250

Quote from: mikaelh on August 25, 2013, 11:07:29 AM

Quote from: cabin on August 25, 2013, 10:39:06 AM

Quote

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

I think I'm close to being able to build it. I've gone through all the steps from here:
https://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479

But I have a problem halfway through the compile with primecoin/src/compat.h

c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ws2tcpip.h:38:2: error
: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
In file included from compat.h:18:0,
   from netbase.h:11,
   from net.h:19,
   from rpcnet.cpp:7:

I tried commenting out:
//#include in compat.h

but that didn't work.

I think I had a similar issue with mingw64. Try adding -DWIN32_LEAN_AND_MEAN to the compiler flags. I think the cause of the issue was some boost header file including windows.h. If WIN32_LEAN_AND_MEAN is not defined, then winsock.h would also be included.

I can build primecoind, however the performance of my build is bad. There must be some compiler flags or other things that matter a lot. Here are rough results though:
mikaelh build, 9 chain sieve, chainsperday: 0.76 (Blocks per day: 0.152)
cabin build, 9 chain sieve, chainsperday: 0.40 (Blocks per day: 0.08)
cabin build, 10 chain sieve, chainsperday: 0.15 (Blocks per day: 0.15)

So there is a huge hit for sure to start sieving for 10 chains, but in terms of blocks per day it might be worth it.

elvisrene

sr. member

Activity: 252

Merit: 250

mikaelh,Aggrophobia

Thanks guys for helping me out +1 for both of you got it working

elvisrene

sr. member

Activity: 252

Merit: 250

Quote from: Aggrophobia on August 25, 2013, 12:13:07 PM

Quote from: mikaelh on August 25, 2013, 11:59:21 AM

Quote from: elvisrene on August 25, 2013, 11:50:29 AM

mikaelh i cant sync wallet it shows no connections i have tried all do i need to do a config file in appdata/primecoin

My best guess at this point is that you're behind a strict firewall/proxy. If it's your own firewall, adjust it. If not, there's not much that can be done about it.

Q: How do I solve a problem with the client not being able to synchronize or connect to any nodes?
A: Try adding this line to your primecoin.conf file:
Code:

seednode=primeseed.muuttuja.org

And it will work

you see theres also a problem i know where to do the config file i just dont know what to put there

Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 31. (Read 397645 times)