[L2Ork-dev] New developer interested in doing a GSOC18 project

[Jonathan Wilkes]

Hi Pranay,

I'll respond point by point for clarity below.

On Fri, Mar 23, 2018 at 1:33 PM, pranay gupta
<pranayguptastudent at gmail.com> wrote:
> Hello Jonathan,
>
> I have gone through all the mails and tried to go through some files also,
> what I understood was that, wherever algorithms have been implemented using
> single precision I have to change that to double precision and some external
> libraries that are being called in the core functions might also need
> changes.

There are basically two categories of work: the core and the external
libraries (essentially plugins) which ship with Purr Data.

For the core there is prior art with the Pd Double project which can
be found here:

https://github.com/pd-projects/pd-double

One of the challenges here is that our core code has diverged substantially
from that codebase. However, the overall structure of the code is still very
similar as are the core DSP algorithms and message dispatching/parsing
code.

The second category-- external libraries-- is a bit more
difficult because the quality varies considerably for each library.
Some of them are straightfoward and just require recompiling
and testing. Some freely mix "t_float" and "float", probably under
the assumption that the "t_float" type would never change. Still
others may use type-punning or other tricks that depend on
"t_float" being equal to "float".

I think a workable approach here is to prioritize a handful of these
libraries to make ready for double precision and then document
common types of problems for the rest. That is to say I don't think
this project idea needs to aim to make every single library ready
for double precision.

> Also, support for backward compatibility, and an option to the
> users whether to run purr date using single precision or double precision
> should be added.

I don't think this is possible. The public API essentially
requires external library developers to typecast raw pointers to
arrays of t_float. So either everything is compiled with a
uniform t_float value, or you get either:

a) data corruption (double-precision mode with single-instance library loaded)
b) data corruption and buffer overflow (single-precision mode with
double-precision lib)

I'm actually just guessing on the type of errors-- there may be
some part of the API I'm forgetting which causes crashes in both cases.

> And in case any of the single precision or double precision
> catches an error, the one that works has to be used.

As above, I don't think that's possible. But we can test both
precision types in the CI (perhaps switching out one of the older
Ubuntu runners for a single precision build runner).

> Also, you mentioned
> about single precision binaries performing better with better algorithms as
> compared to double precision with a basic implementation when compared to
> vanilla binaries as per the results of some tests.

I didn't measure any difference on my Rockchip Chromebook.
But I'd say it would be a good idea to set up some performance
tests to measure the differences.

>
> I had a few doubts regarding the project,
>
> 1) What should be the main points that I should focus more on in my
> proposal?

Probably on making it possible to compile Purr Data for both types
of precision, to make sure the core runs reliably in each case, and
to make sure some of the more popular external libraries run reliably
in each and document a process for testing/working on the rest.

>
> 2) Also will any of the algorithms that are already implemented require any
> implementation changes when adding support for double precision?

In the core-- yes. These were replaced and tested with new implementations
in the pd double project. I *think* they are the files assigned to the
TYPE_PUNNING_SRC variable in purr-data/pd/src/makefile.in.

>
> 3) And it would be really helpful if you could provide me a few resources
> that might make it easier for me to understand the project better?

General resources or specific to this project idea?

For the former-- here's a great resource Albert created:

https://agraef.github.io/purr-data-intro/

Let us know if you have any more questions.

-Jonathan