[fpc-devel] An interesting thought... AI
J. Gareth Moreton
gareth at moreton-family.com
Fri Nov 11 00:44:09 CET 2022
I wouldn't advocate a neural network within FPC since, yes, it would be
unbelievably slow, very difficult to port and even more difficult to
maintain and verify... not just to confirm correct output (e.g. BSR is
good as an approximation to the expression "floor(log2(x))", but it has
some awkwardness if the input is zero) but also to ensure something
undesired (i.e. a backdoor) hasn't been slipped inside the assembly
language. I would be curious to see a neural net be able to improve on
small algorithms though.
My slight concern is that the x86 peephole optimizer is becoming pretty
bloated now, mostly thanks to my slightly haphazard development (I see a
source of improvement in a particular set of circumstances), and while
studying a diff of the output, I see another block of assembly language
nearby and think 'that could be improved too', and the end result is a
massive jungle of "if... then" blocks, which I suppose is the ultimate
building block of artificial intelligence (one for Sven... "The Diamond
Age" by Neal Stephenson has characters use the term "pseudo
intelligence" instead, with the characters remarking that it's more
Ultimately I want to look for cleaner and more fundamental solutions
since each new feature makes the compiler more bloated. Then again, if
you compare the speed and size of the generated binaries between the
trunk and a couple of releases ago, the difference is paramount. I
can't remember the proverb that Florian used (in a sense, approving of
small peephole optimizer changes), but one I learned in Chinese martial
arts would be "the journey of a thousand miles starts with a single
step"... lots and lots of small changes that individually are almost
pointless, but which build up over time and when you look back at the
starting point, the difference becomes very apparent.
To get back to the point, I wouldn't advocate giving FPC a neural
network, or any compiler really except as a development aid, with
generated results having an implicit "hey, might this work?" for the
developer. Random instruction changes doesn't feel particularly robust
though, and I would wonder if a neural net would work out how to change,
say "y := x div 3;" to "y := High32Bits(x * $AAAAAAAB) shr 1" ...
essentially turning a division by a constant into a multiplication by
its reciprocal, which a lot of compilers use (including FPC on x86 and
AArch64) to get around the integer division instruction being rather slow.
On 10/11/2022 23:08, Karoly Balogh via fpc-devel wrote:
> On Thu, 10 Nov 2022, Sven Barth via fpc-devel wrote:
>> You still need to feed the model with the necessary rules and with
>> necessary training data of both correct and incorrect approaches.
>> But even then *I* wouldn't want to have any of that black box mambo
>> jumbo in FPC, cause when a bug occurs in the optimizations due to some
>> decision the model made... well... tough luck.
> Well, a few years back I read a paper (maybe it was linked before in the
> thread no idea), that embraced this, and used a genetic algorithm for
> optimization, basically, took the default compiler output, and just
> started to change instructions randomly to see if it performed better...
> 99,99999% cases it crashed, but eventually there was a version that
> performed better. So for the next iteration that was taken as baseline.
> (Of course, with the necessary state-verifications surrounding the code.)
> Now, I could still see a billion ways this could fall apart (what if you
> change input data, so you have to combine it with some fuzzing too for
> sure?), but it was an interesting idea nevertheless. And of course,
> unbelievably slow.
> Anyway, until a simple memory layout change and pure chances of caching in
> a live system change can cause huge differences in code performance,
> sometimes bigger changes than the optimizer can make(!) the entire
> excercise is largely pointless, IMO. As much as one of course don't want
> to generate total junk as code, in real world applications there are
> usually bigger wins to be had just by improving the used algorithms.
> (I've seen a talk about this once, where they basically measured GCC's
> optimizer against caching and code layout changes, and the optimizer's
> effect was mostly within measurement error, apart from a few big things
> like register variables... Which is nuts.)
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel