[fpc-devel] Vectorisation, optimisation etc.

[Jeppe Johansen]

On 4/7/19 12:16 AM, Ben Grasset wrote:
> On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen <jeppe at j-software.dk 
> <mailto:jeppe at j-software.dk>> wrote:
>
>     That can't happen or won't benefit much, before the compiler
>     supports super-natual alignments. So there's a deeper level of
>     support needed.
>
> I'm fairly confident the existing functionality could be improved upon 
> in a useful way. Gareth has already done so in the past.
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
>  On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen <jeppe at j-software.dk 
> <mailto:jeppe at j-software.dk>> wrote:
>
>     And personally I don't think that's the right long term direction.
>     It takes a long time to develop and maintain this stuff and you
>     never know what the market will look like in 10 years.
>     ARM has SVE, and RISC-V has the upcoming vector extension which
>     will move far away from the traditional SIMD stuff.
>
> I sincerely doubt I will be using a RISC-V based desktop PC in 10 
> years. Also nobody said -Sv could not also be extended to stuff such 
> as ARM Neon at some point down the line if someone was up to it. One 
> thing at a time though.

It's too hard to say, and the RISC-V foundation has made really bad 
decisions that will prevent them from getting a good start.

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

> On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen <jeppe at j-software.dk 
> <mailto:jeppe at j-software.dk>> wrote:
>
>     Compiler support for block vectorization has rarely paid off
>     really well given the amount of work that needs to go into it. So
>     maybe it's better to wait for the next iteration :)
>
> It very objectively pays off in every compiler that has it. I don't 
> think "it's too hard" is a good excuse. I made my previous comment 
> because it seems like Gareth if anyone specifically does *not* think 
> it is too hard.
Do you have any quantifiable data to point at here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190407/6d8246f2/attachment.html>