Am Mit, 2003-01-01 um 18.49 schrieb Sander Vesik:
> I'm not entirely sure what you mean by this - while its true that you want the
> reordering to be architecture speific to an extent (so you take page size into
> account) I doubt that you'll find a usefull reordering that took either the tlb
> size or associativity into acocunt.
Exactly that's my point. This optimisation would have to be per CPU and
OS and not per architecture, which means that it cannot be done globally
for any architecture people are not compiling Gtk+/Glib themselves for.
> many usefull re-orderings (like moving
> frequent caller-calle pairs to be next to each other) are beneficial in any
> TLB you are likely to find in a shipping CPU.
What makes you think that? TLB management is part of the OS which is
free to choose how the TLB is organized and whether it uses the hardware
for the management. And then the hardware is also differing; some don't
have TLB hardware, some only support full flushes, many organize it as
some form of tree while other use hashtables.
I'm by no mean someone who knows much about TLBs so the above written is
probably a bit off but I'm pretty confident that a generic
implementation is somewhere between hard and impossible.
> You may want to use more than one application though.
Yeah, but that would complicate gathering the statistics quite a lot.
> > The argument of having often used functions in the same location to get
> > them paged in at once and thus perceive lower startup times seems more
> > likely to me than high benefits of shorter lookup times.
> The two are complimentary, not exclusive options.
Sure, but I tend to prefer the tastier fruit...
--
Servus,
Daniel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil