Sorry I've missed most of the recent discussion...busy with a new addition...

The r10 "trick" of letting it get clobbered requires you know something about the calling convention of the OS in use. The Linux SSE2 code for x86_64 will completely break on Windows, since there's a different set of registers saved between function calls. Depending on what OSX does with r8, you may be able to let it get clobbered, saving you a cycle or two.

I never really found any docs on how the calling convention works under Darwin/Mac OSX. I'm sure reading the GCC source code would enlighten someone. But I also like my sanity.

For those who want to take on a challenge, what you need to do to allow sse2_64 to run on Win64 boxes is to change the assembly to handle the Windows ABI for x86_64.

This is a useful starting point:
https://secure.wikimedia.org/wikipedia/en/wiki/X86_calling_conventions#Table_of_x86_Calling_Conventions.5B1.5D
Since I don't do Windows development, I'm not going to port it. However, I'll look at pull requests on my SSE2 branch.

And to talk to myself...I think I found the problem. Let me see if I can quickly fix it.

Edit

Fixed pushed to http://github.com/chromicant/cpuminer on the sse2 branch. Can people can pull from it and test to make sure it builds on other machines? It works on mine Ubuntu 10.10 x86_64 box with YASM 1.1.0.2352.

It also contains a minor update to the assembly code to remove the few pipeline stalls. I was playing with a profiler, and looking at some data people posted here, and made some minor fixes. Don't really see any noticeable speedup, but it should be there in theory. And we know how well theory is in practice.

Ok. Took a look at the logs. Seems like configure is not doing the yasm test correctly. Can you run yasm --version and open an issue on my Github page for cpuminer?

https://github.com/chromicant/cpuminer/issues

You can use a pastebin for the logs. Need them to help you out.

If you do a ./minerd --help, is sse2_64 listed as a valid algorithm to use? If not, you need a copy of yasm 1.1 from Debian and use that. That'll compile the SSE2 code. You also need to be running a 64-bit version of Ubuntu.

The SSE2 code is not well-tuned for some AMD architectures, it seems.

Even funnier. A T2 system is *cough* slightly *cough* more expensive:

http://cgi.ebay.com/SUN-Coolthreads-UltraSPARC-T2-Enterprise-T5120-Server-/180516461674

Only $10k USED!

Course, if you have a fab shop, you can make your own T2 (the design is Open Sourced)...in theory. Don't know if anyone has ever done that.

I did find a student paper which measured the performance of the T2 here: http://cs.anu.edu.au/student/projects/10S2/Reports/Cody%20Christopher.pdf...and ArtForz really hit the nail on the head (like, freaky scarily on the head) compared to the experimental results. Seems like if you run 8 threads worth on a T2 (there's 8 hashing units on each T2 die, from what I can read), you would hit ~31.25Mhash/sec if you hash 8k of data.

Where the paper is a little unclear is if hashing 512 bits on the hardware is worthwhile, since it seems like the Sun supplied code will use the hardware if it's worth it. From section 4.2.1 in the paper, if we force the hardware to hash 512 bits, then we see that the speed of the hardware is only 1510.94kb/sec. This leads to a rate of 2.95M sha256 blocks/s, or 1.5Mhash/s.

Looks like the setup cost is prohibitive for small blocks, but for larger ones, it's negligible. Tradeoff for the T2 is around the 8k mark.

Use a good compiler and the C code?

The UltraSPARC III is just a standard RISC 64-bit CPU. The UltraSPARC III does have "MMX Like" instructions (VIS), but the ISA doesn't even have a bit rotate if I recall, which makes it useless for trying SIMD tricks to speed up SHA-anything.

You may get something with some hand assembly, but I don't think it'll hold a candle to the tuned SSE2 code that's in some of the miners out there on modern hardware.

You want an UltraSparc T2 for SHA256 acceleration. I've had zero luck trying to get a test account on one....it's not common hardware someone would say "sure, have a shell account on this $10k server".

Try ./minerd since . is traditionally not on your path.

Try replacing "-f elf64" with "-f macho64" in the x86_64/Makefile as a workaround. Also, you need to make sure you're producing a 64-bit binary while you're compiling. Can't remember how to do that with XCode, but if you don't, the SSE2 code as written will fail. The code uses the added registers that come with the x86_64 architecture to prevent reading/writing to memory.

Hmm. Looks like it'll be a 5 line patch to fix that. Something like (the 5 lines plus the rest of the define):


Taken from XOrg, which had the same problem on OSX.

...and I think jgarzik's solution needs to be massaged into the OSX code above for maximum cleanliness!

Urm. Have you tried to compile it natively using XCode on OSX 10.6 on a machine that can handle SSE2? I'd like to see some bug reports as to why it won't compile. I don't think there's anything super specific that would prevent a build from happening. I've seen nothing on what sort of compile errors one gets on OSX. Also remember, I crafted the SSE2 code in jgarzik's miner to require the 64-bit mode of Intel/AMD chips. So if you're running a 32-bit kernel/userspace, you won't be able to use it.

(I'd try myself, but my Mac is in little bits...and it's just a CoreDuo, so I couldn't test the SSE2 code if I wanted to)

I do know my SSE2 WILL NOT WORK in win64, since the calling ABI is different.

The one place where there probably is a problem is I used ELF64 as the output for yasm. That should be Mach-O for OSX...but it may also just work.

Actually...that's an interesting idea.

I've been working with a STM8S-DISCOVERY board to run GNUK on the STM32 part. I still have some bugs to work out on the GnuPG implementation, but it may be interesting to try to hack up some code to make a smartcard-like application that can do transaction signing on said hardware. There is a bit of work that would need to be done on hardware as well as getting a client to be able to read the wallet from the hardware.

May be an interesting proof of concept.

Don't do that. There's a reason the check is failing.

If you looked at config.log, it probably says your version of yasm is 0.8.0. You need 1.1.0. For Ubuntu, you either compile it yourself or get the right version from Debian's repository.

Yup. Secret sharing. Really easy math wise as well...it's just a system of linear equations IIRC.

I am still putzing around with my Android client work....but as for [mike]'s Java code, I'd think storing the block headers in an SQLite database may be the way to go, but you'd need to edit that code to do so as I saw it.

But great job on the first pass. I should clean up and release what I have with respect to using C2DM to notify a bitcoin client that blocks are waiting. Also, now that we have a growing DNS spec...I don't feel bad if I am not part of the network as a whole.

Researchers nowadays.

They need to read the literature that's already out there. Lazy bums.

http://upload.wikimedia.org/wikipedia/commons/d/d1/PiratesVsTemp_English.jpg

Do you have an idea what part of the protocol munched up most of the bandwidth? It's a definite concern for people who want to run seed nodes to stabilize the network, as well as people interested in a mobile client.

If I had to guess, would it be exchanging/downloading the block chain?