[fpc-devel] Kit's development progress and research

[J. Gareth Moreton]

Well, I haven't managed to get much of a saving yet, probably due to how 
good FPC's memory manager is as well as the "nf_pass1_done" flag that 
minimises needless parsing of the nodes even when they're copied.  
Ultimately it's not worth showcasing just yet, although I might be able 
to pick out a couple of things like removing memory leaks, and avoiding 
the use of copying nodes does save on memory, which might be good for 
platforms that are a bit more constrained.

Either way, back to looking at pure functions again and seeing how well 
I can get the nodes down to just writing to the result and 'out' 
variables (the presence of 'Exit' tends to complicate things).

Gareth aka. Kit

On 28/05/2020 22:45, J. Gareth Moreton wrote:
> Hi everyone,
>
> I've still got pure functions on my books, and I've been looking 
> around the node system that the compiler uses, especially pass 1. My 
> main forte, which is probably also my weakness because I like going on 
> wild goose chases, is looking for ways to optimise a process.  One 
> thing I've noticed in the node pass is how often nodes are duplicated 
> and destroyed, often without actually changing their contents, just 
> their position in the tree.  For example, with the 'pass_1' and 
> 'simplify' calls, things like "result := getcopy" in order to trigger 
> another run of the pass, since the original always gets destroyed if 
> result is not nil.
>
> One solution I've found, that I'm researching the effectiveness of, is 
> using a reference count system, and a method to mark a node as reused 
> (internally, just raises the reference count).  There's still room for 
> improvement though, as I've only gained a 1% speed gain in the 
> compiler so far (while confirming that the compiled code doesn't 
> change).  There are some hazards though, like when 'left' and 'right' 
> are set to nil in order to prevent them from being destroyed (because 
> the current node is due to be destroyed but is preserved due to a 
> reference count greater than 1).
>
> In the meantime, I've found and fixed a couple of memory leaks in the 
> form of commands like "right:=right.simplify(false);" - besides 
> assuming the result of 'simplify' is not nil, the original contents of 
> 'right' is never freed and gets leaked.
>
> This'll be something I'll be writing a design and implementation spec 
> when I'm done, assuming I can get a worthwhile speed boost. More than 
> anything I'm looking for ways make sure pure functions are processed 
> as quickly as possible and improving compiler speed without 
> sacrificing efficiency.
>
> Gareth aka. Kit
>
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus