Author

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

legendary
Activity: 1470
Merit: 1114
An update on the beta test.

Windows is definitely out for the beta test and so is CPU ID display. Arcitecture checking is working but will be
in permissive mode for the test build. I'm pretty beat tonight but will start packaging everything tomorrow.
I will be contacting the select beta testers by PM to make arangements for getting the beta build to
them. I expect it to be available friday. I expect the beta test to be quite short as the software has been
very reliable. I hope the first public release is out next week.
member
Activity: 72
Merit: 10
legendary
Activity: 1470
Merit: 1114
While waiting until I downgrade to VS 2013 let me indulge myself as I ramble on about who I am.

I'm a 58 year old computer geek who was laid off with a good severence package 8 years ago less than
a year before the company went bankrupt.

My education is somewhat limited, just a 3 year computer science diploma. In my final year in college
I and 2 other team members wrote an assembler for a microprosessor board that didn't have one.
It had no keyboard or display interface just an rs-232 serial port. So we had to write the assembler
twice on two different processor architectures. My teammate had an Apple 2e and it could connect
to the serial port and talk to the monitor program. It also had some rudimantary file transfer capability
so off we went. We got it done on tie with only one real all-nighter which was more by choice than
necessity. We were among the few that attended class or stayed awake in class the last week before
the formal project demonstration week. We actually had a live demo where we uploaded source code
to the board comlied it and executed it. And it worked. For a bit of humour we even deliberately
left a coding error so we could show the eror handling capability. They we all three graduated and
ended up at the same company, although at different times and in different departments. The same
company that went bankrupt after giving me a golden parachute. Ifeel sorry for the people layed off
after me because the company started cutting back on the packages. Then they declared bankruptcy
and all severance packages were taken off the table. They even reduced pension benefits to past
employees A real shame.

The proprietary system I worked on used Motorola 68k, 88k and powerpc cpus. I was most familiar with
the unpopular 88k. My claim to fame was discovering a bug in the branch prediction which ironically
improved performance once it was disabled. Apparently the BP conflicted with a compiler optimization
even if it had been working properly. The 88k, Moto's first venture into RISC, however, was short lived.

The software system was an integrated development system consisting of a run time real time operating system,
it's applications, a Linux based (originally IBM mainframe) multi-site program and documentation library,
and compiler all written in and for a proprietary high level language with similarities (ie strict type checking) with Pascal.
I really learned to love the language and it has some great features, with OO added later. One of my favorite quirks
in the language was the guzinta: "->". This is unlike similar c++ operator. It is the assigment operator
and works like this:  "value -> variable;".  Some of your may recognize it.

it had some important features like not defining the null pointer as 0. nul always pointed off to invalid address high
up in the address space. Address 0 was also invalid and would throw an exception if accessed. The languange
also had array index protection built into the compiler. An index out of range also would throw an exception.
There was also a built in data structure (nice to own your own compiler) called a descriptor that was essentially
a pointer to an array. It also had index protection. c++ probably has a class similar to the descriptor but without
index protection. That feature alone made the system so much more resilient to memory corruption and easier
to debug, but most importantly the concept of a buffer overflow did not exist. The compiler would not allow it.
Imagine how many fewer exploits there would have been had c/c++ had such protection (at a slight performance
cost).

I've never done any Linux or c++ development although I had some exposure to c++ at work. Many of the concepts
are so different that what I am familiar with and that slows me down a lot. I've used HP-UX, solaris and linux as
desktop workstations at work and used linux at home since Redhat 5.2.

Although I'm comfortable with assembly code I haven't touched Intel since the 8000 series. That will make the assembly
language files tough to work with. I have a couple of optimization thechniques I've used in the past but they require
intimate knowledge of the Intel architecture such as memory interface, cache organization, execution environment,
instruction issue and retirement throughput, and things I'm probably not aware exist. I have a lot to learn, but that's why
I'm here.

I know nothing about cryptographic algorithms so don't expect me to code new algos. I'll leave that up to others.

I had heard of Bitcoin but didn't get involved until very late (too late) in the darkcoin frenzy in April 2014. I started
with just one CPU but unknown to me at the time ASICS had taken over bitcoin and scrypt was next. And GPUs were taking
over the altcoin algos. I bought a gt730, a nice little card that performed on par with my i7-4790K. I bought a 750ti shortly
after that and a few other cards since then.

Well that's how I got here. I'm bored with lots of time on my hands so I've been poking around at miner code here and there.
I'm even less familiar so I took a shot with a cpuminer and was surprised. It is a credit to Pooler's design that I was able to
pull together code from 3 different miners and make it work smoothly and efficiently in a short time.

VS is still installing but I think it's time for a break.

I must be getting tired I just tried to post this to the wrong thread. I giess i don't have the stamina I did 25 years ago.

Thanks for reading and taking an interest in my project.
legendary
Activity: 1470
Merit: 1114

Look for example at this line:

and this line one more time:


Looks like you forgot self closing "/" before ">" in line with "sha3\aes_helper.c"

There was a lot wrong with that file, some of it was me and some of it was editpad++.
I'm starting fresh.

Edit: It's loaded now.  I made minimal edits and avoided moving things around. I should have known
better than to get too adventurous with MS. Thanks again for your keen eye.

Edit2: 479 errors on first compile. An this is code that compiles flawlessly on Linux. Obviously Windows
support is out for the beta. Maybe I'll get it working in time for the release.
legendary
Activity: 1470
Merit: 1114

AES function pointer - call CPUID, one AND, and one compare against zero. If true, function pointer = AES-NI one, else slow AES.

Hi Wolf0, thanks for contributing.

I've got the capabilities check working has_aes-ni() already existed and I wrote has_sse2. I'm now trying to get cpuid working to see
if I can display the actual cpu model.
member
Activity: 81
Merit: 1002
It was only the wind.
I'm looking for opinions on how to handle incompatible CPUs, during the test phase and then the first release

There are two parts to this issue. First is whether the CPU has AES_NI and the second is whether
cpuminer is compiled for that architecture. it's a biggger issue on Windows where the builds are
portable. I hope MS builds to support multiple architectures and select the best one at run time.
When multiple architectures are supported in cpuminer it is my intention to do exactly that.

But for the time being it only support ASES_NI so...

For the first part I'm considering 4 options.

1. If the CPU doesn't support AES_NI exit.
      probably most likely for the release

2. Damn the torpedos full speed ahead
      My preferred choice during testing

3. Add a comand line prompt to choose 1 or 2
        will become obsolete when more architectures are supported
        would probably delay the test release

4. Add a user prompt at startup
       This would require the work in 3 as well additional work to add a yes/no prompt and
       expand the new command line option for 3 choices if an incompatibility is found: Exit, Continue,
       or Prompt(default). This has all the cons of 3 but more so.

I'm not interested in poll, I prefer the reasons for the choice. And of course the beta testers can get what
they want.


AES function pointer - call CPUID, one AND, and one compare against zero. If true, function pointer = AES-NI one, else slow AES.
member
Activity: 117
Merit: 10
legendary
Activity: 1470
Merit: 1114
I'm looking for opinions on how to handle incompatible CPUs, during the test phase and then the first release

There are two parts to this issue. First is whether the CPU has AES_NI and the second is whether
cpuminer is compiled for that architecture. it's a biggger issue on Windows where the builds are
portable. I hope MS builds to support multiple architectures and select the best one at run time.
When multiple architectures are supported in cpuminer it is my intention to do exactly that.

But for the time being it only support ASES_NI so...

For the first part I'm considering 4 options.

1. If the CPU doesn't support AES_NI exit.
      probably most likely for the release

2. Damn the torpedos full speed ahead
      My preferred choice during testing

3. Add a comand line prompt to choose 1 or 2
        will become obsolete when more architectures are supported
        would probably delay the test release

4. Add a user prompt at startup
       This would require the work in 3 as well additional work to add a yes/no prompt and
       expand the new command line option for 3 choices if an incompatibility is found: Exit, Continue,
       or Prompt(default). This has all the cons of 3 but more so.

I'm not interested in poll, I prefer the reasons for the choice. And of course the beta testers can get what
they want.
legendary
Activity: 1470
Merit: 1114
member
Activity: 72
Merit: 10
legendary
Activity: 1470
Merit: 1114
I'm having some difficulty compiling on Windows with VS community 2015.

If there is anyone who can help it will speed up Windows support.

I editted  cpuminer.vcxprog with a text editor, not VS's built in editor.
I modelled the changes based on the sources list in Makefile.am,
but I really have no idea what I'm doing.

I added a bunch of entries to this list:

Code:
      Full
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
                   <------- error here
    
    
    

I get the following error.: The attribute "Include" in element   is unrecognized. I've shuffled
the order of the list and it errors on a different file everytime but the same line number.

Any ideas welcome.
    
member
Activity: 72
Merit: 10
This is interesting. Been trying to make the cpuminers faster myself but never got much done. To busy with other things. If you need help compiling with mingw I could help.

Good luck  Wink

theLosers106.
legendary
Activity: 1470
Merit: 1114
Looking forward to the cpu miner. 
 
I'm willing to help test it.   I've some i-7, I-3, I-5, core 2 computers.
Along with some older various single core Intel & AMD I have sitting here gathering dust. Smiley

Also have a black box AMD FX=8320E 8-core.

Algos I'd like to see are : neos, spread X11, Ethereum and the algo XMG coin uses.

--GKar (former nic was Angora)


I'm comfortable with the testers I have now but thanks for the offer. You shouldn't have to
wait very long for the public release.

You might want to talk to epsylon3 (tpruvot) about new algos, but I think he is more focussed on
his ccminer fork and yiimp pool (busy guy) at the moment.
full member
Activity: 180
Merit: 100
Looking forward to the cpu miner. 
 
I'm willing to help test it.   I've some i-7, I-3, I-5, core 2 computers.
Along with some older various single core Intel & AMD I have sitting here gathering dust. Smiley

Also have a black box AMD FX=8320E 8-core.

Algos I'd like to see are : neos, spread X11, Ethereum and the algo XMG coin uses.

--GKar (former nic was Angora)

legendary
Activity: 1470
Merit: 1114
Just checking in. Thread is looking good. I looked threw my collection of CPU miners and everything is pretty old and outdated.
Except the ones you talked about earlier. I'll be reading along and will be ready for this when the time is right, thanks for your support.
I'll have to brush up my Linux skills as most of what I have running at the moment is windows based.

I'm starting to work on compiling on Windows, if it goes well it should b be ready for private beta in a couple of days.
full member
Activity: 231
Merit: 150
Just checking in. Thread is looking good. I looked threw my collection of CPU miners and everything is pretty old and outdated.
Except the ones you talked about earlier. I'll be reading along and will be ready for this when the time is right, thanks for your support.
I'll have to brush up my Linux skills as most of what I have running at the moment is windows based.
legendary
Activity: 1470
Merit: 1114
You should add it to github.

good work


Thanks SP. Now if only I could code in cuda. Smiley
sp_
legendary
Activity: 2926
Merit: 1087
Team Black developer
You should add it to github.

good work
legendary
Activity: 1470
Merit: 1114
where can we see the sourcecode and download windows binaries ?
also advice from me compile the miner with mingw it makes the miner software more powerfull.

Thanks kama. The project is just getting off the ground officially, nothing is yet available publicly
or privately.

Source code will be available. I compile Windows with VS and am not inclined to change. But as
I editted in my first post Windows is not guaranteed in the first release. It Depend on how things go.

full member
Activity: 140
Merit: 100
where can we see the sourcecode and download windows binaries ?
also advice from me compile the miner with mingw it makes the miner software more powerfull.
Jump to: