Hi list,
is double-precision Pd a possible way to get around interpolation artifacts (B16.long-varispeed.pd) for tabread4~ and delread4~?
I found out that I can have both, single and double precision Pd, installed in parallel in Debian, thank's to IOhannes clever packaging.
From the few sources explaining pd64
http://puredata.info/downloads/pd-double https://www.katjaas.nl/doubleprecision/doubleprecision.html I suspect that externals have to be compiled for double precision as well? Will I have to install specific externals via Deken or apt then? Are all™ such externals available in both flavours?
From skimming Katja's article, I understand that memory usage of patches
in pd64 will be larger than in single precision. Will cpu usage also increase?
Thanks for any help understanding this better! cheersz, P
I think that's right. The need for the long-varispeed hack is just that 32-bit floats don't have enough precision to address long tables with fractional indices, 64-bit samples should have enough that the remaining addressing imprecision would be far below the errors introduced in either case by the 4-point interpolation used in delread4~.
cheers
Miller
On 5/26/24 9:40 AM, Peter P. wrote:
Hi list,
is double-precision Pd a possible way to get around interpolation artifacts (B16.long-varispeed.pd) for tabread4~ and delread4~?
I found out that I can have both, single and double precision Pd, installed in parallel in Debian, thank's to IOhannes clever packaging.
From the few sources explaining pd64 https://urldefense.com/v3/__http://puredata.info/downloads/pd-double__;!!Mih... https://urldefense.com/v3/__https://www.katjaas.nl/doubleprecision/doublepre... I suspect that externals have to be compiled for double precision as well? Will I have to install specific externals via Deken or apt then? Are all™ such externals available in both flavours?
From skimming Katja's article, I understand that memory usage of patches in pd64 will be larger than in single precision. Will cpu usage also increase?
Thanks for any help understanding this better! cheersz, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." peterparker@fastmail.com:
I suspect that externals have to be compiled for double precision as well?
Yes (well: there are some exceptions, but those are very niche)
Will I have to install specific externals via Deken or apt then?
Via deken: only externals that are compatible will be shown. So when running Pd64, you will only see externals that can deal with double precision (or are precision agnostic, eg pure abstractions).
Via apt: *most* externals are built for both precisions, in a single binary package (eg "pd-zexy" hat both pd32 and pd64). Caveats:
- I'm currently afk and don't really know the state in Debian/stable (bookworm) by heart (as I'm mostly working with testing/unstable)
- the packages that provide pd64 binaries have an (alternative) dependency on "puredata64" (so they can be installed on a system that *only* has pd64)
- however there's no other marker that marks them as pd64 compatible (they should probably have something like "Provides: pd64-zexy"
- the apt plugin for deken ("pd-deken-apt") does not handle pd64 externals at all (and will happily install pd32 externals)
Are all™ such externals available in both flavours?
No.
From skimming Katja's article, I understand that memory usage of patches in pd64 will be larger than in single precision.
Mostly not. at least not on 64bit systems (eg the "amd64"/"x86_64" and "arm64" archs). On "i386" and "armhf" (old raspberries) the memory footprint will be doubled.
Will cpu usage also increase?
Maybe. With 32bit floating point values, there are more CPU registers available, so the compiler could generate more optimized code. Also, it's easier to hit cache limits.
In practice I wouldn't give much about such conjectures and simply try it out with a specific patch. Of course, if you do test it would be nice if you could share some (meaningful) data...
mfg.sfg.jfd IOhannes
Am 26. Mai 2024 11:11:53 MESZ schrieb "IOhannes m zmölnig" zmoelnig@iem.at:
Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." peterparker@fastmail.com:
Will I have to install specific externals via Deken or apt then?
Via deken: only externals that are compatible will be shown. So when running Pd64, you will only see externals that can deal with double precision (or are precision agnostic, eg pure abstractions).
Also note that some maintainers might have chosen to upload separate pd32 and pd64 packages for their externals (as opposed to having a single package for both variants). If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Just so you know
mfg.sfg.jfd IOhannes
On Sun, 2024-05-26 at 11:16 +0200, IOhannes m zmölnig wrote:
If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Good to know. Is it correct to derive from this that it is (and will be) good practice to pack 32bit and 64bit flavors into the same package?
Roman
On 5/26/24 23:09, Roman Haefeli wrote:
On Sun, 2024-05-26 at 11:16 +0200, IOhannes m zmölnig wrote:
If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Good to know. Is it correct to derive from this that it is (and will be) good practice to pack 32bit and 64bit flavors into the same package?
yes. for now this is the proper way¹.
gmdsar IOhannes
¹ deken might gain more intelligence at one point, allowing it skip uninstallation if the version numer is the same. but do not wait for this feature.
- IOhannes m zmölnig zmoelnig@iem.at [2024-05-26 11:17]:
Am 26. Mai 2024 11:11:53 MESZ schrieb "IOhannes m zmölnig" zmoelnig@iem.at:
Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." peterparker@fastmail.com:
Will I have to install specific externals via Deken or apt then?
Via deken: only externals that are compatible will be shown. So when running Pd64, you will only see externals that can deal with double precision (or are precision agnostic, eg pure abstractions).
Also note that some maintainers might have chosen to upload separate pd32 and pd64 packages for their externals (as opposed to having a single package for both variants). If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Thanks, do both versions of the compiled externals have the identical filename extension then?
If yes, is there a way to have externals of both versions installed in parallel without specifying different install locations?
best, P
- Peter P. peterparker@fastmail.com [2024-05-27 08:41]:
- IOhannes m zmölnig zmoelnig@iem.at [2024-05-26 11:17]:
Am 26. Mai 2024 11:11:53 MESZ schrieb "IOhannes m zmölnig" zmoelnig@iem.at:
Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." peterparker@fastmail.com:
Will I have to install specific externals via Deken or apt then?
Via deken: only externals that are compatible will be shown. So when running Pd64, you will only see externals that can deal with double precision (or are precision agnostic, eg pure abstractions).
Also note that some maintainers might have chosen to upload separate pd32 and pd64 packages for their externals (as opposed to having a single package for both variants). If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Thanks, do both versions of the compiled externals have the identical filename extension then?
(Sorry, replying to myself here)
this seems the case, at least for apt-packaged zexy: $ dpkg -L pd-zexy | grep .pd_linux /usr/lib/pd/extra/zexy/zexy.pd_linux
...is the only file found.
best, P
/usr/lib/pd/extra/zexy/zexy.pd_linux ...is the only file found.
there are actually quite a few binaries for a variety of architectures and pd32 and pd64 in this case - with different file extensions: zexy.l_i386 zexy.pd_linux zexy.l_arm zexy.l_arm64 zexy.linux-i386-64.so zexy.linux-amd64-64.so zexy.linux-arm64-64.so zexy.linux-armv7-64.so
you can find these documented in https://msp.ucsd.edu/Pd_documentation/x4.htm#s4.1.2.1
cheers, ben
Am Mo., 27. Mai 2024 um 08:45 Uhr schrieb Peter P. peterparker@fastmail.com:
- Peter P. peterparker@fastmail.com [2024-05-27 08:41]:
- IOhannes m zmölnig zmoelnig@iem.at [2024-05-26 11:17]:
Am 26. Mai 2024 11:11:53 MESZ schrieb "IOhannes m zmölnig" zmoelnig@iem.at:
Am 26. Mai 2024 09:40:02 MESZ schrieb "Peter P." peterparker@fastmail.com:
Will I have to install specific externals via Deken or apt then?
Via deken: only externals that are compatible will be shown. So when running Pd64, you will only see externals that can deal with double precision (or are precision agnostic, eg pure abstractions).
Also note that some maintainers might have chosen to upload separate pd32 and pd64 packages for their externals (as opposed to having a single package for both variants). If both pd variants install into the same directory (which is the default), then installing the pd64 external will (by default) first remove the pd32 external. You can change this (in the deken preferences).
Thanks, do both versions of the compiled externals have the identical filename extension then?
(Sorry, replying to myself here)
this seems the case, at least for apt-packaged zexy: $ dpkg -L pd-zexy | grep .pd_linux /usr/lib/pd/extra/zexy/zexy.pd_linux
...is the only file found.
best, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 5/27/24 08:44, Peter P. wrote:
Thanks, do both versions of the compiled externals have the identical filename extension then?
no.
(Sorry, replying to myself here)
this seems the case, at least for apt-packaged zexy: $ dpkg -L pd-zexy | grep .pd_linux /usr/lib/pd/extra/zexy/zexy.pd_linux
...is the only file found.
$ dpkg -L pd-zexy | grep "zexy\."
/usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so
/usr/lib/pd/extra/zexy/zexy.pd_linux
mgfasdr IOhannes
- IOhannes m zmoelnig zmoelnig@iem.at [2024-05-27 11:51]:
On 5/27/24 08:44, Peter P. wrote:
Thanks, do both versions of the compiled externals have the identical filename extension then?
no.
(Sorry, replying to myself here)
this seems the case, at least for apt-packaged zexy: $ dpkg -L pd-zexy | grep .pd_linux /usr/lib/pd/extra/zexy/zexy.pd_linux
...is the only file found.
$ dpkg -L pd-zexy | grep "zexy\." /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so /usr/lib/pd/extra/zexy/zexy.pd_linux
Thanks for the correcty grep syntax.
Aja,pd-zexy 2.4.1-4 on my Debian stable system provides only /usr/lib/pd/extra/zexy/zexy.pd_linux but pd-zexy 2.4.3-1 on testing does contain both precisions then, brilliant!
So the bottom line might then be: Deken developers should ideally package both single and double precision binaries of their externals into the same package.
Deken users should note that newer version packages uninstall older version packages, as this might remove a single precision package when installing a double precision package with a higher version number (unless that feature is disabled in dekens preferences).
right?
best, P
While we're discussing pd64, can we make it 'official' and have it as 'non beta' for the next 0.55 release?
If Miller can't take care of yet this other compilation, he can put a link for p64 binaries in his website that redirects to 'puredata.info' p64 downloads.
I will only bother to compile ELSE and Cyclone when this is finally officially "ok" and easily available :)
If we agree to have this worked out I can also make the current state clearer on the documentation (manual and stuff).
cheers
Em seg., 27 de mai. de 2024 às 08:28, Peter P. peterparker@fastmail.com escreveu:
- IOhannes m zmoelnig zmoelnig@iem.at [2024-05-27 11:51]:
On 5/27/24 08:44, Peter P. wrote:
Thanks, do both versions of the compiled externals have the identical filename extension then?
no.
(Sorry, replying to myself here)
this seems the case, at least for apt-packaged zexy: $ dpkg -L pd-zexy | grep .pd_linux /usr/lib/pd/extra/zexy/zexy.pd_linux
...is the only file found.
$ dpkg -L pd-zexy | grep "zexy\." /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so /usr/lib/pd/extra/zexy/zexy.pd_linuxThanks for the correcty grep syntax.
Aja,pd-zexy 2.4.1-4 on my Debian stable system provides only /usr/lib/pd/extra/zexy/zexy.pd_linux but pd-zexy 2.4.3-1 on testing does contain both precisions then, brilliant!
So the bottom line might then be: Deken developers should ideally package both single and double precision binaries of their externals into the same package.
Deken users should note that newer version packages uninstall older version packages, as this might remove a single precision package when installing a double precision package with a higher version number (unless that feature is disabled in dekens preferences).
right?
best, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2024-05-27 at 11:50 +0200, IOhannes m zmoelnig wrote:
$ dpkg -L pd-zexy | grep "zexy\." /usr/lib/pd/extra/zexy/zexy.linux-amd64-64.so /usr/lib/pd/extra/zexy/zexy.pd_linux
On a somewhat related note, I tried my first floatsize=64 build and pd64 refused to load it. I only noticed after that I was using pd-lib- builder v0.6.0 and support for the floatsize=64 flag was only added in the v0.7.0.
Until I actually tried to load the binary with pd64, I had no indication that I was still building for pd (32bit). I wonder if there is an (easily scriptable) way of detecting the floatsize of the resulting binary. Messing things can happen quickly and I would like to avoid that as far as possible, of course.
Roman
Am 27. Mai 2024 23:13:56 MESZ schrieb Roman Haefeli reduzent@gmail.com:
Until I actually tried to load the binary with pd64, I had no indication that I was still building for pd (32bit). I wonder if there is an (easily scriptable) way of detecting the floatsize of the resulting binary.
Package your external with the deken cmdline tool?
(A poor man's substitute would be to just grep for class_new64)
mfg.sfg.jfd IOhannes
On Tue, 2024-05-28 at 06:07 +0200, IOhannes m zmölnig wrote:
Am 27. Mai 2024 23:13:56 MESZ schrieb Roman Haefeli reduzent@gmail.com:
Until I actually tried to load the binary with pd64, I had no indication that I was still building for pd (32bit). I wonder if there is an (easily scriptable) way of detecting the floatsize of the resulting binary.
Package your external with the
dekencmdline tool?
Works! (with an up-to-date Deken)
(A poor man's substitute would be to just grep for
class_new64)
Nice. That's what I was after. Thanks!
Roman
Em dom., 26 de mai. de 2024 às 04:41, Peter P. peterparker@fastmail.com escreveu:
From the few sources explaining pd64 http://puredata.info/downloads/pd-double https://www.katjaas.nl/doubleprecision/doubleprecision.html
Hmm, these are outdated sources that do not really mention the current Pd64 release. So it can be quite misleading and confusing. It should be edited/updated.
The actual source should and must be the Manual as well, by the way, but info about it is pretty limited so far, as this is not officially supported yet.
I will try to improve this a bit for the upcoming release, but I would also like to reinforce and ask about finally officially supporting this.
By the way, https://msp.ucsd.edu/Pd_documentation/x4.htm#s4.1.2.1 shows a table of possible extensions, and I have some questions.
Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as .m_amd64, .d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the idea was to create new extension possibilities to distinct single and double precision, right?
While we're at it, can i386 be 64? really? As in .linux-i386-64.so, .darwin-i386-64.so and .windows-i386-64.dll?
cheers
I suspect that externals have to be compiled for double precision as well? Will I have to install specific externals via Deken or apt then? Are all™ such externals available in both flavours?
From skimming Katja's article, I understand that memory usage of patches in pd64 will be larger than in single precision. Will cpu usage also increase?
Thanks for any help understanding this better! cheersz, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 5/29/24 21:03, Alexandre Torres Porres wrote:
Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as .m_amd64, .d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the idea was to create new extension possibilities to distinct single and double precision, right?
depends on what you mean by "can". technically they could. practically, Pd64 will *not* load an external that ends with .pd_darwin. see the mailinglist archives and the github issues for a lengthy discussion why it is like this.
While we're at it, can i386 be 64? really? As in .linux-i386-64.so, .darwin-i386-64.so and .windows-i386-64.dll?
sure, why not? the "double" floattype has been around for some time. a quick wikipedia check shows that one of the first (C)PU to implement IEEE 754 (the floating point standard that defines "double" floats as we know them) was the Intel 8087, a 16bit processor (and famous co-processor for the 8086) It would be capable of running Pd64 (".cpm-x86_16-64.so").
fmdsafds IOhannes
I see, not being well versed, I see I'm again confusing 64-bit architecture with double precision. And I'm still confused on what "CPU-architecture" actually means. Let's see if I get things straight.
Older macs with intel chips can run two different architectures: *i386* (Intel 32bit) and *amd64* (Intel 64bit). This depends on the OS and the last to allow i386 was Mojave (10.14). Newer arm64 is obviously only 64bit.
I'm positive this is what it is, but it still strikes me as a bit uncanny that a computer can have more than one architecture, as my intuition would tell me that the architecture of my chip can only be of one type. So I guess I don't really get the concept of "cpu-architecture".
Anyway, things like this should be made clearer for dummies like me in the manual and stuff.
Cheers
Em qua., 29 de mai. de 2024 às 18:44, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 5/29/24 21:03, Alexandre Torres Porres wrote:
Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as .m_amd64, .d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the
idea
was to create new extension possibilities to distinct single and double precision, right?
depends on what you mean by "can". technically they could. practically, Pd64 will *not* load an external that ends with .pd_darwin. see the mailinglist archives and the github issues for a lengthy discussion why it is like this.
While we're at it, can i386 be 64? really? As in .linux-i386-64.so, .darwin-i386-64.so and .windows-i386-64.dll?
sure, why not? the "double" floattype has been around for some time. a quick wikipedia check shows that one of the first (C)PU to implement IEEE 754 (the floating point standard that defines "double" floats as we know them) was the Intel 8087, a 16bit processor (and famous co-processor for the 8086) It would be capable of running Pd64 (".cpm-x86_16-64.so").
fmdsafds IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
While we're at it, as I only know about macOS, let me ask about windows and linux...
So, Windows 11, the current version, is only for 64 bit architectures, right? so one cannot install pd 32 bit on it.
As for Linux, is there any most recent version only for 64-bit architecture?
cheers
Em qua., 29 de mai. de 2024 às 21:13, Alexandre Torres Porres < porres@gmail.com> escreveu:
I see, not being well versed, I see I'm again confusing 64-bit architecture with double precision. And I'm still confused on what "CPU-architecture" actually means. Let's see if I get things straight.
Older macs with intel chips can run two different architectures: *i386* (Intel 32bit) and *amd64* (Intel 64bit). This depends on the OS and the last to allow i386 was Mojave (10.14). Newer arm64 is obviously only 64bit.
I'm positive this is what it is, but it still strikes me as a bit uncanny that a computer can have more than one architecture, as my intuition would tell me that the architecture of my chip can only be of one type. So I guess I don't really get the concept of "cpu-architecture".
Anyway, things like this should be made clearer for dummies like me in the manual and stuff.
Cheers
Em qua., 29 de mai. de 2024 às 18:44, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 5/29/24 21:03, Alexandre Torres Porres wrote:
Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as
.m_amd64,
.d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the
idea
was to create new extension possibilities to distinct single and double precision, right?
depends on what you mean by "can". technically they could. practically, Pd64 will *not* load an external that ends with .pd_darwin. see the mailinglist archives and the github issues for a lengthy discussion why it is like this.
While we're at it, can i386 be 64? really? As in .linux-i386-64.so, .darwin-i386-64.so and .windows-i386-64.dll?
sure, why not? the "double" floattype has been around for some time. a quick wikipedia check shows that one of the first (C)PU to implement IEEE 754 (the floating point standard that defines "double" floats as we know them) was the Intel 8087, a 16bit processor (and famous co-processor for the 8086) It would be capable of running Pd64 (".cpm-x86_16-64.so").
fmdsafds IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Le 30/05/2024 à 03:14, Alexandre Torres Porres a écrit :
While we're at it, as I only know about macOS, let me ask about windows and linux...
So, Windows 11, the current version, is only for 64 bit architectures, right? so one cannot install pd 32 bit on it.
As for Linux, is there any most recent version only for 64-bit architecture?
debian is known to run on multiples architecture : https://wiki.debian.org/SupportedArchitectures
anyway, you need a 64 bit OS if you want to address more than 3Go of memory.
cheers c
cheers
Em qua., 29 de mai. de 2024 às 21:13, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> escreveu:
I see, not being well versed, I see I'm again confusing 64-bit architecture with double precision. And I'm still confused on what "CPU-architecture" actually means. Let's see if I get things straight. Older macs with intel chips can run two different architectures: *i386* (Intel 32bit) and *amd64* (Intel 64bit). This depends on the OS and the last to allow i386 was Mojave (10.14). Newer arm64 is obviously only 64bit. I'm positive this is what it is, but it still strikes me as a bit uncanny that a computer can have more than one architecture, as my intuition would tell me that the architecture of my chip can only be of one type. So I guess I don't really get the concept of "cpu-architecture". Anyway, things like this should be made clearer for dummies like me in the manual and stuff. Cheers Em qua., 29 de mai. de 2024 às 18:44, IOhannes m zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at>> escreveu: On 5/29/24 21:03, Alexandre Torres Porres wrote: > Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as .m_amd64, > .d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the idea > was to create new extension possibilities to distinct single and double > precision, right? depends on what you mean by "can". technically they could. practically, Pd64 will *not* load an external that ends with .pd_darwin. see the mailinglist archives and the github issues for a lengthy discussion why it is like this. > > While we're at it, can i386 be 64? really? As in .linux-i386-64.so, > .darwin-i386-64.so and .windows-i386-64.dll? > sure, why not? the "double" floattype has been around for some time. a quick wikipedia check shows that one of the first (C)PU to implement IEEE 754 (the floating point standard that defines "double" floats as we know them) was the Intel 8087, a 16bit processor (and famous co-processor for the 8086) It would be capable of running Pd64 (".cpm-x86_16-64.so"). fmdsafds IOhannes _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2024-05-29 at 22:14 -0300, Alexandre Torres Porres wrote:
As for Linux, is there any most recent version only for 64-bit architecture?
No. Debian provides puredata (due to the work of IOhannes!) for the following architectures:
- amd64
- arm64
- armel
- armhf
- i386
- mips64el
- mipsel
- ppc64el
- s390x
From: https://packages.debian.org/search?keywords=puredata-core&searchon=names...
I don't know by heart which are 64 bit and which are not. i386 and armhf are certainly only 32 bit.
Double precision Pd is not yet in any stable release, but is available in testing for the following architectures:
- amd64
- arm64
- armel
- armhf
- i386
- mips64el
- ppc64el
- s390x
From: https://packages.debian.org/search?keywords=puredata64-core&searchon=nam... Roman
Am 30. Mai 2024 08:30:43 MESZ schrieb Roman Haefeli reduzent@gmail.com:
I don't know by heart which are 64 bit and which are not. i386 and armhf are certainly only 32 bit.
armel and mipsel are 32bit archs as well.
Double precision Pd is not yet in any stable release,
However, it's available in bookworm/backports (bookworm is the current stable release): https://packages.debian.org/bookworm-backports/puredata64-core
mfg.sfg.jfd IOhannes
Here's a quick primer:
When we say 32-bit or 64-bit architecture, we refer to the "word size". "word" is the natural unit of data processing for a given CPU. The word size is typically the size of the CPU's (integer) registers. Most importantly, it defines the size of pointers and thus the max. addressable memory within a given (virtual) memory space.
(There are some curious exceptions, such as x32 mode on amd64 platforms, but these can be ignored for practical purposes.)
Note that a 32-bit computer can still work with 64-bit data types, they just won't fit into a single register. Also note that on modern platforms floats/doubles are usually kept in special SIMD registers that are much wider than their integer counterparts (e.g. 256 bits with AVX on Intel).
The main takeaway is that word size and float size are completely orthogonal. In other words: a 32-bit program can use 64-bit integers or 64-bit doubles.
(On some platforms this comes with a performance cost, though. For example, the ESP32 is a 32-bit processor whose FPU only natively supports 32-bit floats, so 64-bit doubles are emulated in software.)
So, Windows 11, the current version, is only for 64 bit architectures, right? so one cannot install pd 32 bit on it.
No. 64-bit Windows has an emulation layer for 32-bit applications (the WoW subsystem). Just like Apple used to emulate PPC on its 32-bit Intel processors (Rosetta 1) and now emulates amd64 code on Apple Silicon (Rosetta 2). This is done to make the transition to another CPU architecture easier for the user because they can run their old programs.
Christof
On 30.05.2024 03:14, Alexandre Torres Porres wrote:
While we're at it, as I only know about macOS, let me ask about windows and linux...
So, Windows 11, the current version, is only for 64 bit architectures, right? so one cannot install pd 32 bit on it.
As for Linux, is there any most recent version only for 64-bit architecture?
cheers
Em qua., 29 de mai. de 2024 às 21:13, Alexandre Torres Porres porres@gmail.com escreveu:
I see, not being well versed, I see I'm again confusing 64-bit architecture with double precision. And I'm still confused on what "CPU-architecture" actually means. Let's see if I get things straight. Older macs with intel chips can run two different architectures: *i386* (Intel 32bit) and *amd64* (Intel 64bit). This depends on the OS and the last to allow i386 was Mojave (10.14). Newer arm64 is obviously only 64bit. I'm positive this is what it is, but it still strikes me as a bit uncanny that a computer can have more than one architecture, as my intuition would tell me that the architecture of my chip can only be of one type. So I guess I don't really get the concept of "cpu-architecture". Anyway, things like this should be made clearer for dummies like me in the manual and stuff. Cheers Em qua., 29 de mai. de 2024 às 18:44, IOhannes m zmölnig <zmoelnig@iem.at> escreveu: On 5/29/24 21:03, Alexandre Torres Porres wrote: > Can't .pd_linux, .pd_darwin, .d_fat, .dll be 64 bit? As well as .m_amd64, > .d_arm64 and .l_arm64 and stuff? I mean, probably they "can", but the idea > was to create new extension possibilities to distinct single and double > precision, right? depends on what you mean by "can". technically they could. practically, Pd64 will *not* load an external that ends with .pd_darwin. see the mailinglist archives and the github issues for a lengthy discussion why it is like this. > > While we're at it, can i386 be 64? really? As in .linux-i386-64.so, > .darwin-i386-64.so and .windows-i386-64.dll? > sure, why not? the "double" floattype has been around for some time. a quick wikipedia check shows that one of the first (C)PU to implement IEEE 754 (the floating point standard that defines "double" floats as we know them) was the Intel 8087, a 16bit processor (and famous co-processor for the 8086) It would be capable of running Pd64 (".cpm-x86_16-64.so"). fmdsafds IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Am 30. Mai 2024 11:17:16 MESZ schrieb Christof Ressi info@christofressi.com:
So, Windows 11, the current version, is only for 64 bit architectures, right? so one cannot install pd 32 bit on it.
No. 64-bit Windows has an emulation layer for 32-bit applications (the WoW subsystem). Just like Apple used to emulate PPC on its 32-bit Intel processors (Rosetta 1) and now emulates amd64 code on Apple Silicon (Rosetta 2). This is done to make the transition to another CPU architecture easier for the user because they can run their old programs.
To add a bit of confusion here, it's actually a bit simpler: the x86_64 (aka amd64) processors are fully compatible with the x86_32 (aka x86; aka i386) CPUs. There's no need to emulate anything, as the 64 bit CPU can execute the machine 32bit machine coffee directly. Similarly, (some) arm64 CPUs can run both 64bit machine code (aarch64) and 32 bit machine code (aarch32) natively. This allows you to install a 32bit operating system on the 64bit computer. This is a special feature of these architectures. OTOH, Apple Rosetta is required to run incompatible machine code on the new CPUs (so it needs to use a slower emulation).
Of course, a program also needs to interface with the operating system. Since you cannot mix 32bit and 64bit machine code (eg you cannot load a windows-i386-32 external into a windows-amd64-32 Pd), your OS needs to provide some runtime layer. This is where the WoW subsystem comes into play.
On OSX this was only useful in the early days of intel (iirc, there were some 32bit models). (The rest is Rosetta)
On Linux (Debian) there's a hybrid "multiarch" approach, that can provide the runtime for *any* architecture. Is the CPU cannot natively run the machine code, you need an emulator (eg qemu).
mfg.sfg.jfd IOhannes
No. 64-bit Windows has an emulation layer for 32-bit applications (the WoW subsystem). Just like Apple used to emulate PPC on its 32-bit Intel processors (Rosetta 1) and now emulates amd64 code on Apple Silicon (Rosetta 2). This is done to make the transition to another CPU architecture easier for the user because they can run their old programs.
To add a bit of confusion here, it's actually a bit simpler: the x86_64 (aka amd64) processors are fully compatible with the x86_32 (aka x86; aka i386) CPUs. There's no need to emulate anything, as the 64 bit CPU can execute the machine 32bit machine coffee directly. Similarly, (some) arm64 CPUs can run both 64bit machine code (aarch64) and 32 bit machine code (aarch32) natively.
Yeah, "emulation" was the wrong term in this context. After all, x86_64 / amd64 has been designed as a 64-bit /extension /to the x86 instruction set.
Christof
-
Alexandre Torres Porres -
Benjamin Wesch -
Christof Ressi -
cyrille henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette -
Peter P. -
Roman Haefeli