Questions about X86 processors_问答_开发者_运维开发者技术经验分享

I have two questions about X86 processors.

First: What is SSE? What is it for? Is it CISC architecture? Should a programmer that does not program in Assembly and does not program compilers learn SSE?

Second: 64-bits processors support 32-bits processors. If 64-bits processors replace 32-bits processors, should programmers compile app that uses less than 2 GB of RAM for 32-bits? 32-bits app uses smaller amount of memory and its binaries are smaller. 开发者_StackOverflow社区The OS have to store shared libraries for both 32 and 64 bits, and it may be a problem.

Thanks

SSE is intel's implementation of single instruction multiple data. Doing the same operation on a number of values at the same time to speed things up. If you do some numerical calcualtion heavy work especially image processing it's perhaps worth looking at - although the libraries probably already do it and for real bang/buck you would learn Cuda/openCL.

32/64bit is complicated and very OS/compiler specific. There is a space cost for 64bit code - and there may be advantages to using 32bit builds on a 64bit OS. But a lot of the reasons are very OS reasons outside the size of a pointer - for instance requiring signed builds on the 64bit version.

You can read about SSE here. Truthfully, you probably don't really need to know anything about it if you're not working in ASM or doing media heavy stuff (and even then, it's probably best if you let your compiler do the optimization for you).
Not all 64-bit processors support 32-bit instructions. It's true that modern 64-bit PC processors support 32-bit instructions. You can read more about that here. What's your concern about shipping 64- vs. 32-bit binaries? It all depends on what your customer needs/wants. It is true that 64-bit binaries tend to be larger in size. Whether your program actually needs to be 64-bit or not is your decision.

[Heh, while answering this question, it was migrated to superuser, then deleted, and now it seems to be magically back here. Third try is the charm!]

I'm not well-versed in SSE, but it is a mechanism to operate on multiple datasets in parallel per clock cycle. (Older chips left a surprising amount of silicon idle per cycle; the chips got better at executing multiple instructions per cycle on their own, but it involved a fair amount of guesswork, and failed completely at some data-heavy algorithms.) So SSE takes a page from older SIMD systems, which allowed executing the same commands on multiple pieces of data. The setup time might have taken longer, but it got a lot done in the long term.

Depending upon what you're trying to get done, it can make a huge difference, but most programmers will probably never need the sorts of tools that SSE can provide.

As for executing 32 bit processes on 64 bit processes to save memory, that's a real possibility. But when AMD were first introducing the x86-64 instruction set, they were very careful to point out the new instructions and additional registers that could improve performance on tasks that weren't running out of address space or performing many 64-bit arithmetic operations. They mentioned that most people would probably want most code to be executing in 64-bit mode, but that the performance speedups would be subtle most of the time.

So, with the exception of Firefox and Flash, 64-bit is ubiquitous, and the memory expansion due to larger pointers doesn't seem to be a big issue.

SSE are an extension to the x86 architecture intended to support multimedia. More information can be found http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions.

There is a fair amount of debate about your second question. Here I am talking only about the Intel 32 and 64 bit platform. Functionally if a program never uses more than 2GB of memory there should not be a difference. However, compiling for 64 bit can create different performance profiles. For example the size of a pointer is larger on a 64 bit platform this tends to make the size of a program larger. To offset this disadvantage 64 bit the 64 bit platform has more registers which can make your program run faster. There is a complicated trade off here. It will be interesting to see what others think.