Given that deken already lets you ship the source along with the binaries, it seems better (to me at least) if deken could also build them on the actual machine that will be running them. At least for the linux Pis and Beaglebones, which almost always have the toolchains installed by default.
Yes... It can work.! Considering that the external is pdlibbuilder friendly it can be much simple for special cases...
Em qui., 15 de abr. de 2021 às 14:16, Martin Peach chakekatzil@gmail.com escreveu:
Given that deken already lets you ship the source along with the binaries, it seems better (to me at least) if deken could also build them on the actual machine that will be running them. At least for the linux Pis and Beaglebones, which almost always have the toolchains installed by default. So you could provide a basic binary that will run on any arm cpu, but also the possibility to build an optimized version.
Martin
On Thu, Apr 15, 2021 at 12:27 PM Alexandre Torres Porres porres@gmail.com wrote:
Thanks for all the clarifications, it's still hard for me to follow it
all, but I think I got the most of it :)
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.
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.
Anyway, me and Esteban will do the tests for armv6 vs armv7 in his RPi 3!
Cheers
Em qui., 15 de abr. de 2021 às 08:25, IOhannes m zmölnig <
zmoelnig@iem.at> escreveu:
On 4/14/21 23:59, Alexandre Torres Porres wrote:
Em qua., 14 de abr. de 2021 às 18:29, IOhannes m zmölnig <
zmoelnig@iem.at>
escreveu:
But one can also just ship armv6 and aarch64 and it should work for everybody, right?
as said before: somebody should do some benchmarking how much gain
there
is for armv7 with respect to armv8.
I don't understand because I was talking about *armv6*
(Linux-armv6-32) and
*aarch64* (Linux-arm64-32).
the "as said before" was referring to some other mails years ago. iirc, something that triggered https://lists.puredata.info/pipermail/pd-list/2019-06/125453.html
You said it yourself that we should use *armv8* for the 32 bit variant (Linux-armv8-32), and *aarch64* for this other one. We're also
agreeing
*armv8*/Linux-armv8-32 is pointless. So I guess you mean armv8 as (Linux-arm64-32) and *aarch64*.
no. i'm pretty sure i meant 32bit arm architectures. i think the main concern is the speed-boost between armv6 vs armv7. the latter has (usually) better support for (single precision) floating point math, and might give a significant speed gain when doing signal processing.
otoh, it might not be able to fully utilize the additional instruction set if there's no explicit code for it (as would be typical for pd-extenrals) (see also http://single-boards.com/armv6-vs-armv7/)
that's why i keep mentioning benchmarks.
the armv7 vs armv8 (aarch32!) debate is basically the same, though i guess(!) speed improvements might not be as prominent.
Now, my understanding is that *aarch64* can't run anything else other
than
this... can it run *armv6* and *armv7*?
can you run intel/32bit externals on your intel/64bit mac book? yes can you run intel/32bit externals within your Pd-intel/64bit on that same mac book? no
fgmsard IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev