texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Scrolling speed


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Scrolling speed
Date: Fri, 28 May 2004 11:24:16 +0200 (CEST)

On Wed, 26 May 2004, David MENTRE wrote:
> Joris van der Hoeven <address@hidden> writes:
> > I also noticed another strange phenomenon. If I flush my memory using
> > David's program, restart TeXmacs and load one of my articles,
>
> Is such an article in TeXmacs format is available somewhere?

You may take one of the longer articles from the online examples.
Help -> Online help -> Browse web -> etc.

> > then scrolling is completely fluid. However, if I work for a while,
> > start a browser, launch a few compilations, etc. and then restart
> > TeXmacs, the scrolling becomes much slower.
>
> Yes, but after working for a while, is the scrolling getting better (I
> would say yes)?

No.

> > Any explanation for this phenomenon? Does malloc give me blocks which
> > do not behave well from the cache point of view? Should I allocate
> > larger consecutive blocks of memory? I currently allocate blocks of
> > 64Kb for small objects. Should I use larger blocks instead?
> > Should I also use larger blocks for big mallocs?
>
> Caches are exploiting spatial and temporal locality. Caches take into
> account physical memory accesses and do not consider how this physical
> memory is distributed into the virtual address space of the
> program. So malloc has little to do for cache locality.

Do you have a good reference on how modern memory works more precisely?

> In other words, to optimize cache use, just concentrate on optimizing
> locality of your program. Use the same data a lot, and then never use it
> again.

OK, but the strange thing here is that the performance depends a lot
on whether some other processes are or have been running or not.
This is weird; maybe it has something to do with X?
Typesetting speed does not seem to suffer from this phenomenon.

> One important effect to take account is that caches have a size
> limit. Working on a data set bigger than what the cache can store makes
> the cache totally unuseful. A typical example is having an array A and
> wanting to apply operations f and g on all A[i].
>
> If you do: for(i=0;i<n;i++)A[i]=f(A[i]); for(i=0;i<n;i++)A[i]=g(A[i]);
> with n big enough, you have cache trashing.
>
> On the contrary, if you do, for(i=0;i<n;i++)A[i]=g(f(A[i])); you have
> much better locality and therefore performance.

I understand this.

> That's why people optimizing numerical codes do matrix blocking,
> i.e. doing operations on sub-matrices, for matrix operations.
>
> Of course, my examples are taken from numerical programs when it is
> relatively easy to observe program behavior. It can be much more
> difficult for a program using complex data structures under user input
> like TeXmacs.
>
> If you want to know where you program is trashing the cache, run it
> under OProfile and annotate TeXmacs source with cache misses, that would
> give you good hints.
>
> I hope my explanation is clear.

Yes, but it still does not explain the phenomenon I observed...





reply via email to

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