Re: [Plex86-devel] Task #1356...

[Daniel Herring]

>code in the current implementation.  This is
_a_very_bad_idea_.  The paste
>code is, by necessity, going to need different key
translation than the
>keyboard, and thus it should be translated separately.  There 

Separation of unrelated features?  always a good idea.  :)


>course, a couple of ways to go about this.  From what I can
tell at the
>moment, what we are doing for the paste is roughly the
equivalent of
>parsing a file (in memory) each time a key is pressed.

That doesn't sound good.


>keypresses, the code seems to be cleaner, but to be honest it
isn't
>usually a good idea to have tables like that static in
memory--due to the
>way that CPU cache works primarily.  What makes more sense
from an
>optimised code point of view, is to have the keymap coded
directly into
>inline code on compile.  I know that this wipes out the 

How much do you think this would expand the code?  If a clever
pattern (e.g. equation) can do the mapping, then it is
definitely superior.  If however, the code is comparable in
size to the current code+table, then cache miss rates will
probably be similar.


>but it makes the runtime of the code so much faster.  Every
time that you
>index by a variable (or even constant) amount into a large
static array
>you suffer many many cache hits and context changes in the
host
>CPU--generally a bad idea.  Also, just having the array in
memory when it
>doesn't really need to be in some separate variable space
(since it may be
>part of code somewhere anyway) is a costly penalty in and of
itself.

Modern caches often use ~1k blocks (depending on where in the
line they are; bigger toward the hard drive and smaller at the
CPU).  If the keymap table is "small", as in a few k, then
having it separate from the code shouldn't cost much.  If its
bigger, then it might be wise to chunk the keymap into smaller
parts, grouping common keys toward the front of the table and
less-common keys toward the end.  That way, the table holding
common keys can stay in cache, while the other keys will swap
in and out as needed...

The key to efficient caching is to frequently hit the same
areas.

My fear is that expanding the tables would actually reduce the
effective hit rate and therefore inadvertantly hurt caching.

Just my $0.02(USD)


>I'll quit ranting now (for a moment) and let that get tossed
around a bit.

Keep on ranting; it often gets things done. :)

Even though I don't actually used your code, I appreciate
monitoring your progress.

Thanks,
Daniel Herring
address@hidden