[fpc-devel] I'll be straight

[J. Gareth Moreton]

 Thanks Michael,
 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.
 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.

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

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

 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!

 Gareth aka. Kit

 On Sat 09/02/19 07:52 , Michael Van Canneyt michael at freepascal.org sent:

 On Fri, 8 Feb 2019, J. Gareth Moreton wrote: 

 > I'll be straight here.  Exactly what should I even be looking at and 
 > working on?  Being self-guided is evidently not cutting it because 
 > recently, everything I see and think has potential or could use
improvement 
 > has been rejected or dismissed out of hand because it damages 
 > maintainability, is deemed too risky to even experiment with or touches
a 
 > unit that was derived from a third party source and one doesn't want to 
 > make changes to it in the name of being able to compare it line-for-line

 > (even though the third party source is in C) 

 No-one stops you from doing this anyway, but you will need to prove that
the 
 replacement code is equally correct or better if you want to get it
included. 
 The more sensitivethe code, the better the proof must be... 

 > If I'm the wrong kind of person for this project, I understand, and you 
 > can boot me out.  What am I but naïve 'new blood' who is overly 
 > optimistic and doesn't understand risk? 

 No-one is a priori the wrong kind of person for this (or any) project. 
 Any software has parts that are more sensitive and less sensitive. 
 Diving in and starting to tinker with the sensitive parts is of course 
 more prone to be met with criticism or reluctance... 

 I am not familiar with the compiler internals, but executable speed surely

 can still be optimized a lot. I'm sure Florian, Sven or Jonas can point to

 things that can use some work. 

 Michael. 

 _______________________________________________
 fpc-devel maillist - fpc-devel at lists.freepascal.org [1]
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

 

Links:
------
[1] mailto:fpc-devel at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190209/561cbe0a/attachment.html>