Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 12/21/2016 11:44 AM, David Mertens wrote:
> Discussion about alignment and execution speed for the Haskell
> compiler: https://ghc.haskell.org/trac/ghc/ticket/8279
> <https://ghc.haskell.org/trac/ghc/ticket/8279>
>
> This discussion mentions why things should be aligned, and gives
> some multi-byte no-ops that can be used for padding for aligned
> loops.
> http://stackoverflow.com/questions/18113995/performance-optimisations-of-x86-64-assembly-alignment-and-branch-prediction

Unfortunately much of these stuff involve compiler optimization, 
that'll be plenty of work to do for tcc to make it work well. In a 
perfect world, we would detect CPU model/family/features and JIT 
it perfectly to suit, heh heh :-)

Since x86 parallel decoders can decode only a certain mix of 
instructions, looking at Agner Fog's doc, if tcc chooses many 
instructions that uses multi-uOps, then for those instructions a 
decoder may process only one instruction per clock, instead of up 
to 4. Easy to gum up the works. But adding an optimization 
framework for instruction selection and organization for optimal 
decoding is a big thingy...

> I came across a similar issue a few weeks ago, but I was able to
> "fix" it by allocating more memory than I needed and then
> relocating to an address within that allocation that was aligned
> to the start of a page. This seemed to fix the problem back then,
> but this new flavor of alignment woes is impervious to such a trick.

Amazing how far we've come compared to Michael Abrash's black 
books, there are so many interacting modules in a modern x86 part.

Luckily I rarely need top performance and thus stopped worrying 
about these things long ago :-) It's hard for most regular coders 
to chase down such performance issues, it's a never-ending struggle...

> On Tue, Dec 20, 2016 at 10:29 PM, KHMan
> [snipped]
>     On 12/20/2016 10:17 PM, David Mertens wrote:
> [snipped]

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia