[fpc-devel] Blackfin support

[Hans-Peter Diettrich]

Marco van de Voort schrieb:

> One must keep in mind though that he probably measures on a *nix, and there
> is a reason why on Windows the make cycle takes twice the time on Windows.

One of these issues are memory mapped files, that can speed up file 
access a lot (I've been told), perhaps because it maps directly to the 
system file cache?


> So one can't entirely rule out limiting I/O and number of compiler startups,
> since not all OSes are alike.

That means optimizing for one platform may slow down the compiler on 
other platforms :-(

> For the memory management issues, an memory manager specifically for the
> compiler is the solution first hand. To make it worthwhile to have a list of
> zeroed blocks (and have a thread zero big blocks), somehow the system
> must know when a zeroed block is needed. For objects this maybe could be by
> creating a new root object, and deriving every object from it (cclasses
> etc). But that would still leave dynamic arrays and manually allocated
> memory.

When zeroing blocks really is an issue, then I suspect that it's more an 
issue of memory chaches. This would mean that the data locality should 
be increased, i.e. related pieces of data should reside physically next 
each other (same page). Most list implementations (TList) tend to spread 
the list and its entries across the address space.

Special considerations may apply to 64 bit systems, with an (currently) 
almost unlimited address space. There it might be a good idea to 
allocate lists bigger than really needed, what should do no harm when 
the unused elements never are allocated to RAM (thanks to paged memory 
management). Then a TList with buckets only is slower on such a system, 
for no other gain.


> For manually allocated memory of always the same size (virtual register
> map?) a pooling solution could be found.

Again candidates for huge pre-allocated memory arrays. But when these 
elements then are not used together, they may occupy one or two memory 
pages, and the remaining RAM in these pages is unused.


> Most OSes already read several 10s of kbs in advance. I don't really think
> that will bring that much. Such approaches are so lowlevel that the OS could
> do it, and probably it will.

Every OS with MMF will do so, when memory mapped files only are used. 
The rest IMO is so platform specific, that a single optimization 
strategy may not be a good solution for other platforms.


But I think that such low-level considerations should be left for later, 
when the big issues are fixed, and the requirements for exploring the 
real behaviour of various strategies have been implemented.

DoDi