texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Scrolling speed


From: David MENTRE
Subject: Re: [Texmacs-dev] Scrolling speed
Date: Wed, 26 May 2004 20:19:03 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hello Joris,

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?

> 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)?

> 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.

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. 

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. 

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.

Yours,
d.
-- 
 David Mentré <address@hidden>




reply via email to

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