back

by vardump·11y ago·view on hn ↗
> 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.

1 comments
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.