On 2017-02-27 23:50, Roman Haefeli wrote:
On Mon, 2017-02-27 at 23:13 +0100, IOhannes m zmölnig wrote:
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Thanks for the explanation. Sounds wasteful in my ears.
wasteful of what?
available bits on your RAM module? sure. code that needs to be maintained? no.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
It takes half of the memory to load the same amount of audio files. Or did I misunderstand?
no you understood correctly. but you missed the point, that with 64bit archs you will be able to address 2^32 times the amount of data you can theoretically address on a 32bit arch. and while current machines do not have *that* much memory, they still have enough memory to give you more net-value out of your tables than 32bit machines.
this of course does not apply if you are dealing with legacy hardware or with embedded devices (including the popular Raspberry Pis), because they often do not have more memory than can be addressed with 32bit.
gfmsdr IOhannes