[PD-dev] double precision Pd: .patch files, tests and benchmarks

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-10-01 17:25, Hans-Christoph Steiner wrote:
> 
> Hey Katja,
> 
> This is great, just starting to dig into it.  Its a great write-up too.


congrats from my side as well.

however, i got 2 remarks regarding the write-up:
- - "The situation is similar to Pd for 64 bit Linux, which can not be
mixed with externals for 32 bit Linux." is not really true - at least if
by "the situation" you mean that you have to take care not to
accidentally load a library of the wrong architecture. the dynamic
loader will plainly refuse to load a 32bit external on a 64bit machine
(and vice versa), which resolves a lot of headaches, as you never
experience mysterious crashes because you got the architecture wrong
(which is the only problem with getting double precision into Pd)

- - "there is good reason to build double precision Pd for 64 bit systems
and single precision Pd for 32 bit systems."
i cannot quite follow the argumentation here. of course, in 64bit world,
you can address more memory and thus you might not run out of memory as
soon as on 32bit systems.
i'm a bit concerned about such a proposal in the "symbol collision"
part, as it might seem to be a remedy against the symbol collision
problem, which it simply is not. we have had 64bit single-precision
versions of Pd around for quite some time (just install it in Debian,
Ubuntu,...), so we do already have a compat problem here.
it would be different, if 64bit Pd would not be there, as then we could
just start on fresh grounds.


anyhow, i think double precision Pd is really one of the biggest things
since quite some time.

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6JvQwACgkQkX2Xpv6ydvS8WQCg1m9IjkziO1JS1uU+gIbQjUzV
9fAAnR8JWX1/5f9fHH494phVoqMmtI01
=cY4m
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20111003/4736500e/attachment-0001.bin>