[fpc-devel] Blackfin support
DrDiettrich1 at aol.com
Wed Jul 14 00:00:43 CEST 2010
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
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.
More information about the fpc-devel