[fpc-devel] Vectorisation, optimisation etc.

Ben Grasset operator97 at gmail.com
Sun Apr 7 03:25:40 CEST 2019


On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <jeppe at j-software.dk> wrote:

> Perhaps but it's a nightmare in so many places to satisfy requirements for
> potential uses. Ideally the programmer would specify minimum alignment
> requirements per type
>

Actively worrying about alignment in the vast majority of cases is about
the least ideal thing I can imagine. As far as I can gather the whole point
of the -Sv flag is that it's just a magic thing that makes it possible to
do SomeArray + SomeArray or SomeArray * SomeArray in a highly performant
way. (Which it does, *mostly*, right now.)

On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <jeppe at j-software.dk> wrote:

> But you will not find anyone who don't think vector extensions are better
> for software than SIMD. ARM SVE and RISC-V Vector extensions are true
> vector extensions, whereas the  SSE, AVX, NEON, Advanced SIMD, etc are
> packed SIMD extensions requiring a ton of hoops and jumps to use in real
> block vectorized code
>
 I don't disagree with your general point, however, you seem to be making a
(strange IMO) assumption that the *majority* (or even close to it) of
people who care about Free Pascal in any way whatsoever are using ARM or
RISC-V machines as their "daily drivers", *right now.*

If you honestly can't see why that blatantly is not the case, I'm not sure
what to tell you. If that *was* anywhere close to the case, do you think
there'd still be so many people out there rambling on about how great
Delphi 7 was and how they think generics make their code slower, and other
such nonsense? I think not.

On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <jeppe at j-software.dk> wrote:

> Do you have any quantifiable data to point at here?
>
Well, uh, presumably you've heard of LLVM? There's a reason every big
compiler project implemented with it has first-class language bindings to
its intrinsics, and that reason is not "just for fun."

Putting LLVM aside even, at the highest possible settings GCC / G++ still
runs circles around FPC for reasons that in many cases are *not* related to
it doing really crazy optimizations, but just to it being able to properly
auto-vectorize code in general.

Even the fact that FPC will not / cannot inline "procedure variable" calls
is far from great. Just that alone would result in enormous speedups in a
huge amount of places...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190406/29c7df21/attachment.html>


More information about the fpc-devel mailing list