Bitcoin Forum
May 28, 2018, 04:29:49 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 ... 190 »
  Print  
Author Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner  (Read 408694 times)
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 14, 2016, 07:45:10 PM
 #461

I never heard of LTO before, what will it give me? Is that how boost now works with your changes?

Can you explain the __attribute__ used stuff a bit more, that's a new concept for me. Again, it worked before so how is this better?
This is link-time optimization. Same way what Microsoft does under the "whole program optimization" name.

This lets the compiler see how each function is used by other functions and optimize more aggressively since it knows about all functions, this can mean that the optimizer can skip some work done since it's not needed by the program as a whole.

__attribute__((used)) is needed to fix compilation errors when using LTO wih gcc -- gcc is late to the party when adding LTO/whole program optimization, so there are still some kinks to be ironed out -- the LTO optimizer tends to disregard pure-assembler functions, so they need to be marked as used by the program, otherwise they'll be thrown away at one of the passes before the linking happens. Same applies to static variables defined in headers.

Boost didn't work for me until I added the linking options to the makefile. Are your changes leading edge?
Will they work on older loads?

I did remove the need for boost in hodlcoin after I posted that comment, I did not intend the changes to be visible by you (yet) -- The proper diff URLs are:
 * https://github.com/hmage/cpuminer-opt/compare/75db804...d01b290 -- UI
 * https://github.com/hmage/cpuminer-opt/compare/75db804...d01b290.diff -- raw diff

I implemented __AES__ with a slight change, I allow configure to override automatic aes compile, not very useful
for users but it helps testing SSE2 on my i7.

There's no need for that, you can just put -march=core2 instead of -march=native.


There are still problems with build.sh. First groestl sse2 complained about ASM constraints so I removed USE_ASM
then a bunch of AES code failed to compile, then I stripped it down to "-O3 -march=native" and it works.

Again, you're seeing LTO problems mentioned above, for the reasons mentioned above. The proper diff URL builds cleanly on core2 and haswell.

I didn't see a point in changing the way boost was linked, it doesn't make compiling any easier and it ain't broke.
That's part of changes to get rid of boost.

Quote from: joblo
I have a small issue with compiler warnings for using undefined functions. It has to do with algo-gate.
In C you have to tell the compiler what the function declaration looks like before you use the function, what happens next is undefined behaviour and thankfully on intel linux with gcc this doesn't break anything.

You have to put a function prototype in a header -- the dev needs to add a mention of the function in 3 places -- the header, the body, and the place that calls it. Since this doesn't happen often, I don't think it's a big deal.

Strange though that you didn't see any kind of these warnings before, probably MS Visual C defaults to not show this specific warning (and because MS has to worry only about making developer's sourcecode work only Intel Windows anyway).

There's no way to do what you want portably that works on both MSVC and GCC without requiring a function prototype in a header. Linux kernel relies on Linux-specific assembler code (.init) to do their module system without forcing everyone to list all function prototypes in one place.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1527481789
Hero Member
*
Offline Offline

Posts: 1527481789

View Profile Personal Message (Offline)

Ignore
1527481789
Reply with quote  #2

1527481789
Report to moderator
1527481789
Hero Member
*
Offline Offline

Posts: 1527481789

View Profile Personal Message (Offline)

Ignore
1527481789
Reply with quote  #2

1527481789
Report to moderator
1527481789
Hero Member
*
Offline Offline

Posts: 1527481789

View Profile Personal Message (Offline)

Ignore
1527481789
Reply with quote  #2

1527481789
Report to moderator
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 14, 2016, 08:06:33 PM
 #462


[snipped]


Thanks for the detailed explanation, it'll take a while to digest it. In the meantime you can take
a look at the latest release, I implemented some of your suggestions (forgot to credit you, need to fix that)
in v3.1.14. I do the initial __AES__ check in miner.h and you can see a good example of how I use it in
cpu-miner.c:cpu_capabilities_check.

One thing I immediately infered from your response is I need to use LTO to get Windows working
(and I sense you are working on that, if so thanks) and I need to clean up boost and implied function
declarations to get LTO working. That is plenty justification to do it. I look forward to seeing that cake
when it's fully baked.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 14, 2016, 11:17:05 PM
 #463


This is link-time optimization. Same way what Microsoft does under the "whole program optimization" name.

This lets the compiler see how each function is used by other functions and optimize more aggressively since it knows about all functions, this can mean that the optimizer can skip some work done since it's not needed by the program as a whole.

That seems very worthwhile to do if it gets windows Working. If is requires extra work for devs to maintain a master list of
function declarations, so be it. I'll have to find a way to make it work.

I implemented __AES__ with a slight change, I allow configure to override automatic aes compile, not very useful
for users but it helps testing SSE2 on my i7.

There's no need for that, you can just put -march=core2 instead of -march=native.


I think there is. Even with "-march=core2 -DNO_AES_NI" the __AES__ var is still defined. It is based
on the architecture of the CPU, not the compiled app.

Thanks again for your contributions and I look forward to what you have planned next.


cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 15, 2016, 02:04:08 AM
 #464

That seems very worthwhile to do if it gets windows Working.

Fixing LTO to work on GCC/Linux has nothing to do with making it work for MSVC/Windows. If anything, I don't have Windows here to test so it might be actually breaking Windows build.

I think there is. Even with "-march=core2 -DNO_AES_NI" the __AES__ var is still defined.

It depends on -march:
Code:
hmage@dhmd:~$ echo '' | gcc -E -dD -march=core2 -|grep __AES__|wc -l
0
hmage@dhmd:~$ echo '' | gcc -E -dD -march=haswell -|grep __AES__|wc -l
1

If you're seeing __AES__ macro defined when you're using -march=core2, then you have wrong build flags or unclean build.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 02:21:04 AM
 #465

I think there is. Even with "-march=core2 -DNO_AES_NI" the __AES__ var is still defined.

It depends on -march:
Code:
hmage@dhmd:~$ echo '' | gcc -E -dD -march=core2 -|grep __AES__|wc -l
0
hmage@dhmd:~$ echo '' | gcc -E -dD -march=haswell -|grep __AES__|wc -l
1

If you're seeing __AES__ macro defined when you're using -march=core2, then you have wrong build flags or unclean build.

Hmmm, I should retest, maybe I actually used "-march=native -DNO_AES_NI". I'm hoping I'm right
because it enables detection of an AES_NI cross compiled build being run on a non-AES_NI CPU. Although
very unlikely to occur it also adds a safety net in case bugs creep in, and that kind of design was part of my
past professional life.

Edit: if __AES__ doesn't reflect the HW arch I can go back to has_aes_ni() from cpuid.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 15, 2016, 02:40:35 AM
 #466

Hmmm, I should retest, maybe I actually used "-march=native -DNO_AES_NI". I'm hoping I'm right
because it enables detection of an AES_NI cross compiled build being run on a non-AES_NI CPU. Although
very unlikely to occur it also adds a safety net in case bugs creep in, and that kind of design was part of my
past professional life.

Edit: if __AES__ doesn't reflect the HW arch I can go back to has_aes_ni() from cpuid.

You're probably confusing two things:
 * The processor the binary was built for
 * The processor the binary is running on

These two things are similar but separate:
 * -march sets the _target_ processor the binary will be built for. The binary will error with "illegal instruction" if you run it on older CPU's.
 * cpuid returns the _current_ processor it's running under, if you can code your program to dynamically switch between implementations based on what CPU is currently running the binary.

__AES__ means that the _target_ processor supports AES -- that is a macro, not a variable, it doesn't change between runs. It reflects the hardware architecture of the processor the binary is _designed_ to be run on. Trying to execute AES instructions on core2 will give you "illegal instruction" error.

You need to check that _both_ the binary and the CPU support AES before actually doing the code. You need to check for __AES__ flag and get the cpuid capability.

Same goes for SSE2, you need to pull it from cpuid and check that __SSE2__ is defined.

I've rewritten the check_cpu_capability() to reflect what I mean:
https://github.com/hmage/cpuminer-opt/commit/30ef05f18b538655440667c5106e4967a27ccb51?diff=split
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 04:31:35 AM
 #467

Hmmm, I should retest, maybe I actually used "-march=native -DNO_AES_NI". I'm hoping I'm right
because it enables detection of an AES_NI cross compiled build being run on a non-AES_NI CPU. Although
very unlikely to occur it also adds a safety net in case bugs creep in, and that kind of design was part of my
past professional life.

Edit: if __AES__ doesn't reflect the HW arch I can go back to has_aes_ni() from cpuid.

You're probably confusing two things:
 * The processor the binary was built for
 * The processor the binary is running on

These two things are similar but separate:
 * -march sets the _target_ processor the binary will be built for. The binary will error with "illegal instruction" if you run it on older CPU's.
 * cpuid returns the _current_ processor it's running under, if you can code your program to dynamically switch between implementations based on what CPU is currently running the binary.

__AES__ means that the _target_ processor supports AES -- that is a macro, not a variable, it doesn't change between runs. It reflects the hardware architecture of the processor the binary is _designed_ to be run on. Trying to execute AES instructions on core2 will give you "illegal instruction" error.

You need to check that _both_ the binary and the CPU support AES before actually doing the code. You need to check for __AES__ flag and get the cpuid capability.

Same goes for SSE2, you need to pull it from cpuid and check that __SSE2__ is defined.

I've rewritten the check_cpu_capability() to reflect what I mean:
https://github.com/hmage/cpuminer-opt/commit/30ef05f18b538655440667c5106e4967a27ccb51?diff=split

I unerstood the concepts but not the implementation. I had problems with has_sse2 last time I tried that, maybe I'll
success this time.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 15, 2016, 07:12:15 AM
 #468

I had problems with has_sse2 last time I tried that, maybe I'll success this time.

has_sse2() was broken. Had to repair it. It was looking at wrong cpuid field.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 04:58:25 PM
 #469

There is a problem in v3.1.14 with the new compile procedure for CPUs that do not have
AES_NI. Please continue to use _DNO_AES_NI on the configure command line if your CPU does
not have AES_NI.



cpuminer-opt v3.1.14 released.

https://drive.google.com/file/d/0B0lVSGQYLJIZaE5DYXA4SHl2WVk/view?usp=sharing

New in v3.1.14

Algos
     - cryptonight algo is now supported on CPUs without AES_NI.
       All algos now support both CPU architectures.
     - jane added as an alias for scryptjane with default N-factor 16

Build enhancements, see details in README.md (thanks to hmage)
     - build.sh now works for CPUs with and without AES_NI
     - it is no longer necessary to add -DNO_AES_NI CFLAG to
       configure command when building for CPUs without AES_NI.

     Note: Compiling requires some additional libraries not included
     in the default instalation of most Linux distributions: libboost-dev,
     libboost-system-dev, libboost-thread-dev.

UI enhancements
     - enhanced checks for CPU architecture, SW build and algo for
       AES_NI and SSE2 capabilities.
     - a warning is displayed if mining an untested algo.

Code cleanup
     - removed a few more compiler warnings
     - removed some dead code

Algo gate enhancements (for devs)
     - replaced algo specific null gate functions with generic null
       functions



cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 15, 2016, 05:39:09 PM
 #470

There is a problem in v3.1.14 with the new compile procedure for CPUs that do not have
AES_NI. Please continue to use _DNO_AES_NI on the configure command line if your CPU does
not have AES_NI.

Yeah, you added the NO_AES_NI define inside the VisualC-specific section of miner.h  Cool

Here's a diff against v3.1.14 to make it work on core2:
 * https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37
 * https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37.diff -- raw diff

You also no longer need to carry around compat/curl-for-windows/openssl, since you are including system openssl headers anyway:
 * https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf
 * https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff -- raw diff

You no longer need boost to compile hodlcoin, the code uses unordered_map, which is part of C++11 standard and gcc supports it since 4.7:
 * https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc
 * https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff -- raw diff

To properly report that SW and CPU support AES and SSE2, you need to fix has_sse2() first:
 * https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f
 * https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff -- raw diff

Then go fix the check_cpu_capability() to actually report the proper values:
 * https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab
 * https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab.diff -- raw diff

To avoid problems with misapplying the patches (I guess you applied my previous patch manually, therefore you put NO_AES_NI define in wrong place in miner.h), I recommend using the standard patch utility to automate the process:
Code:
cd cpuminer-opt
wget https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37.diff
wget https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff
wget https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff
wget https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff
wget https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab.diff
patch -p1 -i 94f503824a852335770c0ee5789bbd7511224a37.diff
patch -p1 -i b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff
patch -p1 -i 73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff
patch -p1 -i d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff
patch -p1 -i c869830ef2446d863019e284437382681da259ab.diff

This way it will apply exactly as it is on my side, assuming you didn't make any changes nearby.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 07:05:09 PM
 #471

There is a problem in v3.1.14 with the new compile procedure for CPUs that do not have
AES_NI. Please continue to use _DNO_AES_NI on the configure command line if your CPU does
not have AES_NI.

Yeah, you added the NO_AES_NI define inside the VisualC-specific section of miner.h  Cool

DOH!. That explains everything. Thanks for noticing that stupidity.

I found the bugs in has_sse2, yes there were two of them, wrong reg & wrong field.

I'll look over your other stuff and fully understand it before I implement it. I will learn more
by hand coding it. I also need the practice.
 
Eliminating dependencies is good. You should pass these along to Epsylon3 as he may be interested
in porting them to his fork.



cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 07:09:16 PM
 #472

The problem is now understood and a fix has been coded and tested.  The fix will be in the next
release but since the workaround is to use the old build procedure I will not rush the next release
for this issue. V3.1.14is still a better release than v3.1.13.

There is a problem in v3.1.14 with the new compile procedure for CPUs that do not have
AES_NI. Please continue to use -DNO_AES_NI on the configure command line if your CPU does
not have AES_NI.



cpuminer-opt v3.1.14 released.

https://drive.google.com/file/d/0B0lVSGQYLJIZaE5DYXA4SHl2WVk/view?usp=sharing

New in v3.1.14

Algos
     - cryptonight algo is now supported on CPUs without AES_NI.
       All algos now support both CPU architectures.
     - jane added as an alias for scryptjane with default N-factor 16

Build enhancements, see details in README.md (thanks to hmage)
     - build.sh now works for CPUs with and without AES_NI
     - it is no longer necessary to add -DNO_AES_NI CFLAG to
       configure command when building for CPUs without AES_NI.

     Note: Compiling requires some additional libraries not included
     in the default instalation of most Linux distributions: libboost-dev,
     libboost-system-dev, libboost-thread-dev.

UI enhancements
     - enhanced checks for CPU architecture, SW build and algo for
       AES_NI and SSE2 capabilities.
     - a warning is displayed if mining an untested algo.

Code cleanup
     - removed a few more compiler warnings
     - removed some dead code

Algo gate enhancements (for devs)
     - replaced algo specific null gate functions with generic null
       functions



cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 07:49:33 PM
 #473

There is a problem in v3.1.14 with the new compile procedure for CPUs that do not have
AES_NI. Please continue to use _DNO_AES_NI on the configure command line if your CPU does
not have AES_NI.

Yeah, you added the NO_AES_NI define inside the VisualC-specific section of miner.h  Cool

Here's a diff against v3.1.14 to make it work on core2:
 * https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37
 * https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37.diff -- raw diff

You also no longer need to carry around compat/curl-for-windows/openssl, since you are including system openssl headers anyway:
 * https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf
 * https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff -- raw diff

You no longer need boost to compile hodlcoin, the code uses unordered_map, which is part of C++11 standard and gcc supports it since 4.7:
 * https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc
 * https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff -- raw diff

To properly report that SW and CPU support AES and SSE2, you need to fix has_sse2() first:
 * https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f
 * https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff -- raw diff

Then go fix the check_cpu_capability() to actually report the proper values:
 * https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab
 * https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab.diff -- raw diff

To avoid problems with misapplying the patches (I guess you applied my previous patch manually, therefore you put NO_AES_NI define in wrong place in miner.h), I recommend using the standard patch utility to automate the process:
Code:
cd cpuminer-opt
wget https://github.com/hmage/cpuminer-opt/commit/94f503824a852335770c0ee5789bbd7511224a37.diff
wget https://github.com/hmage/cpuminer-opt/commit/b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff
wget https://github.com/hmage/cpuminer-opt/commit/73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff
wget https://github.com/hmage/cpuminer-opt/commit/d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff
wget https://github.com/hmage/cpuminer-opt/commit/c869830ef2446d863019e284437382681da259ab.diff
patch -p1 -i 94f503824a852335770c0ee5789bbd7511224a37.diff
patch -p1 -i b0c0a7ab9b1d812075de90052b7f6ecb58d8a2cf.diff
patch -p1 -i 73eae16f3afa1b1f32ab4264c705b1e6bbbd8bbc.diff
patch -p1 -i d867ad08c7dac01f8c3735b0e65afb0242a4566f.diff
patch -p1 -i c869830ef2446d863019e284437382681da259ab.diff

This way it will apply exactly as it is on my side, assuming you didn't make any changes nearby.

AES fixed, has_sse2 fixed.

I'm hesitant to change boost because the compiler flagged it as experimental.
I'm not sure I want to go there yet.

Adding #include "miner.h' does nothing in groestl-version.h, everything is hard coded.

Everything now works as I intended in 3.1.14, just need to do some thorough testing.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 15, 2016, 08:35:40 PM
 #474

I'm hesitant to change boost because the compiler flagged it as experimental.
I'm not sure I want to go there yet.

What version of compiler? Did you put -std=gnu++11 compiler flag into CXXFLAGS? That's important.

Adding #include "miner.h' does nothing in groestl-version.h, everything is hard coded.
It does when you try to compile for -march=core2 or on core2 with -march=native, without the include groestl won't have NO_AES_NI when needed and it won't compile on core2.

To simplify testing I do a -march=core2 pass after every change, and then -march=native pass.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 15, 2016, 09:46:51 PM
 #475

I'm hesitant to change boost because the compiler flagged it as experimental.
I'm not sure I want to go there yet.

What version of compiler? Did you put -std=gnu++11 compiler flag into CXXFLAGS? That's important.

Adding #include "miner.h' does nothing in groestl-version.h, everything is hard coded.
It does when you try to compile for -march=core2 or on core2 with -march=native, without the include groestl won't have NO_AES_NI when needed and it won't compile on core2.

To simplify testing I do a -march=core2 pass after every change, and then -march=native pass.

I saw the compiler flag but I'd rather stay with the default to ensure compatibility. If it produces a measurable
performance gain I could be persuaded otherwise.

All refs to NO_AES_NI groestl-version.h are commented out. Are you confusing it with hash-groestl.c which indeed
needs block out AES code in order to compile on core2?

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 17, 2016, 03:55:52 AM
 #476

I saw the compiler flag but I'd rather stay with the default to ensure compatibility. If it produces a measurable
performance gain I could be persuaded otherwise.

The defaults vary between versions of compiler. Even on latest GCC 5.3 it's not default and it won't be default for some time (the next major release after 5.3 changes it to C++11), there are still distributions that come with gcc 4.7.

By explicitly stating what language version you're using you're actually ensuring compatibility of your code with the compiler (it won't try to treat 'auto' as a keyword, which is new in C++14, for example, also inline semantics are incompatible between C89 and C99).

The message you were seeing about unordered_map was applicable to that language version you were using (C++98), it does not apply to other language version and it goes away if you explicitly specify newer C++11 rather than default C++98 (12 years of difference) in gcc 4.7 or newer.

It's up to you anyway, I'll just keep it in my fork, maybe people will find it easier to start using.

Don't forget to add checks for boost in configure.ac so it's absence is detected at configure time.

All refs to NO_AES_NI groestl-version.h are commented out. Are you confusing it with hash-groestl.c which indeed
needs block out AES code in order to compile on core2?

Try compiling with -march=core2 and you'll see it won't compile.

Maybe the location I placed that include isn't the best.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 17, 2016, 04:23:17 AM
 #477

I saw the compiler flag but I'd rather stay with the default to ensure compatibility. If it produces a measurable
performance gain I could be persuaded otherwise.

The defaults vary between versions of compiler. On GCC 5.x, it will compile fine because it's default there, by explicitly stating what language version you're using you're actually ensuring compatibility of your code with the compiler (it won't try to treat 'auto' as a keyword, which is new in C++14, for example, and default in 5.3.0, also inline semantics are incompatible between C89 and C99).

The message you were seeing about unordered_map was applicable to that language version you were using, it does not apply to other language version and it goes away if you explicitly specify newer C++11 rather than default C++98 (12 years of difference) in gcc 4.9.

I don't understand your point. A new compiler feature was added experimentally and required a non-default option to
enable it. This is to ensure any incompatibilities with legacy code can be avoided. When the app has migrated to
use the new feature it would set that option to enable the compiler to use the new feature. After some transition
period the new feature would be made default on the assumption that all apps have migrated. Based on that
using the default (experimental feature disabled) should be safer. Why not?  

Edit: You mentioned the message is due to the language version I'm using. That supports my point. I'm running the
latest LTS version of mint and the feature is experimental. Older distros may be incompatible and I want to
remain compatible with older distros using older compilers. I can't assume that Centos 6, or Centos 5 (yes still
supported) have updated the compiler to support the new feature.

Quote from: hmage
All refs to NO_AES_NI groestl-version.h are commented out. Are you confusing it with hash-groestl.c which indeed
needs block out AES code in order to compile on core2?

Try compiling with -march=core2 and you'll see it won't compile.

Maybe the location I placed that include isn't the best.

I did (march=core2, not real HW), and it did. One of us has a big blind spot. I've looked at groestl-version.h many
times and there is no reference to NO_AES_NI. I had previously commented them out and hard coded VAES because
that's all that was being used.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 18, 2016, 02:15:58 AM
 #478

I don't understand your point. A new compiler feature was added experimentally

Lemme stop you there, GCC supports C++11 since 4.8.1 as feature-complete and stable, not experimental.

https://gcc.gnu.org/projects/cxx-status.html#cxx11

They do not change defaults for other reason -- a lot of code will break if you upgrade to newer version of the standard, not because it's experimental.

I did (march=core2, not real HW), and it did. One of us has a big blind spot. I've looked at groestl-version.h many times and there is no reference to NO_AES_NI. I had previously commented them out and hard coded VAES because that's all that was being used.

Yes, I was wrong, sorry. Probably a leftover change that isn't needed anymore.

PS: On this forum there's no need for doing linebreaks yourself — it looks weird when the window size is smaller than your linebreaks, and different font rendering systems and different installed fonts will end up with words being different sizes than what you see on your computer (yay compatibility!). Here's how it looks for me — http://i.imgur.com/BRx5I0r.png — note the hanging 'to' and 'the'.
joblo
Legendary
*
Offline Offline

Activity: 1134
Merit: 1016


View Profile
April 18, 2016, 04:35:39 AM
 #479

I don't understand your point. A new compiler feature was added experimentally

Lemme stop you there, GCC supports C++11 since 4.8.1 as feature-complete and stable, not experimental.

https://gcc.gnu.org/projects/cxx-status.html#cxx11

They do not change defaults for other reason -- a lot of code will break if you upgrade to newer version of the standard, not because it's experimental.


I'm still not sure it's the rigt thing to do. So c++11 is not the default until 6.1 over concerns it may break existing code. You have shown it is not the case with cpuminer-opt sothere is little risk. The fact the code is agnostic is good because it can still work on c++98 (not sure about this because I believe it requires code changes between versions). These are all reasons it's not a bad thing but I'm having a hard time coming up with any reasons it's a good thing.

I don't expect any performance improvements out of the box, and if there are any to be realized it would require code chnages that would break compatibility. It's forward thinking but the migration could be done at any time, such as after c++11 v6.1 is released. If it had been done with the first hodl release it would have eliminated the need to install packages but now that hodl is in the wild with the libboost dependencies it's no longer an issue.

Can you help me out here? Why is it a good thing?

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
hmage
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 18, 2016, 01:40:33 PM
 #480

I don't expect any performance improvements out of the box.

My bad, we were talking about this from different angles. Performance-wise there is no good reason for this. This will _not_ improve performance at all, in fact, the code that is in gcc's implementation of unordered_map and in boost is very similar and will likely behave exactly the same.

The only difference is that users won't need to install boost, and on some platforms like Windows boost doesn't come pre-packaged. This harms eventual plans to port this to Windows.

Not requiring boost means people won't have to deal with 210 pages of this -- http://stackoverflow.com/search?q=boost+visual-studio

So, to recap:
 * Performance wise -- there's no difference.
 * Maintenance wise -- there is.

Sorry for misunderstanding.
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 ... 190 »
  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!