<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Thanks Michael,</div><div><br>
</div><div>In the last patch that Jonas almost immediately closed, the speed savings were inconclusive because the number of cycles saved is probably only a few dozen, but I would argue it makes the code a bit more reasonable too because it replaces things like loc[low(loc)] with loc[0] and fillchar with a for-loop that initialises each element of an array to zero (it's slightly faster because the element size is a multiple of 16, while fillchar is general-purpose and spends a lot of time jumping around and even performing a multiplication before it starts filling things up). I guess seeing it marked as "won't fix" within 20 minutes was a moment of horror.</div><div><br>
</div><div>I just want to avoid working on something, building passion for it which is an unfortunate character flaw of mine, and then seeing it rejected or ignored when it's finished.<br>
</div><div><br>
</div><div>I guess I can get a bit impatient, because some of the things I can improve in, say, the peephole optimiser, are dependent on other patches (in this case, the x86-64 optimiser overhaul) being accepted or rejected rather than being left in limbo (trying to make the changes now, before the patch is accepted, will just cause merge conflicts later). Mind you, I understand the need to do careful testing before committing something (and I've made bug fixes to the overhaul already based on problems people have found). The node dumping feature is also slightly essential for a couple of things I need to research that Florian's approved of (some node-level optimisations for things like the floor() function).<br>
<br>
I've just hit a couple of impasses since I'm waiting on the node dump feature to be approved and the status of the optimiser overhaul (I tend to be quite good at doing peephole optimisations... at least a peephole optimisation was the very first piece of code I submitted to FPC).<br>
</div><div><br>
</div><div>Other things that I'm experimenting with or researching, like attempting to allow pure assembler routines to be inlined, partly as a way to support intrinsics and also to provide a speed boost for some internal functions like Trunc (which is only a single command under x86_64), is something that Florian is afraid to begin contemplating, whereas I like to jump right in and try it out, and see if it blows up in my face or not. Mind you, as a volunteer with a relatively unknown track record outside of Free Pascal, I can be a bit of a pariah sometimes. The way I see it though, being a programmer who likes to play around with gaming and mathematics, I seek to help make Free Pascal a tool that is more than suitable for the job and something I can tell others "yes, this is a good language to use". Now, I accept that for certain time critical things or things that take weeks to complete, where even the slightest saving can multiply into a whole day (e.g. folding proteins or determining the primality of a Mersenne number), nothing beats raw assembly language - I just have to remember that most people don't like to mess with it!<br>
</div><br>
Gareth aka. Kit<br>
<br>
<br>
<span style="font-weight: bold;">On Sat 09/02/19 07:52 , Michael Van Canneyt michael@freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<br>
<br>
On Fri, 8 Feb 2019, J. Gareth Moreton wrote:
<br>
<br>
<span style="color: rgb(102, 102, 102);">> I'll be straight here. Exactly what should I even be looking at and
</span><br>
<span style="color: rgb(102, 102, 102);">> working on? Being self-guided is evidently not cutting it because
</span><br>
<span style="color: rgb(102, 102, 102);">> recently, everything I see and think has potential or could use improvement
</span><br>
<span style="color: rgb(102, 102, 102);">> has been rejected or dismissed out of hand because it damages
</span><br>
<span style="color: rgb(102, 102, 102);">> maintainability, is deemed too risky to even experiment with or touches a
</span><br>
<span style="color: rgb(102, 102, 102);">> unit that was derived from a third party source and one doesn't want to
</span><br>
<span style="color: rgb(102, 102, 102);">> make changes to it in the name of being able to compare it line-for-line
</span><br>
<span style="color: rgb(102, 102, 102);">> (even though the third party source is in C)
</span><br>
<br>
No-one stops you from doing this anyway, but you will need to prove that the
<br>
replacement code is equally correct or better if you want to get it included.
<br>
The more sensitivethe code, the better the proof must be...
<br>
<br>
<span style="color: rgb(102, 102, 102);">> If I'm the wrong kind of person for this project, I understand, and you
</span><br>
<span style="color: rgb(102, 102, 102);">> can boot me out. What am I but naïve 'new blood' who is overly
</span><br>
<span style="color: rgb(102, 102, 102);">> optimistic and doesn't understand risk?
</span><br>
<br>
No-one is a priori the wrong kind of person for this (or any) project.
<br>
Any software has parts that are more sensitive and less sensitive.
<br>
Diving in and starting to tinker with the sensitive parts is of course
<br>
more prone to be met with criticism or reluctance...
<br>
<br>
I am not familiar with the compiler internals, but executable speed surely
<br>
can still be optimized a lot. I'm sure Florian, Sven or Jonas can point to
<br>
things that can use some work.
<br>
<br>
Michael.
<br>
<br>
<br>
_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>
<br>
</blockquote></HTML>