[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Jullien
Subject: Re: [Tinycc-devel] Huge swings in cache performance
Date: Wed, 21 Dec 2016 08:39:05 +0100

M2 mode generates a pseudo assembler Lisp code like:

  ((fentry fib 1 0 0)
   (param 0)
   (jeq _l004 '1)
   (jneq _l003 '2)
   (move a1 '1)
   (gsub1 a1)

Each instruction is translated into an encoded integer (OpenLisp specific)
and goes to a vector which corresponds to compiled code.
This vector is interpreted with a state machine working much like a
processor using a BIG switch

JNEQ above is interpreted using:

        for( ;; ) {
                inst = ((FIXPTR)opcode[ pc++ ]) >> 4;

                switch( olopcode( inst ) ) {
                case LAP_FENTRY:
                         * LEN = 3 : 00 | type | xxxx | yyyy | zzzz
                         * information only,  should not be executed.
                         * x  is the number of required arguments and
                         * y  is flag used when function has &rest or
                         *    :rest argument.
                         * z  is the number of local paramters.
                case LAP_JNEQ:
                         * LEN = 1 : 5C xx xx obj
                         * where xx is the next address and obj an

                        if( a1 != opcode[ pc++ ] ) {
                                pc = (int)olushortarg( inst );

M3 takes M2 pseudo code and generates pure C code which is statically
compiled (as a standard .c file).

-----Original Message-----
From: Tinycc-devel [mailto:address@hidden
On Behalf Of Edmund Grimley Evans
Sent: mercredi 21 d├ęcembre 2016 08:26
To: address@hidden
Subject: Re: [Tinycc-devel] Huge swings in cache performance

Are you dynamically generating code on Intel? But presumably the dynamically
generated code is not inside your loop? However, if your dynamically
generated code is adjacent in memory to some data that gets modified, then
it could be (I have no idea how this stuff works on Intel) that the
processor thinks that the code may have been modified, even though it hasn't
been modified, and invalidates the cache just in case. And this phenomenon
would be very sensitive to the precise layout. The solution might be to put
the dynamically generated code in a block of memory that is separately
allocated with mmap. On the other hand, if you're already doing that,
probably this isn't the explanation.


Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]