[PD-dev] multi-architecture deken packages

[Martin Peach]

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 at 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 at 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 at 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 at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev