Re: Making Lemonade (Floating-point format changes)

On 5/14/2024 10:19 AM, MitchAlsup1 wrote:

Anton Ertl wrote:
 

mitchalsup@aol.com (MitchAlsup1) writes:

I recall that MIPS could emulate a TLB table walk in something like
19 cycles. That is:: a few cycles to get there, a hash table access,
a check, a TLB install, and a few cycles to get back.

 

Which MIPS?  R2000? R10000? Something else? Was this an inverted page
table?

 R3000 and it was a hast table ~1MB in size.
 

In my case, still using software managed TLB.
   Theoretically, hardware page walk is optional.
Current page-table formats:
   3-level nested page table with 16K pages;
   B-Tree;
   Hybrid B-Tree
     Lowest level is a conventional page-table;
     Higher levels are B-Tree.
Hardware page walk would not likely use the B-Tree formats. These are slower, but can save memory for the page tables with sparse address spaces and ASLR.
Though, one could go further and use the B-Trees to manage page-spans rather than individual pages, but this would not play well with the pagefile mechanism (since one needs to swap in/out individual pages rather than entire spans).
Had considered the possibility of an inverted page table, but not done so yet either.

On an x86 this would be at least 200 cycles just getting there and back.

 

Which x86?  8086?  80186?  80286?  These (maybe the 8088 and V20, too)
are the only implementations that deserve to be called x86.  If you
mean some IA-32 or AMD64 implementations, which ones?

 

Anyway, let's see how this works for the U74 (a RISC-V implementation
which apparently uses trapping for unaligned loads); here we have a
10M iteration loop with a payload that performs one load per
iteration:

 

[fedora-starfive:~/nfstmp/gforth-riscv:104544] perf stat -e instructions -e cycles gforth-fast -e ': foo 10000000 0 do @ loop ; 0 value x here aligned to x x x ! x foo drop bye'

 

 Performance counter stats for 'gforth-fast -e : foo 10000000 0 do @ loop ; 0 value x here aligned to x x x ! x foo drop bye':

 

         223805151      instructions:u            #    0.70  insn per cycle
         318131306      cycles:u

 

       0.352533487 seconds time elapsed

 

       0.257061000 seconds user
       0.064265000 seconds sys

 

[fedora-starfive:~/nfstmp/gforth-riscv:104545] perf stat -e instructions -e cycles gforth-fast -e ': foo 10000000 0 do @ loop ; 0 value x here aligned 1+ to x x x ! x foo drop bye'

 

 Performance counter stats for 'gforth-fast -e : foo 10000000 0 do @ loop ; 0 value x here aligned 1+ to x x x ! x foo drop bye':

 

        5329494415      instructions:u            #    0.75  insn per cycle
        7149481783      cycles:u

 

       7.183239751 seconds time elapsed

 

       7.082298000 seconds user
       0.070121000 seconds sys

 

So the unaligned access handling result in 511 additional instructions
per load compared to an aligned access (so it obviously does the
handling using some kind of trapping).  Each unaligned access results
in 683 additional cycles.

 Yes, but notice sys time hardly changes, so, RISC-V is performing the
misaligned LD in user mode (2 context switches -- likely somewhat light
weight).
 

In my case, fast unaligned access was a priority.
Mostly, I wanted LZ decompressor speeds that were not dog crap, but this is harder to pull off with an aligned-only machine. With the exception of my FELZ32 design, which operated entirely in terms of aligned 32-bit words.

So better use the unspecified MIPS, right?  However, if the
unspecified MIPS is an R2000, 19 cycles on a 12.5MHz R2000 cost
1.52us, whereas 683 cycles on a 1000MHz U74 cost 0.683us (and I have
heard that in the Visionfive V2 the U74 runs at 1500MHz).

 Given at least the same cache footprint a 2GHz R3000 would still be in the 20-cycle range. {{That 19 cycle TLB reload is dependent on
the handler and its table have a footprint in the cache(s).
 

In my case, it is significantly slower, but still manages to work OK at 50 MHz.
Granted, the situation might be not as pretty if I were doing separate address spaces.

- anton