Author

Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 170. (Read 444067 times)

legendary
Activity: 1470
Merit: 1114
I have problem with CentOs 6.5 (final). I try lo install with build.sh command but i have problems (i'm windows user.. i don't know more about Cheesy ). Someone know how to install on CentOS 6.5? Specific parameters on configure command?

Thank you. great job

There should be no special procedure for centos. If this is your first time it is likely you are missing some
dependencies. Some new ones were added recently to support new algos. Post your errors if you still have
problems.
full member
Activity: 239
Merit: 100
I have problem with CentOs 6.5 (final). I try lo install with build.sh command but i have problems (i'm windows user.. i don't know more about Cheesy ). Someone know how to install on CentOS 6.5? Specific parameters on configure command?

Thank you. great job
legendary
Activity: 1470
Merit: 1114
Is a windows version available?


Clearly you write more posts than you read. Go back a couple of pages.
legendary
Activity: 1470
Merit: 1114
I've retested blakecoin in cpuminer-opt v3.1.18 and it is now listed as supported.
newbie
Activity: 3
Merit: 0
Is a windows version available?



legendary
Activity: 1470
Merit: 1114
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.

If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.

I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.

I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)

Like I said, have a nice night, it's time for to go to bed.

There's no need to pout. You're making a claim that the AES_NI optimized hodlminer-wolf is slower than the
original on AMD CPUs with AES_NI. That is a serious claim and no one else has reported this so you need proof.
This goes beyond being childish, you have made a serious charge against a respected dev whio was paid to
develop the AES_NI enhanced miner.

You've already gone too far, you need to follow through with proof or make a full retraction with an apology to Wolf.

You have to calm down, I haven't make any charge against nobody, what are you talking about? listen to your self!

All I did was telling you that on my machine, EVP was using AES-NI and it is faster than wolfs code. Period. There is no 'charges' against nobody, please!!

And like I said, that only applied to the source code on the hodlcoin, I even told you the file where it was used: hodl.cpp

My suggestion was that you could use EVP alone (whitout wolfs code) because it uses AES-NI automatically. Where is the accusation??

You are making a stupid and simple suggestion a matter way, way out of proportion. You doesn't even understand that I was trying to suggest something to improve your code.

So, end of the story. I'm not gonna continue with this stupid conversation, it when from a simple suggestion to "charges against a respected dev'. Go figure!

You don't realize the sum of your claims. You claim the original hodlminer is faster than Wolf's AES_NI optimized version.
I'm not saying it isn't true in your case but you need to show proof to convince me. I can't replicate your results and
they in fact prove the opposite.  You're on AMD and I'm on Intel, there're may be something there that should be pursued but you
haven't given me anything I can work with. You're coming accross as a troll. Prove me wrong.

The original hodlminer was not promoted to use AES_NI and Wolf was contracted to implement one. His version
produced higher hashrates and no one has complained. Either no one is mining hodl with AES enabled AMD CPUs,
they aren't paying attention, or you're wrong. There is some foundation to your claim because Wolf is optimized
for Intel, its performance on AMD may not be optimum. You can provide the answer if you stop throwing a hissy
fit and stick to the issue. It's up to you.

Edit: In your last 5 posts you haven't provided one piece of new information. Instead you're acting like a spoiled child
whining because I didn't give you praise. Grow up.
hero member
Activity: 583
Merit: 502
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.

If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.

I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.

I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)

Like I said, have a nice night, it's time for to go to bed.

There's no need to pout. You're making a claim that the AES_NI optimized hodlminer-wolf is slower than the
original on AMD CPUs with AES_NI. That is a serious claim and no one else has reported this so you need proof.
This goes beyond being childish, you have made a serious charge against a respected dev whio was paid to
develop the AES_NI enhanced miner.

You've already gone too far, you need to follow through with proof or make a full retraction with an apology to Wolf.

You have to calm down, I haven't make any charge against nobody, what are you talking about? listen to your self!

All I did was telling you that on my machine, EVP was using AES-NI and it is faster than wolfs code. Period. There is no 'charges' against nobody, please!!

And like I said, that only applied to the source code on the hodlcoin, I even told you the file where it was used: hodl.cpp

My suggestion was that you could use EVP alone (whitout wolfs code) because it uses AES-NI automatically. Where is the accusation??

You are making a stupid and simple suggestion a matter way, way out of proportion. You doesn't even understand that I was trying to suggest something to improve your code.

So, end of the story. I'm not gonna continue with this stupid conversation, it went from a simple suggestion to "charges against a respected dev'. Go figure!
legendary
Activity: 1470
Merit: 1114
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.

If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.

I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.

I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)

Like I said, have a nice night, it's time for to go to bed.

There's no need to pout. You're making a claim that the AES_NI optimized hodlminer-wolf is slower than the
original on AMD CPUs with AES_NI. That is a serious claim and no one else has reported this so you need proof.
This goes beyond being childish, you have made a serious charge against a respected dev whio was paid to
develop the AES_NI enhanced miner.

You've already gone too far, you need to follow through with proof or make a full retraction with an apology to Wolf.
legendary
Activity: 2716
Merit: 1094
Black Belt Developer
Wolf0 doesn't have an AMD cpu and it is indeed slower on that kind of processor.
Still, EVP can only be applied to algos which use plain AES, which are very few.
The others need specific code, like joblo is making.
hero member
Activity: 583
Merit: 502
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.

If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.

I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.

I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)

Like I said, have a nice night, it's time for to go to bed.
legendary
Activity: 1470
Merit: 1114
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.

Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response.
If it is faster how do I implement it?

It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything.

Just try it and you will see.

Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it.

You're full of shit, Wolf is 30% faster.

That's what you get when you are trying to help.

Never mind, forget all that I told you. Have a nice one.

Are you serious? That's a pretty childish response.

If evp is so much better and is already implemented in the orignal hodlminer Why is it so much slower than Wolf?

You've made a substantial claim without any data. My data contradicts your claims, Your move.
hero member
Activity: 583
Merit: 502
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.

Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response.
If it is faster how do I implement it?

It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything.

Just try it and you will see.

Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it.

You're full of shit, Wolf is 30% faster.

That's what you get when you are trying to help.

Never mind, forget all that I told you. Have a nice one.
legendary
Activity: 1470
Merit: 1114
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.

Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response.
If it is faster how do I implement it?

It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything.

Just try it and you will see.

Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it.

You're full of shit, Wolf is 30% faster.
hero member
Activity: 583
Merit: 502
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.

Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response.
If it is faster how do I implement it?

It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything.

Just try it and you will see.

Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it.
legendary
Activity: 1470
Merit: 1114
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.

Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response.
If it is faster how do I implement it?
hero member
Activity: 583
Merit: 502
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.



Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Smiley

Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out.
legendary
Activity: 1470
Merit: 1114
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.

If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the
AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general
purpose tool while the Wolf miner is optimized for the specific task.

If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into
detail there are only three things that would motivate me to make design changes to a stable product:
support for more algos, higher hashrates or Windows support.

hero member
Activity: 583
Merit: 502
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.

Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it.

I already did and it works perfect.
legendary
Activity: 1470
Merit: 1114
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 

I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions
on an incompatible CPU. Without it the compile fails.
hero member
Activity: 583
Merit: 502
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.

OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection.
Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the
AES_NI and non-AES_NI implementations.

@joblo:

    You are already using it in hodl.cpp:

                        EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv);
                        EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize);
                        EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2);
                        EVP_CIPHER_CTX_cleanup(&ctx);

All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary.

Hope that I'm clear this time Smiley
 
Jump to: