Hello list,
I just noticed that pd 0.49 comes packed with 64b. I was interested to ask
what are currently the biggest advantages. I imagine that lots of added
memory capacity; but for example, is it still limited to only one
processor?
I also notice that pd~ is in windows already for a while, I think I'll
test it soon for the next version of my porting of Henke's granulator. I
would like to know: is it guaranteed that parallel processes will run in
different processors, or a bit of a luck game managed by the operating
system?
Best,
Joao
On 24.10.18 21:11, João Pais wrote:
Hello list,
I just noticed that pd 0.49 comes packed with 64b. I was interested to ask what are currently the biggest advantages. I imagine that lots of added memory capacity; but for example, is it still limited to only one processor?
64bit binaries are just this: binaries that can run natively on a 64bit OS. (read: it has nothing to do with the ability to use multiple CPUs, the precision of numbers within Pd, or the bugginess of your patches ;-)).
the only changes the user might notice when running a 64bit binary of Pd:
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
potentially speeding up the execution (regardless of the number of CPUs)
some ASIO drivers which can only be accessed from 64bit applications.
I also notice that pd~ is in windows already for a while, I think I'll test it soon for the next version of my porting of Henke's granulator. I would like to know: is it guaranteed that parallel processes will run in different processors, or a bit of a luck game managed by the operating system?
the actual CPU assignment of a process is managed by the OS. this is actually not a bad thing. since the OS does CPU management anyhow, you might end up ensuring that a process is running on the same CPU as another process that - by mere chance - requested to run on that very CPU... also, if your hardware happens to only have a single CPU, it would be rather annoying if pd~ would insist on running on a CPU#3.
gafmsdf IOhannes
Le 25/10/2018 à 09:46, IOhannes m zmoelnig a écrit :
the only changes the user might notice when running a 64bit binary of Pd:
- Pd can use 64bit pointers to address memory. that means it could use
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
- Pd can use more features (registerse, instructions) of the CPU,
potentially speeding up the execution (regardless of the number of CPUs)
- Pd can use more modern frameworks provided by the OS. iirc, there are
some ASIO drivers which can only be accessed from 64bit applications.
Does that mean we are now in double precision? like in Katja's benchmark: http://www.katjaas.nl/doubleprecision/doubleprecision.html
Are we still limited by 32 bits pointers to address table? (I dont remember the exact value, I think it was 2^24) that would be reaaaaally nice to manage easily big tables (not so big when you use sounds) n
--
On 25.10.18 09:58, Nicolas Montgermont wrote:
Le 25/10/2018 à 09:46, IOhannes m zmoelnig a écrit :
the only changes the user might notice when running a 64bit binary of Pd:
- Pd can use 64bit pointers to address memory. that means it could use
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
- Pd can use more features (registerse, instructions) of the CPU,
potentially speeding up the execution (regardless of the number of CPUs)
- Pd can use more modern frameworks provided by the OS. iirc, there are
some ASIO drivers which can only be accessed from 64bit applications.
Does that mean we are now in double precision? like in Katja's benchmark: http://www.katjaas.nl/doubleprecision/doubleprecision.html
Are we still limited by 32 bits pointers to address table? (I dont remember the exact value, I think it was 2^24) that would be reaaaaally nice to manage easily big tables (not so big when you use sounds)
No, 64bit has nothing to do with double precision. Actually IOhannes wrote exactly that in the mail you reply to (in brackets though).
Quote: "it has nothing to do with [...] the precision of numbers within Pd".
I agree that double-precision would be great to have, it doesn't only affect tables, GPS coordinates would be much easier to handle in Pd too. It looks like Pd is slowly going in this direction actually.
There's a workaround for this - you can put an offset into the right inlet of tabread4~, etc., that allow you to address locally to much better accuracy. For instance, you can give a starting sample as an integer (up to 8 million they're exact) and then address into the neighboring second of sound to a precision of about 1/512 of a sample.
cheers Miller
On Thu, Oct 25, 2018 at 04:15:49PM +0200, Max wrote:
On 25.10.18 09:58, Nicolas Montgermont wrote:
Le 25/10/2018 ?? 09:46, IOhannes m zmoelnig a ??crit??:
the only changes the user might notice when running a 64bit binary of Pd:
- Pd can use 64bit pointers to address memory. that means it could use
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
- Pd can use more features (registerse, instructions) of the CPU,
potentially speeding up the execution (regardless of the number of CPUs)
- Pd can use more modern frameworks provided by the OS. iirc, there are
some ASIO drivers which can only be accessed from 64bit applications.
Does that mean we are now in double precision? like in Katja's benchmark: http://www.katjaas.nl/doubleprecision/doubleprecision.html
Are we still limited by 32 bits pointers to address table? (I dont remember the exact value, I think it was 2^24) that would be reaaaaally nice to manage easily big tables (not so big when you use sounds)
No, 64bit has nothing to do with double precision. Actually IOhannes wrote exactly that in the mail you reply to (in brackets though).
Quote: "it has nothing to do with [...] the precision of numbers within Pd".
I agree that double-precision would be great to have, it doesn't only affect tables, GPS coordinates would be much easier to handle in Pd too. It looks like Pd is slowly going in this direction actually.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em dom, 6 de jan de 2019 às 18:53, Manuel Haible lacuna_@gmx.net escreveu:
Nothing to worry, but little confusing: in 0.49 (and 0.48) the shortcut for the horizintal slider is Shift Control J and not H, as it has been before.
Is this normal ¿
yup! The change was intentional
It was changed to "J" because macOS reserves "cmd-h" for something else.
see: https://lists.puredata.info/pipermail/pd-list/2017-07/119768.html
:)
Mensaje telepatico asistido por maquinas.
On 1/6/2019 5:44 PM, Manuel Haible wrote:
Nothing to worry, but little confusing: in 0.49 (and 0.48) the shortcut for the horizintal slider is Shift Control J and not H, as it has been before.
Is this normal ¿
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 10/25/18 9:46 AM, IOhannes m zmoelnig wrote:
64bit binaries are just this: binaries that can run natively on a 64bit OS.
and to add: this (64bit Pd) is really only something new on Windows. on macOS, we've had this since 2013, on linux since about 2003.
hmfdsa IOhannes
thanks. That's what I thought, but just wanted to be sure. I also notice
that since it's a new thing, there aren't that many externals available
for it yet.
Joao
On 24.10.18 21:11, João Pais wrote:
Hello list,
I just noticed that pd 0.49 comes packed with 64b. I was interested to ask what are currently the biggest advantages. I imagine that lots of added memory capacity; but for example, is it still limited to only one processor?
64bit binaries are just this: binaries that can run natively on a 64bit
OS. (read: it has nothing to do with the ability to use multiple CPUs, the precision of numbers within Pd, or the bugginess of your patches ;-)).the only changes the user might notice when running a 64bit binary of Pd:
- Pd can use 64bit pointers to address memory. that means it could use
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
- Pd can use more features (registerse, instructions) of the CPU,
potentially speeding up the execution (regardless of the number of CPUs)
- Pd can use more modern frameworks provided by the OS. iirc, there are
some ASIO drivers which can only be accessed from 64bit applications.
I also notice that pd~ is in windows already for a while, I think I'll test it soon for the next version of my porting of Henke's granulator. I would like to know: is it guaranteed that parallel processes will run in different processors, or a bit of a luck game managed by the operating system?
the actual CPU assignment of a process is managed by the OS. this is actually not a bad thing. since the OS does CPU management anyhow, you might end up ensuring that a process is running on the same CPU as another process that - by mere chance - requested to run on that very CPU... also, if your hardware happens to only have a single CPU, it would be rather annoying if pd~ would insist on running on a CPU#3.
gafmsdf IOhannes
I also notice that pd~ is in windows already for a while, I think I'll
test it soon for the next version of my porting of Henke's granulator.Interesting project, where can I find more about this?
You can find already from early this year in my library, or since
yesterday evening the new version with new features - see Pd announce.
Joao