[PD-dev] multi-architecture deken packages

[Esteban Viveros]

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


-- 

 Esteban Viveros

www.estebanviveros.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210415/3d9451c7/attachment-0001.htm>