Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does a compiler use all x86 instructions? (2010)

pepijndevos.nl

Post reply on HN
Print view View original

141–150 of 198 posts

Re: Does a compiler use all x86 instructions? (2010)

#141

Post by vidarh »

fizixer wrote: post #110
jcranmer wrote: post #94

Earlier quoted context omitted.

Sure, there is a lot of historical baggage in microprocessors--the BCD stuff and x86-16 support in general only exist for backwards compatibility (although note that BIOS starts up in x86-16). But the reason that Intel keeps adding instructions is, well, because they're useful. > - Why do microprocessors not strive for simplicity, implement only a handful of instructions in an optimized way, with a very small chip fo…

> What you're describing is a GPU I would say I'm describing something halfway between a CPU and a GPU. It's not just an ALU, it's a complete microprocessor, with pipelining, caches, etc. The main difference is that the instruction set is optimized, backward compatibility is no longer a requirement, and redundancy of the architecture is eliminated.

Look at the Epiphany CPUs used as the co-processors in the Parallella [1] and you find something similar to what you suggest. The current iteration are 16 core CPU's in a fingernail sized package. They have a design for a 64 core CPU and says it will scale to 4096 core's on a single die.

It's fun to play with. The challenges are pretty much what people have been saying: To get to these core counts in the little space they have had to sacrifice cache size and memory size and single thread speed, even with a very clean and simple instruction set, and we are in general not good about taking advantage of high core counts other than in the GPU sense.

The Epiphany in variations with enough cores has the potential to beat GPUs for workloads with many independent instruction streams, but it'd gets crushed by GPUs of similar size for workloads that can be easily vectorised, and would crushed by any modern CPU for workloads that require high single core performance because of data dependencies, no matter the core count, exactly because most of the complexity it sacrifices cost single core performance.

The problem is that we don't really know how much space that leaves (the Parallella was designed largely as a development platform to let people experiment with an Epiphany CPU). Adapteva has focused on the low power usage of their CPU, and that may very well be a good idea.

[1] https://www.parallella.org/

Re: Does a compiler use all x86 instructions? (2010)

#142

Post by rasz_pl »

nixos wrote: post #42

My question is if compilers use "new" x86 instructions, as then the program won't work at all on old systems. For example, if Intel decided today that CPUs need a new "fast" hashing opcode (I don't know if they actually do), a compiler can't compiles to it, as programs won't work on older computers. Is it like the API cruft in Android, where "new" Lollipop APIs are introduced for 10 years from now, when no one uses a…

Yes, usually it happens because someone is not experienced enough. Good example is No Man’s Sky crashing on Phenom CPUs because they hard linked Havoc compiled with SSE4.1 and _do not_ detect CPU type.

Re: Does a compiler use all x86 instructions? (2010)

#143

Post by userbinator »

chkras wrote: post #89
veddan wrote: post #43

Earlier quoted context omitted.

Reasonably modern versions of GCC will emit various rep instructions in some cases. Some code I just compiled with GCC 6.1.1 had several snippets like this emitted for zeroing with memset: xor eax,eax ... rep stos QWORD PTR es:[rdi],rax and some rep movs for memcpy/memmove.

really? I wonder if the timing of rep and string instructions have improved at all?

They operate on cacheline-sized pieces ever since the P6.

Re: Does a compiler use all x86 instructions? (2010)

#144

Post by caf »

sitkack wrote: post #127
laksjd wrote: post #107

Earlier quoted context omitted.

Yes, but those would be two assembly instructions each. The basic idea of using lea over 'movl $ebp, $eax; addl 0x80,$eax'ist that we can shave off a cycle because lea can be executed in a single cycle. However I wonder how much any of this still matters in a time where CPUs have developed to include all sorts of complex optimizations.

Modify the backend, or do a binary translation from one to the other and test. If `lea` is the predominate instruction, there might be microcode optimizations that favor `lea` over `movl`. My hunch is that is will be mostly the same barring overflowing the instruction cache. The microps should compile to the same instruction stream.

lea also doesn't modify the flags register. At one point this meant there was a wider choice of execution units it could be scheduled on than arithmetic instructions that required a full ALU.

Re: Does a compiler use all x86 instructions? (2010)

#145

Post by vardump »

webkike wrote: post #57
ajenner wrote: post #2

It doesn't, because there are lots of special-purpose x86 instructions that would be more trouble than they're worth to teach a compiler about. For example, instructions for accessing particular CPU features that the C and C++ languages have no concept of (cryptographic acceleration and instructions used for OS kernel code spring to mind). Some of these the compiler might know about via intrinsic functions, but won't…

It doesn't because when would a compiler issue syscall? Maybe if you count instructions emitted by inline assembly

Compilers do have intrinsics. No inline assembly needed for something that trivial.

Re: Does a compiler use all x86 instructions? (2010)

#146

Post by caf »

mschuster91 wrote: post #88
veddan wrote: post #51

Earlier quoted context omitted.

There are some methods to get around this. For example, there's an ELF extension called STT_GNU_IFUNC. It allows a symbol to be resolved at load time using a custom resolver function. This avoids the problem of figuring out which code-path to use on every invocation. For example, you could have a function void hash(char *out, const char *in); with two different possible implementations: a slow one using common instru…

I'm a bit skeptical about the performance, especially with often-called functions. Normally, asm would do call slow_hash at every place where slow_hash is invoked, but now it has to check at every invocation a pointer with the address of the function. Of course the loader could walk through all uses of the pointer to slow_hash and replace them by fast_hash on loading, but that won't work for selfmodifying (packed, or…

The resolution happens once only, just like other dynamic symbols - the result of the custom resolution call gets installed into the PLT, so subsequent calls will go directly to the right place.

That's the point of doing this in the linker - if you were going to look up the right function every call, you could do that entirely without special linker or compiler support.

Re: Does a compiler use all x86 instructions? (2010)

#148

Post by caf »

SixSigma wrote: post #111
krylon wrote: post #104

Earlier quoted context omitted.

Why would Microsoft want to stop people running their system on newer CPUs?

Hmm, I got that slightly backwards, Win10 will not work on older CPUs > Going forward, as new silicon generations are introduced, they will require the latest Windows platform at that time for support. This enables us to focus on deep integration between Windows and the silicon, while maintaining maximum reliability and compatibility with previous generations of platform and silicon. For example, Windows 10 will be t…

I can't see that surviving first contact with large corporate / government customers saying "No, we're going to stay on Windows 7 Enterprise for the next little while thanks - and by the way, we need to buy new PCs sometimes".

Re: Does a compiler use all x86 instructions? (2010)

#149

Post by caf »

dbcurtis wrote: post #64
shanemhansen wrote: post #24

There are instructions that would almost never be useful. See Linus's rant on cmov http://yarchive.net/comp/linux/cmov.html The tl;dr is that it would only be useful if you are trying to optimize the size of a binary.

I didn't read Linus's rant on CMOV, but whenever you see a CPU with CMOV, it is because the hardware has very good branch prediction, and the compiler has intimate knowledge of how the branch prediction hardware works. Then the compiler works hard on determining if branches are highly predictable. Is the branch part of closing a loop? Predict that you will stay in the loop. Is the branch checking for an exception con…

You don't even need perfect, "insider" branch analysis if you can do profile-guided optimisation using actual branch performance counters in the profile.

Re: Does a compiler use all x86 instructions? (2010)

#150

Post by vardump »

theresistor wrote: post #131
fizixer wrote: post #110

Earlier quoted context omitted.

> What you're describing is a GPU I would say I'm describing something halfway between a CPU and a GPU. It's not just an ALU, it's a complete microprocessor, with pipelining, caches, etc. The main difference is that the instruction set is optimized, backward compatibility is no longer a requirement, and redundancy of the architecture is eliminated.

That's literally what a GPU is.

That's literally not true.

GPUs have only something like 1-32 independent very wide MIMD/SIMD units with a lot of hardware threads.

Not sure about Nvidia 1080, but at least 980 has 32 SMM units, each roughly as defined above.

1024 independent cores... that'd be crazy. Surely they would not be cache coherent but only able to talk to immediate neighbors.

It'd be understatement to say that programming that kind of CPU would be challenging...

Post reply on HN