back

by vardump·11y ago·view on hn ↗
Currently CPU capabilities can even change on the fly, because of virtualization technologies like vMotion. That's why CPUID flags need to be masked by the hypervisors to hide CPU features that some CPUs in the same domain don't have.

Maybe that is possible. But would it be simpler? Maybe it can be a part of the solution?

Why would you care? You can generate a lot of code in a microsecond.

> Or maybe this could be built into the CPU cache? We already have a 1000-plus opcode decoded instruction cache. Already certain 'idioms' are optimized at decode time. How impossible would it be to have an opcode optimizer that rewrites the instructions in the cache to use the widest vector instructions available?

Sorry, but I don't understand your question.

1 comments
Why would you care? You can generate a lot of code in a microsecond.

Because the limiting factor isn't code generation speed, but pattern recognition. Also, having spent too much time staring the mangled junk produced by optimizing compilers that concentrate on speed of compilation, I'm naively hoping that dedicating more processor time to optimizations will produce better code.

Sorry, but I don't understand your question.

CPU's no longer decode x64 instructions for tight loops. Instead, they inject decoded opcodes by that they index by starting address. Already, simple optimizations are being made at this level: https://sites.google.com/site/paulclaytonplace/andy-glew-s-c...

I'm wondering how feasible it would be to "rewrite" series of scalar instructions to a smaller number of SIMD alternatives either as part of the front end decoder or as something that continually optimizes the stream of opcodes in the cache.

> Because the limiting factor isn't code generation speed, but pattern recognition. Also, having spent too much time staring the mangled junk produced by optimizing compilers that concentrate on speed of compilation, I'm naively hoping that dedicating more processor time to optimizations will produce better code.

You wouldn't need to care of the actual generated code. It would be generated just and only for the currently running processor and memory subsystem.

> I'm wondering how feasible it would be to "rewrite" series of scalar instructions to a smaller number of SIMD alternatives either as part of the front end decoder or as something that continually optimizes the stream of opcodes in the cache.

Right. First you'd need to have available instruction encodings -- for x86, they're in very short supply. Secondly this would increase the amount of state that needs to be stored to memory and restored when context switching between threads and processes, unless the support would only be available to the operating system and opcodes are shared by all thread contexts.

You can achieve this by JITting already, without the context switching overhead.

On the positive side, this would ease instruction cache pressure.

I don't think we're talking about the same thing. I'm probably not helping by being sloppy distinguishing between opcodes and µops. But I'm referring to the hardware decoded µop cache that mostly replaced the "loop stream detector" in Intel processors post-Nehalem. No context switching, no OS support, rather hardware optimizations targeted at the interface between the outward facing x64 (CISC) instruction set and the post-encoding (RISC) µop driven monster within.

It would be a box along the same path as the one labelled "uOP Cache Hit Logic": http://pc.watch.impress.co.jp/video/pcw/docs/601/851/p16.pdf

I think that's what the SIMD instructions largely do. Like AVX-512 when talking about Skylake. A more direct interface to the "monster within". The monster got bigger, so there's a need to feed it with bigger chunks of work.

µops are just an intermediary translation format. The point in JITting is to have the CPU translating the intent better to actual µops.