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

[Hans-Christoph Steiner]

On Oct 3, 2011, at 9:12 AM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-10-03 14:28, katja wrote:
>> On Sun, Oct 2, 2011 at 11:36 PM, Hans-Christoph Steiner <hans at at.or.at 
>> > wrote:
>>
>>> I think it makes sense to work off of
>>> pure-data.git rather than pd-extended.git since this is a patch  
>>> targetted at
>>> getting into Miller's repo.
>>
>> Right. Even then, we could add some external libs to work on,  
>> starting
>> with zexy and cyclone for example. The question is how to load
>> appropriate executables into local single and double precision test
>> builds of vanilla Pd. A single preference file is shared by all
>> vanilla Pd installations, therefore setting searchpaths via
>> preferences is no option. Each Pd should only load from it's own
>> 'extra' directory. With the extra's included in vanilla Pd, this  
>> works
>
>
> i'm not sure whether i really understand what you are saying here.
>
> however, as long as a double-precision Pd looks into different paths
> than a single precision Pd, we won't have any problems.
> however, as soon as a double precision enabled Pd will find such an
> external in there, it will go kaboom.
>
> possible solutions to the problem that come to my mind are:
> - - use a different filename suffix for double-precision externals.  
> e.g.
> bonk~.pd_linux and bonk~.double.pd_linux
> pro: you can ship single and double precision files in a single zip  
> file
> con: yet another special suffix
>
> - - use a different setup function name for double precision, e.g.
> bonk_tilde_setup() vs bink_tilde_dsetup()
> pro: allows to have both single and double precision objects in a  
> single
> binary
> con: needs extra code in each external (esp. if you want to exploit  
> the
> 'pro' without resorting to C++-templates...)
> con: code need to be made aware for which width it is compiled
>
> - - use a special exported function in the code, that indicates the  
> width,
> for which the object was compiled [*]
> pro: backward compatible,
> con: needs extra code in each external (could probably done with a  
> macro).
>
>
> [*] something like:
> int pd_floattype_compatcheck(int runtimetype) {
>  return runtimetype && COMPILETIMETYPE);
> }
> COMPILETIMETYPE would be defined in m_pd.h
> during load time, before Pd calls the _setup function, it would check
> for pd_floattype_compatcheck() and call it with
> runtimetype=COMPILETIMETYPE. if the compatcheck returns!=0, then the
> external is considered to be compatible with the currently used
> COMPILETIMETYPE and can thus be safely used.
> if 0 is returned, the external is incompatible and the setup  
> function is
> not called at all (and hopefully the search for a compatible  
> external is
> continued).
> if there is no pd_floattype_compatcheck() exported, then we really  
> don't
> know whether we are compatible.
> i would suggest to assume compatibility, but make Pd issue a warning
> before it tries to load (and run) the object, so people would have a  
> way
> to find out what caused the crash.
> alternatively, one could assume "single precision" if the  
> compatcheck is
> missing, and refuse to load it in double precision mode.

These all sound like good ideas to try.  My only concern is that we  
might let the deployment issues distract from the issues at hand about  
getting it actually working first.

In terms of packaging, I can see having 64-bit distros run double- 
precision Pd for all packages, and 32-bit distros run single  
precision.  That should cover the bulk of situations, the other  
situations can be covered by custom builds.  Having all the 64-bit  
packages use double-precision Pd is of course going to happen after a  
while, once we have the bugs worked out.  Here I can see an advantage  
of the monolithic Pd-extended package: its an easy, self-contained  
test bed.

I think this could also apply to the file extensions.  The 64-bit  
ones, like .l_ia64, would assume double-precision, and 32-bit ones  
like .l_i386 would be single precision.  I'm not yet sure what to do  
about .pd_linux.  On Mac OS X, we'd still only need .pd_darwin since  
the fat binaries handle all the archs.  Then the 64-bit code would be  
double-precision, and the 32-bit single.

.hc


>
>> fine as far as I have seen. I tested bonk~ in single and double
>> precision Pd simultaneously without symbol collision.
>
> which symbols are supposed to collide?
>
> fgmasdr
> IOhannes
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6JtKUACgkQkX2Xpv6ydvTZZgCgu8d045+iv0ju7wvgSTefJBXa
> ZfMAoIh2eVZ2uwgh7e5gkjU+itRw3IlT
> =vbHJ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom