<div dir="ltr">Thanks for all the clarifications, it's still hard for me to follow it all, but I think I got the most of it :) <br><br>Bottom line, we gotta test a RPi with binaries for armv6 and armv7,  if no significant improvement is found on armv7 (and there might not be), let's just ship armv6.<br><br>The only issue is that deken might not give the armv6 option for armv7. But the funny part is that most people with a RPi 3 and stuff end up getting armv6 instead anyway :) not sure what to do about that. Hopefully this information for RPi users can be easily found.<div><br></div><div>Anyway, me and Esteban will do the tests for armv6 vs armv7 in his RPi 3! </div><div><br></div><div>Cheers<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 15 de abr. de 2021 às 08:25, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/14/21 23:59, Alexandre Torres Porres wrote:<br>
> Em qua., 14 de abr. de 2021 às 18:29, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>><br>
> escreveu:<br>
> <br>
>>> But one can also just ship armv6 and aarch64 and it should work for<br>
>>> everybody, right?<br>
>><br>
>> as said before: somebody should do some benchmarking how much gain there<br>
>> is for armv7 with respect to armv8.<br>
>><br>
> <br>
> I don't understand because I was talking about *armv6* (Linux-armv6-32) and<br>
> *aarch64* (Linux-arm64-32).<br>
<br>
the "as said before" was referring to some other mails years ago.<br>
iirc, something that triggered<br>
   <a href="https://lists.puredata.info/pipermail/pd-list/2019-06/125453.html" rel="noreferrer" target="_blank">https://lists.puredata.info/pipermail/pd-list/2019-06/125453.html</a><br>
<br>
> <br>
> You said it yourself that we should use *armv8* for the 32 bit variant<br>
> (Linux-armv8-32), and *aarch64* for this other one. We're also agreeing<br>
> *armv8*/Linux-armv8-32 is pointless. So I guess you mean armv8<br>
> as (Linux-arm64-32) and *aarch64*.<br>
<br>
no. i'm pretty sure i meant 32bit arm architectures.<br>
i think the main concern is the speed-boost between armv6 vs armv7.<br>
the latter has (usually) better support for (single precision) floating <br>
point math, and might give a significant speed gain when doing signal <br>
processing.<br>
<br>
otoh, it might not be able to fully utilize the additional instruction <br>
set if there's no explicit code for it (as would be typical for <br>
pd-extenrals)<br>
(see also <a href="http://single-boards.com/armv6-vs-armv7/" rel="noreferrer" target="_blank">http://single-boards.com/armv6-vs-armv7/</a>)<br>
<br>
that's why i keep mentioning benchmarks.<br>
<br>
the armv7 vs armv8 (aarch32!) debate is basically the same, though i <br>
guess(!) speed improvements might not be as prominent.<br>
<br>
<br>
> <br>
> Now, my understanding is that *aarch64* can't run anything else other than<br>
> this... can it run *armv6* and *armv7*?<br>
<br>
can you run intel/32bit externals on your intel/64bit mac book? yes<br>
can you run intel/32bit externals within your Pd-intel/64bit on that <br>
same mac book? no<br>
<br>
fgmsard<br>
IOhannes<br>
_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
</blockquote></div>