Bitcoin Forum
July 20, 2017, 10:54:33 PM *
News: Are you prepared for Aug 1 / BIP148?
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: Wolf's XMR/BCN/DSH CPUMiner - 2x speed compared to LucasJones' - NEW 06/20/2014  (Read 336673 times)
sleepdog
Full Member
***
Offline Offline

Activity: 166


View Profile
July 10, 2014, 12:57:03 PM
 #401

Similar results here. I ran some tests with a dual E5520 server.

cpu-multi / LucasJones (these are the same thing, right?) v2.3.3 gets max 148 H/s and is pretty much always over 140.

Wolf's newly provided non-AES version gets 118 H/s max, with a range of 100 - 118.

Looks like any advantages of Wolf's miner come from the AES-NI code.
Decentralized search
Search for products or services and get paid for it
Join pre-ICO
25 July. 50% discount
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 10, 2014, 01:43:26 PM
 #402

Similar results here. I ran some tests with a dual E5520 server.

cpu-multi / LucasJones (these are the same thing, right?) v2.3.3 gets max 148 H/s and is pretty much always over 140.

Wolf's newly provided non-AES version gets 118 H/s max, with a range of 100 - 118.

Looks like any advantages of Wolf's miner come from the AES-NI code.

Lucas' code has AES-NI, as well. What OS?

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
sleepdog
Full Member
***
Offline Offline

Activity: 166


View Profile
July 10, 2014, 02:07:19 PM
 #403

I meant that if yours is quicker than his on AES-NI systems it must be down to that part of the code that uses AES-NI.

I'm running 2008 R2 Enterprise.
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 10, 2014, 03:06:55 PM
 #404

I meant that if yours is quicker than his on AES-NI systems it must be down to that part of the code that uses AES-NI.

I'm running 2008 R2 Enterprise.

Nah, your problem is Windows. My AES-NI miner is faster than his on Windows and Linux. My non-AES-NI miner is only faster than his on Linux, I believe.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
ajiekceu4
Jr. Member
*
Offline Offline

Activity: 33


View Profile
July 11, 2014, 10:39:42 PM
 #405

Download links broken. (ottrbutt.com and 46.105.182.112 didn't response).
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 12, 2014, 02:58:17 AM
 #406

Download links broken. (ottrbutt.com and 46.105.182.112 didn't response).

Fixed - and had my VPS provider whipped. >.<

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
primer-
Legendary
*
Offline Offline

Activity: 994



View Profile
July 12, 2014, 09:50:34 AM
 #407

I'm getting different results when running the miner on all threads vs only physical cores.

On newer CPUs i'm getting up to 50% more power when running only on physical cpu cores. On older CPUs (also with AES) i get 50% less when using only physical cores.
Why is this ?

Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 12, 2014, 09:04:51 PM
 #408

I'm getting different results when running the miner on all threads vs only physical cores.

On newer CPUs i'm getting up to 50% more power when running only on physical cpu cores. On older CPUs (also with AES) i get 50% less when using only physical cores.
Why is this ?



That isn't obvious? Newer CPUs tend to be faster, and I don't mean in terms of clock speeds. They improve shit like out of order execution, speculative execution, branch prediction...

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
primer-
Legendary
*
Offline Offline

Activity: 994



View Profile
July 12, 2014, 09:19:12 PM
 #409

I'm getting different results when running the miner on all threads vs only physical cores.

On newer CPUs i'm getting up to 50% more power when running only on physical cpu cores. On older CPUs (also with AES) i get 50% less when using only physical cores.
Why is this ?



That isn't obvious? Newer CPUs tend to be faster, and I don't mean in terms of clock speeds. They improve shit like out of order execution, speculative execution, branch prediction...

I think you misunderstood my post, example below :

dual E5-2620 (12 cores/24 threads)

-t 23 (default when run without -t tag) does around 310H/s
-t 12 (physical cores) does around 390H/s

Dual E5620 (8 cores/16 threads)
-t 15 (default when run without -t tag) does around 150H/s
-t 8  (physical cores) does around 100H/s

EDIT:Dual E5620 figures might not be correct, i performed tests earlier today (couple hours) and no longer have access. Difference was 50%
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 12, 2014, 09:25:15 PM
 #410

I'm getting different results when running the miner on all threads vs only physical cores.

On newer CPUs i'm getting up to 50% more power when running only on physical cpu cores. On older CPUs (also with AES) i get 50% less when using only physical cores.
Why is this ?



That isn't obvious? Newer CPUs tend to be faster, and I don't mean in terms of clock speeds. They improve shit like out of order execution, speculative execution, branch prediction...

I think you misunderstood my post, example below :

dual E5-2620 (12 cores/24 threads)

-t 23 (default when run without -t tag) does around 310H/s
-t 12 (physical cores) does around 390H/s

Dual E5620 (8 cores/16 threads)
-t 15 (default when run without -t tag) does around 150H/s
-t 8  (physical cores) does around 100H/s

EDIT:Dual E5620 figures might not be correct, i performed tests earlier today (couple hours) and no longer have access. Difference was 50%

Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
primer-
Legendary
*
Offline Offline

Activity: 994



View Profile
July 12, 2014, 09:28:21 PM
 #411


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).

Rytir_fik
Full Member
***
Offline Offline

Activity: 139


View Profile
July 12, 2014, 09:38:01 PM
 #412


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).



In case you use it for CryptoNight hash algorithm then the answer could be this. CryptoNight hash algorithm requires 2 MB of cache for each of the mining threads. In my case of i5-2500K with 4 cores and 6MB I am able to use only -t 3 properly, so any additional thread (over 3) will only slow the process down.

I like Bytecoin (BCN). BYTECOIN.ORG the best to mine with MinerGate
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 12, 2014, 11:27:36 PM
 #413

Updated readme.md and added some stuff to the OP.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Rytir_fik
Full Member
***
Offline Offline

Activity: 139


View Profile
July 13, 2014, 08:31:17 AM
 #414


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).



in one i5 laptop I get more hashes with -t 1 than with -t 3, for aes-ni cpus less threads means more performance.

Of course it could be correct. In case you have only 3MB cache memory on your processor then the -t 1 will be faster (see my previous post  with explanation). How much memory your processor has you can check eg. here: http://ark.intel.com/products/family/75024/4th-Generation-Intel-Core-i5-Processors#@All

I like Bytecoin (BCN). BYTECOIN.ORG the best to mine with MinerGate
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 13, 2014, 09:33:17 AM
 #415


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).



in one i5 laptop I get more hashes with -t 1 than with -t 3, for aes-ni cpus less threads means more performance.

Of course it could be correct. In case you have only 3MB cache memory on your processor then the -t 1 will be faster (see my previous post  with explanation). How much memory your processor has you can check eg. here: http://ark.intel.com/products/family/75024/4th-Generation-Intel-Core-i5-Processors#@All

Makes a lot of sense. There's no reason why you couldn't run more threads, but it would run a lot slower since it has to traipse out to main memory for the scratchpad all the damned time... but I wonder if the hardware prefetcher is smart enough to get that it should probably stuff the whole scratchpad in cache?

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Rytir_fik
Full Member
***
Offline Offline

Activity: 139


View Profile
July 13, 2014, 01:08:13 PM
 #416


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).



in one i5 laptop I get more hashes with -t 1 than with -t 3, for aes-ni cpus less threads means more performance.

Of course it could be correct. In case you have only 3MB cache memory on your processor then the -t 1 will be faster (see my previous post  with explanation). How much memory your processor has you can check eg. here: http://ark.intel.com/products/family/75024/4th-Generation-Intel-Core-i5-Processors#@All

Makes a lot of sense. There's no reason why you couldn't run more threads, but it would run a lot slower since it has to traipse out to main memory for the scratchpad all the damned time... but I wonder if the hardware prefetcher is smart enough to get that it should probably stuff the whole scratchpad in cache?


I do not know how exactly it works but this is one of the reasons why CryptoNight is declared as Only CPU-mining & ASIC-resistant. I am noob,  I posted here  information which I got from devs of BCN as you can see my Question on Github (because I thought that this is bug) https://github.com/amjuarez/bytecoin/issues/23.
 .... and Wolfi thx for the miner in my case of i5-2500K @ 4.3 is about 15% faster (v. 05-30-2014) than Minergare client (v3.0) (on Minergate pool) Wink

I like Bytecoin (BCN). BYTECOIN.ORG the best to mine with MinerGate
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 13, 2014, 01:15:28 PM
 #417


Oh, I see. Odd... maybe the older CPUs did hyperthreading better?

Maybe. Newer CPUs definitely dont like the default -t option.

I'm also getting a %10-%20 difference on a i7 4770 (210-230 when using -t 7 compared to 265-280 when using -t 4).



in one i5 laptop I get more hashes with -t 1 than with -t 3, for aes-ni cpus less threads means more performance.

Of course it could be correct. In case you have only 3MB cache memory on your processor then the -t 1 will be faster (see my previous post  with explanation). How much memory your processor has you can check eg. here: http://ark.intel.com/products/family/75024/4th-Generation-Intel-Core-i5-Processors#@All

Makes a lot of sense. There's no reason why you couldn't run more threads, but it would run a lot slower since it has to traipse out to main memory for the scratchpad all the damned time... but I wonder if the hardware prefetcher is smart enough to get that it should probably stuff the whole scratchpad in cache?


I do not know how exactly it works but this is one of the reasons why CryptoNight is declared as Only CPU-mining & ASIC-resistant. I am noob,  I posted here  information which I got from devs of BCN as you can see my Question on Github (because I thought that this is bug) https://github.com/amjuarez/bytecoin/issues/23.
 .... and Wolfi thx for the miner in my case of i5-2500K @ 4.3 is about 15% faster (v. 05-30-2014) than Minergare client (v3.0) (on Minergate pool) Wink

CN is not only CPU mining by a long shot. GPUs will be able to do better than CPUs - in fact, they already do. BBR, on the other hand, might be actually GPU-resistant. That totally fucked blockchain-in-mah-scratchpad thing causes an ouch slow copy from host memory to GPU memory very often. On top of that, I don't think you can interrupt kernels sometimes - so you'd have to wait for the kernel to finish wasting its time hashing old data.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
cayars
Full Member
***
Offline Offline

Activity: 168


View Profile
July 13, 2014, 02:11:27 PM
 #418

CN is not only CPU mining by a long shot. GPUs will be able to do better than CPUs - in fact, they already do. BBR, on the other hand, might be actually GPU-resistant. That totally fucked blockchain-in-mah-scratchpad thing causes an ouch slow copy from host memory to GPU memory very often. On top of that, I don't think you can interrupt kernels sometimes - so you'd have to wait for the kernel to finish wasting its time hashing old data.

Nope BBR is not GPU resistant and is being mined with GPUs.
Wolf0
Legendary
*
Offline Offline

Activity: 1624


Miner Developer


View Profile
July 13, 2014, 03:16:39 PM
 #419

CN is not only CPU mining by a long shot. GPUs will be able to do better than CPUs - in fact, they already do. BBR, on the other hand, might be actually GPU-resistant. That totally fucked blockchain-in-mah-scratchpad thing causes an ouch slow copy from host memory to GPU memory very often. On top of that, I don't think you can interrupt kernels sometimes - so you'd have to wait for the kernel to finish wasting its time hashing old data.

Nope BBR is not GPU resistant and is being mined with GPUs.

Yes, it's being mined with GPUs. But the GPU implementation is slower than a good CPU one.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
cayars
Full Member
***
Offline Offline

Activity: 168


View Profile
July 13, 2014, 05:45:56 PM
 #420

CN is not only CPU mining by a long shot. GPUs will be able to do better than CPUs - in fact, they already do. BBR, on the other hand, might be actually GPU-resistant. That totally fucked blockchain-in-mah-scratchpad thing causes an ouch slow copy from host memory to GPU memory very often. On top of that, I don't think you can interrupt kernels sometimes - so you'd have to wait for the kernel to finish wasting its time hashing old data.

Nope BBR is not GPU resistant and is being mined with GPUs.

Yes, it's being mined with GPUs. But the GPU implementation is slower than a good CPU one.

Let's just say I'll respectfully disagree. Smiley
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!