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

[Giulio Moro]

> double-precision compiled binary performed within a reasonable range of a vanilla binary

This is very much platform-dependent: platforms that do not have native support for 64bit floating point operations would surely suffer.
For instance, the ARM Cortex A8 that powers the Beaglebone Black and the Raspberry Pi 2, have native support for both, but they have much faster performance on float32 (because the NEON SIMD FPU does not support float64, and the other floating point unit they have  (vfpv3 lite) is slow in comparison).

Best,
Giuilo

________________________________________
From: L2Ork-dev <l2ork-dev-bounces at disis.music.vt.edu> on behalf of Jonathan Wilkes <jon.w.wilkes at gmail.com>
Sent: 21 March 2018 18:17
To: l2ork-dev
Subject: Re: [L2Ork-dev] New developer interested in doing a GSOC18 project

On Wed, Mar 21, 2018 at 12:15 PM, Giulio Moro <g.moro at qmul.ac.uk> wrote:
> Just mentioning that, in my opinion, backwards compatibility should be granted.

Prior art suggests that this is doable/maintainable for the core.

For external libraries: some are written in ways that are either
backwards-compatible or
way that can be easily made backwards-compatible. Others certainly aren't.

After the core we can start with the most important (popular) external
libraries and then
see where that leaves us for the rest.

> So any non-backwards compatible changes needed in the rest of the codebase should be protected under an `#ifdef`.

That isn't always the case. For example, katja changed out some core
DSP algorithms that relied
on type-punning with more straightforward implementations. Performance
tests showed that a
double-precision compiled binary performed within a reasonable range
of a vanilla binary. IIRC they also
showed that a singled-precision binary with the new algos performed
better than a vanilla binary.

That kind of approach where possible is preferable to
shipping/maintaining two different algos or
code paths.

-Jonathan

> Best,
> Giulio
_______________________________________________
L2Ork-dev mailing list
L2Ork-dev at disis.music.vt.edu
https://disis.music.vt.edu/listinfo/l2ork-dev