<div dir="ltr"><div dir="ltr">On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <<a href="mailto:jeppe@j-software.dk">jeppe@j-software.dk</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
        </div>
      </div>
    </blockquote>
    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<br></div></blockquote><div><br></div><div>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.)</div><div><br></div><div><div dir="ltr">On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <<a href="mailto:jeppe@j-software.dk">jeppe@j-software.dk</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"></div></div></blockquote><p>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</p></div></blockquote><div> 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.*</div><div><br></div><div>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.</div><div><br></div><div><div dir="ltr">On Sat, Apr 6, 2019 at 6:56 PM Jeppe Johansen <<a href="mailto:jeppe@j-software.dk">jeppe@j-software.dk</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"></div></div></blockquote><p>Do you have any quantifiable data to point at here?</p></div></blockquote><div>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."</div><div><br></div><div>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.<br></div><div><br></div><div>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...</div></div></div></div></div></div></div>