I just improved quark on r74. Do you want it?
1.5.74-jdd+
What did you do? Exactly what I told you. You can have it if you open some of you private stash. Release 78 is faster. Want me to do 78 too? Yes I want you to do +30% when is the last time you delivered 30% in less than an hour? |
|
|
|
I just improved quark on r74. Do you want it?
1.5.74-jdd+
What did you do? Exactly what I told you. You can have it if you open some of you private stash. Release 78 is faster. Want me to do 78 too? |
|
|
|
I just improved quark on r74. Do you want it?
1.5.74-jdd+
What did you do? Exactly what I told you. You can have it if you open some of you private stash. |
|
|
|
I just improved quark on r74. Do you want it? 1.5.74-jdd+ [2016-01-27 19:00:14] accepted: 33/33 (100.00%), 34643 kH/s yes!
[2016-01-27 19:00:18] GPU #0: GeForce GTX 970, 17825
[2016-01-27 19:00:18] accepted: 34/34 (100.00%), 34643 kH/s yes!
[2016-01-27 19:00:19] GPU #1: GeForce GTX 970, 17134
[2016-01-27 19:00:19] accepted: 35/35 (100.00%), 34660 kH/s yes!
[2016-01-27 19:00:22] GPU #1: GeForce GTX 970, 17085
[2016-01-27 19:00:22] accepted: 36/36 (100.00%), 34673 kH/s yes!
[2016-01-27 19:00:28] GPU #1: GeForce GTX 970, 17114
[2016-01-27 19:00:28] accepted: 37/37 (100.00%), 34686 kH/s yes!
[2016-01-27 19:00:29] GPU #0: GeForce GTX 970, 17719
[2016-01-27 19:00:29] accepted: 38/38 (100.00%), 34682 kH/s yes!
1.5.74-SP [2016-01-27 19:02:07] accepted: 19/19 (100.00%), 33334 kH/s yes!
[2016-01-27 19:02:08] GPU #0: GeForce GTX 970, 17793
[2016-01-27 19:02:08] accepted: 20/20 (100.00%), 33486 kH/s yes!
[2016-01-27 19:02:11] GPU #1: GeForce GTX 970, 17146
[2016-01-27 19:02:11] accepted: 21/21 (100.00%), 33482 kH/s yes!
[2016-01-27 19:02:12] GPU #1: GeForce GTX 970, 17139
[2016-01-27 19:02:12] accepted: 22/22 (100.00%), 33478 kH/s yes!
You should have told the truth. |
|
|
|
4% boost in quark coming due to implementation of fast reinit_groestl. Maybe it
will work in ccminer too. It' was simple, just clone init_groestl and remove the constant
initializations. It speeds up the init every time groestl is run. Just make sure to do
a full init the first time.
ccminer only to the init pass once per algo. Until it finds a solution for all the hashfunctions Edit: only worked for quark because quark runs twice in the chain. Only need to do a
reinit before the second run. Full init works but is slower. No init is even faster but
never finds blocks.
ccminer only run groestl once. In cpuminer it only appears once in the code but it runs twice.
Why don't you share your code on github so I can add 100%  [/quote] You can get it from google drive, help yourself. I do intend to get on github when things settle down. There are lots of algos that need AES_NI implementations, so far only groestl and echo. A couple more have SSE2 and the rest are dead slow. Wolf's cryptonight is nice. CPU runs cool and performance is higher than the other algos when compared with ccminer. For mining XMR a CPU is better. |
|
|
|
Why is c11 slower than x11?
I haven't been able to integrate the groestl AES_NI optimizations yet. I'm having that problem with many algos that use groestl. Only x11 and quark are working. It could do wonders on some other algos especially groestl itself. If I can get it working it coould be a 100% boost. 4% boost in quark coming due to implementation of fast reinit_groestl. Maybe it will work in ccminer too. It' was simple, just clone init_groestl and remove the constant initializations. It speeds up the init every time groestl is run. Just make sure to do a full init the first time. Edit: only worked for quark because quark runs twice in the chain. Only need to do a reinit before the second run. Full init works but is slower. No init is even faster but never finds blocks. Some of my improvements have come from optimizing the ctx init, avoiding doing it for nothing. I haven't looked a ccminer but there may be opportunities there. If it works for you don't forget where you got the idea.  |
|
|
|
I found my hash!
X11 back up to peak, it has been down a bit for as couple of releases but it's back.
I also restored cryptonight performance to the same level as Wolf0.
v3.0.6 should be the best release yet, the most algos, the highest performance
and the widest HW support.
It's baking in the oven.
This out turned out well. I'm running out of excused to delay windows support. https://drive.google.com/file/d/0B0lVSGQYLJIZSmFXUnZrdDFkTjg/view?usp=sharingEdit: It has been observed that better performance is achieved when using the CPU name instead of native for the arch argument. It doesn't seem to work for more recent CPU, the only accepte dvalue is corei7-avx, rather than haswell, sandybridge etc. On older CPUs such as the core2 it may make a difference. YMMV Just when I thought there was no more optimising to do I found 4% more in quark. I'll see if it works on other algos. |
|
|
|
I found my hash!
X11 back up to peak, it has been down a bit for as couple of releases but it's back.
I also restored cryptonight performance to the same level as Wolf0.
v3.0.6 should be the best release yet, the most algos, the highest performance
and the widest HW support.
It's baking in the oven.
This out turned out well. I'm running out of excused to delay windows support. https://drive.google.com/file/d/0B0lVSGQYLJIZSmFXUnZrdDFkTjg/view?usp=sharingEdit: It has been observed that better performance is achieved when using the CPU name instead of native for the arch argument. It doesn't seem to work for more recent CPU, the only accepte dvalue is corei7-avx, rather than haswell, sandybridge etc. On older CPUs such as the core2 it may make a difference. YMMV |
|
|
|
|
I found my hash!
X11 back up to peak, it has been down a bit for as couple of releases but it's back.
I also restored cryptonight performance to the same level as Wolf0.
v3.0.6 should be the best release yet, the most algos, the highest performance
and the widest HW support.
It's baking in the oven.
|
|
|
|
Thanks Joblo, I'll test release 3.0.5 later today :-)
I'm noticing cryptonight is about 10% slower than Wolf0's build. Let me know if you can confirm it. I only made two significant changes that shouldn't have had such an impact. Edit: never mind I found it. Will wait a while before a new release in case something else pops up. |
|
|
|
|
I am about to drop support for x86_64 target for two reasons. There is only one generation
of Intel 64 bit CPU it applies to no one has expressed an interest in it.
The x86_64 kernels will live on in cpuminer-multi and I will maintain the x86_64 kernels
ifthey are the best available for a particular algo.. Wil like be dropped in he next release.
|
|
|
|
Tossed away everything I had done with cryptonight and started form scratch.
It took 2 hours to get my first share 180 KH/s.
V3.0.4 coming right up.
Done
Edit: Thanks Wolf0
Edit: I may have overstated the hash rate, more like 170.
I think the addition of cryptonight broke the core2 compile. I've disabled the download link for now. Edit: v3.0.5 https://drive.google.com/file/d/0B0lVSGQYLJIZTXdKVHNpdGRuTW8/view?usp=sharing |
|
|
|
I there folks. I'm a complete noob when it comes to altcoins bitcoins and such but I do have some computer knowledge. I was wondering if I could start mining some altcoin, because from what i've seen it isn't worth to mine bitcoins with cpu or gpu.
So do you have any suggestions for me?
It depends on what you mean by worth it. If all you want is to make money forget it. But if you want to join the altcoin comunity thenby all means. |
|
|
|
|
Tossed away everything I had done with cryptonight and started form scratch.
It took 2 hours to get my first share 180 KH/s.
V3.0.4 coming right up.
Done
Get v3.0.5
Edit: Thanks Wolf0
Edit: I may have overstated the hash rate, more like 170.
|
|
|
|
Honestly I don't think it makes any noticeable difference.
Initialisation is a very little part of the whole hash computation.
I found a measurable difference (<1%) taking the initialisation out of the loop especially the longer chains with many ctxs to manage. I expect this to have even less. Low priority, I've got better things to work on. |
|
|
|
|
InteI GPU mining with cgminer.
I got the source compiled and it too only does blake256. I tried it and got all rejects
on blake but it works on blakecoin, woopee. But wait, it's not mining with the IGPU
but with my Nvidia GPUs. Crap.
A device query doesn't find the Intel IGPU.
Thoughts?
|
|
|
|
|
I owuld open discussion with devs and dev wannabes regarding initializing structs.
It may be trivial but considering my inexperience with c/c++ I'm not clear and
a couple of points.
initializing of contexts is a frequent thing in cpuminer and is done by assigning
each field one by one, very inefficient.
There are some shortcuts where a copy if an initialized contex is saved and used
to reinitialze using memcpy, much more efficient.
However I am considering whether assigning a nul version of the struct would be
better.
Ex:
typedef struct {blah, blah,blah} ctx_t;
// init null_ctx at compile time
const ctx_t null_ctx = { null_blah, null_blah, null_blah };
// init my_ctx at run time
ctx_t my_ctx = null_ctx;
Am I on the right track? It might not beat memset but it can handle
non-zero null fields.
|
|
|
|
|
Time for another story.
The company I worked for produced lage scale mission critical control systems
to institutional customers. They had an emergency response team that provided
24 hour service with a guarantee the customer was talking to an engineer within
5 minutes of the initial call.
The training for this team was interesting and included getting a call from a senior
engineer posing as a cleaner.
He would call and report that hes just a cleaner working near the computer room
and heard alarms. He went into the room and saw a poster with the phone number
to call in case of an emergency.
You can imagine how it went from there. It even involved getting the cleaner to change
circuit packs. One particular trainer would exploit any ambiguity or imprecision in the
instructions to deliverately do the wrong thing. Lots of fun.
|
|
|
|
a little speedup by better compiling:
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
AES_NI: No.
SSE2: No, start mining without optimizations...
[....]
[2016-01-26 13:39:37] accepted: 7/7 (100.00%), 224.92 kH/s yes!
about 5-10% more by using this commandline (to be adapted to your own cpu):
./configure CFLAGS="-march=nehalem -Ofast -DNO_AES_NI" CXXFLAGS=$CFLAGS --with-crypto --with-curl
and remember to "make clean"
Think any of this would help me to get a completion compile on the problem AMD system I posted about a few pages back? https://bitcointalk.org/index.php?topic=1326803.msg13657053#msg13657053the cpu doesn't look to have AES: did you try compiling with -DNO_AES_NI? I just tried that and still get errors. maybe someone could help me on this one I'm a real noob with this stuff. ./configure CFLAGS="-march=?  ?? -Ofast" CXXFLAGS=$CFLAGS --with-crypto --with-curl ?? Processors Information
-------------------------------------------------------------------------
Processor 1 ID = 0
Number of cores 8 (max 8)
Number of threads 8 (max 8)
Name AMD Opteron 6124
Codename Magny-Cours
Specification AMD Opteron(tm) Processor 6124 HE
Package Socket G34 (1974)
CPUID F.9.1
Extended CPUID 10.9
Core Stepping HY-D1
Technology 45 nm
TDP Limit 74.4 Watts
Core Speed 1039.8 MHz
Multiplier x Bus Speed 4.0 x 259.9 MHz
HT Link speed 2859.4 MHz
Stock frequency 1800 MHz
Instructions sets MMX (+), 3DNow! (+), SSE, SSE2, SSE3, SSE4A, x86-64, AMD-V
L1 Data cache 8 x 64 KBytes, 2-way set associative, 64-byte line size
L1 Instruction cache 8 x 64 KBytes, 2-way set associative, 64-byte line size
L2 cache 8 x 512 KBytes, 16-way set associative, 64-byte line size
L3 cache 10 MBytes, 96-way set associative, 64-byte line size
FID/VID Control yes
FID range 4.0x - 9.0x
Max VID 1.050 V
# of P-States 5
P-State FID 0x2 - VID 0x2F - IDD 6 (9.00x - 0.962 V)
P-State FID 0x0 - VID 0x31 - IDD 6 (8.00x - 0.937 V)
P-State FID 0x10A - VID 0x34 - IDD 5 (6.50x - 0.900 V)
P-State FID 0x106 - VID 0x35 - IDD 4 (5.50x - 0.887 V)
P-State FID 0x100 - VID 0x37 - IDD 4 (4.00x - 0.862 V)
Package Type 0x3
Model 25
String 1 0x0
String 2 0x0
Page 0x0
CmpCap 8
ApicIdCoreSize 16
TDC Limit 48 Amps
Boosted P-States 0
Max non-turbo ratio 9.00x
Max turbo ratio 9.00x
Max CPU COF 18
Core Performance Boost no
P-State 0, FID 0x2 - VID 0x2F (9.00x - 0.962 V)
P-State 1, FID 0x0 - VID 0x31 (8.00x - 0.937 V)
P-State 2, FID 0x10A - VID 0x34 (6.50x - 0.900 V)
P-State 3, FID 0x106 - VID 0x35 (5.50x - 0.887 V)
P-State 4, FID 0x100 - VID 0x37 (4.00x - 0.862 V)
Attached device PCI device at bus 0, device 24, function 0
Attached device PCI device at bus 0, device 24, function 1
Attached device PCI device at bus 0, device 24, function 2
Attached device PCI device at bus 0, device 24, function 3
Attached device PCI device at bus 0, device 24, function 4
TSC 2339.8 MHz
Temperature 0 29°C (84°F) [0xE8] (Core #0)
Power 0 27.60 W (Package) First post your console session with your command line and error messages. * And stick with the instructions in the READme.md file. You've got an AMD Opteron 64 so try to find a match https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html* I can be prickly, so be careful with your questions, This is your first warning. I'm not trying to be mean, it just happens, so don't take it personally. Well formulated questions with supporting data and a demonstration you did your best to solve it will always get the best response (and not just from me). Getting closer it does start but hangs at checking the CPU. h8qg6@h8qg6-VirtualBox:~/Downloads/cpuminer-opt-3.0.3$ ./cpuminer -a x11 -o stratum+tcp://x11.usa.nicehash.com:3336 -u 18tvS3deKZK5q4eTtPRWYeEMWmGmuErHgz.H8QG6 -p d=0.01 -t 1
********** cpuminer-opt v3.0.3 ***********
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi-1.2pre with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0 and Jeff Garzik.
Only quark and qubit support SSE at this time. Whenever mining
other algos with an SSE2 capable CPU the generic x86_64 miner
will be used.
Checking CPU capatibility...
Ok now I have something towork with. I have a workaround that requires some code changes. I will explain the changes in detail so you shouldn't have any problems. First backup the original. Edit file cpu-miner.c and make the folllwing changes to block the actual check and hard code the result. Replace any calls to has_aesni(), has_sse2 with true There might be a couple of each. ex: change "cpu_aesni = has_aesni();" to "cpu_aesni = true;" You can also set each one to false if the feature isn't supported but try true for both to start. remove the call to "check_cpu_capability()" on line 3157. Just delete the line. Save, compile and run. Let me know how it goes. Edit:It seems your CPU does not have AES_NI to you will likely have to set cpu_aesni to false in cpu-miner.c and use -DNO_AES_NI. |
|
|
|
|
Show Posts
