this all started as a thread on github: https://github.com/ericlyon/pd-fftease/issues/45
since i think it is of general interest (and i'm pretty sure i will never ever find the relevant info under the "time for a new release? (FFTease-3.1)" thread again, i'm taking this discussion here.
the thread mainly revolves around how to create a single deken-package that contains binaries for all the relevant architectures. i'm too lazy to recap it here.
the current discussion state is, how to deal with all those arm-variants out there.
if somebody has more insight into the arm architectures, please shed a light :-)
::::::
it's not complicated: the 32bit arm variants `armv6`, `armv7`, `armv8` (aka `aarm32`),... are backwards compatible. - you can run a binary compiled for `armv6` on any `armv7` or `armv8` CPU. - you can run a binary compiled for `armv7` on any `armv8` CPU. - but you cannot run a binary compiled for `armv8` on the older `armv7` resp `armv6` CPUs (missing instruction set) - similarly, you cannot run a binary compiled for `armv7` on the older `armv6` CPU.
it's very similar to `i386` and `i686` and `Pentium-i7` and the like. typically, the newer CPUs will have instruction sets that outperform the older CPUs (`MMX/SSE/AVX` on the `x86` platform; `NEON` on `arm`). however, if you have a modern `Pentium-i7` and you are running an `i386`-compatible binary you will probably still get decent performance, because the processor is so much faster. with `arm`-chipsets it is a bit different, as they are much less powerful, so you hit the limitations sooner.
@porres wrote:
I'm confused now, does this mean Raspbian is just for RPi Zero/1?
it means that you can use Raspbian on the RPi Zero/1/2/3 and 4. however, you will get sub-optimal performance on the RPi2 and above.
if you enable the normal Debian repositories on the RPi, you will get into trouble on the RPi Zero/1, as the binaries might (and most likely: will) have instructions that the RPi Zero/1 lacks.
so i'm confused, is the organelle a rasp 1?
it all depends on which version you have. the [current specs](https://www.critterandguitari.com/organelle#design-specs) mention a `ARM Cortex A53` which is an `aarch64` processor (`armv8`)
@emviveros wrote
"compute module" are not important since **RPizero variants are
important**, so armv6 should be disponible.
i'm not sure i understand what you mean. i tried to say, that i believe that - "compute module" is not important - RPi/zero is of (limited) importance - because of the RPi/zero we probably want to support `armv6`
i guess you are saying the same(?)
and
My first annoying is how to name armv6, armv7 and armv8 (aarch64)
binaries to create a unified deken package for arm compilations.
i don't know what this means either. however, i think we should forget about a unified `arm32` deken package.
armv6 = ?? (maybe .pd_linux) armv7 = .l_arm armv8 = .l_arm64
to which @porres answered:
anyway, let's just have these 3 together and I guess there won't be
any issues :)
at least for me, `armv8` is not the same as `aarch64`. most `armv8` are capable of both 32bit (`aarch32`) and 64bit (`aarch64`) instruction sets, but the 64bit part is optional. i'd prefer to use the `armv8` name for the 32bit variant *only*. when talking about the 64bit variant, we should use `aarch64`.
regarding `armv6` and `armv7` in a single folder, i'm not sure whether this would work: - if a `Pd-armv7` happens to see the `armv6` external first, it will just load it (and never try to `armv7` binary) - if a `Pd-armv6` happens to see the `armv7` external first, it will just try load it: and i think the *loading* would succeed, leading to crashes whenever an illegal (armv7-)instruction is encountered.
but as i've written above: the `armv6` is a very limited platform. you probably do not want to install any binaries that you cannot use on it anyhow. so i'd suggest to cram all the architectures into a fat deken package with the exception of `armv6` which you should package separately.
mgfds IOhannes
On 4/14/21 20:08, porres wrote:
armv6 = ?? (maybe .pd_linux) armv7 = .l_arm armv8 = .l_arm64
well, yeah, if we have just a package for raspbrry pis, then we can pack these 3 together, of course!!!
pd_linux was listed for Linux-amd64-32 (regular 64 bits Linux), so the problem would be to pack this with it as well - unless there's something else specfic for this architecture.
.pd_linux is the generic externsion for Pd-externals under linux - regardless of architecture. Pd on Linux will look for this extension on DEC/alpha, RPi/zero, i386 and HAL/9000. the arch-specific extenion for i386 on linux is (of course) .l_i386 (if you've ever encountered a .d_i386 or .m_i386, you might see a pattern).
the arch-agnostic extensions (.pd_linux, .pd_darwin, .dll) are often used for i386, because in the olden days that was the only extension. if you happen to run a Pd<<0.40 chances are that you are using a 32bit Pd.
Anyway, I guess it makes sense to pack the 3 pi versions together, then the 2 linux also together (32/64 bits), then windows in the same way (32/64) and the mac fat binary for both 32/64 bits. 4 Packages instead of 8!
i cannot follow. why does it make sense to separate by OS? what's the advantage of having separate Windows and macOS packages, instead of a single package that contains both Windows and macOS binaries?
also, what are the "2 linux (32/64 bits)"?; i currently count "*5* linux (32/64 bits)" in this discussion alone.
sidenote: there actually *is* a reason to not lump all the binaries together: filename size. since the architectures are encoded in the filename, and filenames typically have a limited length (256 characters on many filesystems!), this limits the number of architectures you can possibly have in a single deken package.
i stumbled upon this when testing deken. however, i think in real-world, the deken package with most architectures is probably zexy (1*Darwin,2*Windows,4*Linux) which has a total filename size of 131 characters. Adding the missing Darwin/i386 and Linux/armv6 and the legacy Darwin/ppc, would give us 182 chars, which still has a bit of headroom before becoming an actual problem.
mgdsr IOhannes
On 4/14/21 22:10, IOhannes m zmölnig wrote:
the arch-agnostic extensions (.pd_linux, .pd_darwin, .dll) are often used for i386, because in the olden days that was the only extension. if you happen to run a Pd<<0.40 chances are that you are using a 32bit Pd.
and actually, if you care for older Pd-versions, you should use .pd_linux as the extension for Linux/amd64, as .l_amd64 is only supported since Pd-0.49 (and we don't want to get back to that abomination older versions of Pd would use for that platform).
mfdsf IOhannes
Em qua., 14 de abr. de 2021 às 17:16, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 4/14/21 22:10, IOhannes m zmölnig wrote:
the arch-agnostic extensions (.pd_linux, .pd_darwin, .dll) are often used for i386, because in the olden days that was the only extension. if you happen to run a Pd<<0.40 chances are that you are using a 32bit
Pd.
and actually, if you care for older Pd-versions, you should use .pd_linux as the extension for Linux/amd64, as .l_amd64 is only supported since Pd-0.49 (and we don't want to get back to that abomination older versions of Pd would use for that platform).
I see zexy has .pd_linux for Linux/amd64 instead of .l_amd64 so I guess it's because you care :)
mfdsf IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em qua., 14 de abr. de 2021 às 17:10, IOhannes m zmölnig zmoelnig@iem.at escreveu:
why does it make sense to separate by OS? what's the advantage of having separate Windows and macOS packages, instead of a single package that contains both Windows and macOS binaries?
none other than download size, I guess.
also, what are the "2 linux (32/64 bits)"?
the remaining two that are not for raspberry pis
and actually, if you care for older Pd-versions
I personally couldn't care less :)
Em qua., 14 de abr. de 2021 às 16:47, IOhannes m zmölnig zmoelnig@iem.at escreveu:
i'm too lazy to recap it here.
Here's a recap. Me and Esteban were providing 4 separate packages for raspberry pis, and we were doing the same for FFTease and LyonPotPourri, but we know that was probably stupid and wanted to do better :)
Zexy provides two packages for raspberry pis in the same bundle:
- (Linux-arm64-32): with the binary *.l_arm64* - (Linux-armv7-32): with the binary *.l_arm*
We had these as separate packages and *.pd_linux* binaries on each. Actually, all 6 Linux packages (4 for raspberry) had this same extension.
As for the extra two raspberry, we have (Linux-armv6-32) and (Linux-armv8-32). The armv8-32 seems to serve no purpose at all! So we just need to get rid of it. Then we have (Linux-armv6-32), which is not completely out of purpose, but is rather obscure (just actually needed for raspberry pi zero, for instance).
i'd prefer to use the `armv8` name for the 32bit variant *only*. when talking about the 64bit variant, we should use `aarch64`.
So, just to be clear, 'armv8' is the unnecessary (Linux-armv8-32) deken package, and the other one ('aarch64') is (Linux-arm64-32).
Now, one thing is weird, cause Eric was using the organelle with deken and he could only see (Linux-armv6-32) instead of (Linux-armv7-32), is this a deken issue?
regarding `armv6` and `armv7` in a single folder, i'm not sure whether
this would work:
- if a `Pd-armv7` happens to see the `armv6` external first, it will
just load it (and never try to `armv7` binary)
- if a `Pd-armv6` happens to see the `armv7` external first, it will
just try load it: and i think the *loading* would succeed, leading to crashes whenever an illegal (armv7-)instruction is encountered.
but as i've written above: the `armv6` is a very limited platform. you probably do not want to install any binaries that you cannot use on it anyhow. so i'd suggest to cram all the architectures into a fat deken package with the exception of `armv6` which you should package separately.
But one can also just ship armv6 and aarch64 and it should work for everybody, right? The armv7 would still see it and load, and in fact this seems to be already happening on deken.
cheers
On 4/14/21 22:41, Alexandre Torres Porres wrote:
Em qua., 14 de abr. de 2021 às 16:47, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Now, one thing is weird, cause Eric was using the organelle with deken and he could only see (Linux-armv6-32) instead of (Linux-armv7-32), is this a deken issue?
not really. if you obtained puredata from the raspbian repositories (as opposed to the Debian repositories), or compiled it yourself (without paying careful attention, using the raspbian provided toolchain - iirc), you would get a Pd-armv6. now Pd reports to deken which architecture it supports, but the code is just some compile-time #ifdef magic, and doesn't actually query the CPU capabilities. the net result of this is that Pd tells deken that it supports armv6, but not armv7 (or - heaven forbid - armv8) - so that's why you can only see arvm6-externals (unless you manually configure deken to use "Linux-armv7-32")
see also https://github.com/pure-data/deken/issues/206
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.
fgsrasd IOhannes
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).
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*.
Now, my understanding is that *aarch64* can't run anything else other than this... can it run *armv6* and *armv7*?
As for benchmarking and me saying we could just ship armv6 that it'll work on armv7, I guess it makes sense to benchmark this.
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
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
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
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
On 4/15/21 18:49, Martin Peach wrote:
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.
i don't think we should make this specific to any given architecture. even it is offered on all platforms, or on none.
however, i do see great potential that automatic builds will fail more often than succeed.
that said: i find the idea somewhat intriguing.
mgTDS IOhannes
On 4/15/21 18:26, Alexandre Torres Porres 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.
yes.
The only issue is that deken might not give the armv6 option for armv7.
why would it not? since armv7 is backward compatible with armv6, deken will offer to install either of the two architectures if it believes that it is running on armv7. (and it will only offer armv6 if it believes that it is running on armv6)
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.
alternatively: find some simple enough code to do runtime detection of the actual arm CPU.
gfSDR IOhannes
Em qua., 14 de abr. de 2021 às 16:47, IOhannes m zmölnig zmoelnig@iem.at escreveu:
regarding `armv6` and `armv7` in a single folder, i'm not sure whether this would work:
- if a `Pd-armv7` happens to see the `armv6` external first, it will
just load it (and never try to `armv7` binary)
- if a `Pd-armv6` happens to see the `armv7` external first, it will
just try load it: and i think the *loading* would succeed, leading to crashes whenever an illegal (armv7-)instruction is encountered.
Ok, I got questions now on how loading works. We know .pd_linux for instance, can be used generically for any architecture. But I guess Pd knows if that .pd_linux file is actually good or not. Like, let's get the zexy bundle, for instance, you have 4 linux versions there and one is .pd_linux, how do the other 3 know that this .pd_linux. is not for them, right? Same thing would be true for other generic extensions such as .dll I assume.
But then, there may be an exception here only for armv6 x armv7, where it just can't really know, right?
Thanks IOhannes for your explanations.
So I'm convinced be good to have a unified binary package. To achieve that I understand we need to ship only armv6 and aarch64 archs for RPi once armv7 can insert noise in Pd external loading system.
I don't know how to benchmark armv6 and armv7 compilations, but I think maybe armv7 binaries can be provided via github repository for users who want to try it. This because I'm thinking deken packages need to work every time.
About .pd_linux extension. If every pd compiled arch can run .pd_linux extension it can be loaded inadvertently and cause crash to load external. So we need ever to name binaries in the new way (new for me at least) aka l_i386 , l_amd64 , l_arm, l_arm64 and so on for other OSs...
The older Pd version which theoretically stay alive is 0.48.1-3 in Ubuntu Bionic which is supported until April 2023. If this version of Pd have deken support, how can we differ the unified version of a specific i386 and amd64 binaries shipped in distinct dek packages? I think maybe these old system can be supported via github repository once add more two packages teoretically would add noise to the majority of users (newest pd versions).
Make sense?
Em qua., 14 de abr. de 2021 às 19:34, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qua., 14 de abr. de 2021 às 16:47, IOhannes m zmölnig zmoelnig@iem.at escreveu:
regarding `armv6` and `armv7` in a single folder, i'm not sure whether this would work:
- if a `Pd-armv7` happens to see the `armv6` external first, it will
just load it (and never try to `armv7` binary)
- if a `Pd-armv6` happens to see the `armv7` external first, it will
just try load it: and i think the *loading* would succeed, leading to crashes whenever an illegal (armv7-)instruction is encountered.
Ok, I got questions now on how loading works. We know .pd_linux for instance, can be used generically for any architecture. But I guess Pd knows if that .pd_linux file is actually good or not. Like, let's get the zexy bundle, for instance, you have 4 linux versions there and one is .pd_linux, how do the other 3 know that this .pd_linux. is not for them, right? Same thing would be true for other generic extensions such as .dll I assume.
But then, there may be an exception here only for armv6 x armv7, where it just can't really know, right?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
We just uploaded new packages for a new release of ELSE.
We have 3 raspberry pi in the same package: armv6 as .pd_linux / armv7 as .l_arm and aarch64 as .l_arm64
I know, we talked about problems of having both armv6/armv7 in the same folder. We'll see...
Em qua., 14 de abr. de 2021 às 22:20, Esteban Viveros emviveros@gmail.com escreveu:
I don't know how to benchmark armv6 and armv7 compilations
It's easy, just try [clone] with a loaded external with several copies, compare the CPU between the 2 binaries.
You have an armv7, right? You can do it then. If the armv7 binary does not have a significant improvement, I guess we can just delete it from our bundle pack, and probably provide a single bundle for the 4 Linux architectures.
So, for now we have 5 linux architectures in two packages, the only way I couldn't fit them in one single package, and the only way. could have 2 and not 3 packages was to put both armv6 and armv7 in the same one. But we'll improve this for the next time and as this discussion progresses.
cheers
On 4/15/21 12:33 AM, Alexandre Torres Porres wrote:
Ok, I got questions now on how loading works. We know .pd_linux for instance, can be used generically for any architecture. But I guess Pd knows if that .pd_linux file is actually good or not. Like, let's get the zexy bundle, for instance, you have 4 linux versions there and one is .pd_linux, how do the other 3 know that this .pd_linux. is not for them, right? Same thing would be true for other generic extensions such as .dll I assume.
Pd doesn't do any loading. it defers this to the operating system.
the OS will open the file and perform some header checks, to know whether the contents of the file is actually a loadable library. once it has established that it is, the library is loaded. and as soon as you run a library function, the machine code encoded in the binary is executed. the important part here, is that the sanity checks are only done during the load process and it's only the meta-information (the header) that is inspected. now the header typically lists the Operating System ABI (see [1], which includes the target architecture. however, there are zillions of slightly different CPUs out there, so - like Pd and deken - this architecture field only gives the *CPU family*, rather than the specific processor. if the CPU family of the binary is incompatible with the current runtime, then the library cannot be loaded. this is why we can have a zexy.pd_linux that is really Linux/amd64 without any problems, even if we are installing the library on a RPi: Pd will try to load the file, but the OS will tell it that it can't. so Pd will just try the next file and eventually and hopefully will come across a zexy-binary that matches the CPU family for the RPi.
if the CPU family of the binary does match the CPU family of the current runtime, then the library is loaded. if during execution the CPU encounters an unknown instruction (e.g. an SSE4 instruction on an old i386 CPU), it will segfault with an "illegal instruction" error.
But then, there may be an exception here only for armv6 x armv7, where it just can't really know, right?
as said above, it's actually the very same for other CPUs as well. if you have Mac Mini, October 2014 (that comes with the Haswell variant of the intel CPU) and try to run a binary that was optimized for an intel Coffee Lake CPU (Mac Book Pro, July 2018), you are likely to experience illegal-instruction segfaults.
that's why binaries are usually built for a more generic "baseline CPU" (unless your specific usecase actually demands all the processing power you can ever get, in which case you either need to self-compile turning on heavy optimization for your target CPU; or hope that the vendor provides a separate binary specifically targetted at your CPU)
gfmasdr IOhannes
[1] here's the description of the linux ELF format; on macOS and W32 other formats are used, but the idea is the same: https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_header
-
Alexandre Torres Porres -
Esteban Viveros -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach