Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 09:51 +0800, Paul Wise wrote:
> Hmm, compile-time choice of CPU instructions doesn't sound like a 
> good idea, because if I build on an old crappy build machine or a 
> base-level  qemu virtual machine then I won't be getting SSE4 when I 
> run on my fast powerful desktop machine. Please ask upstream to 
> switch to runtime choice based on the available instructions on the
> user's CPU.

Upstream has been pretty much MIA for a long time. But even if I
managed to track him down, I reckon I know what he would say: Portable
floating point calculations can come at the expense of performance and
in order to mitigate this as much as possible, hardware level
optimizations are necessary and heavily tied to the method of
implementation.

The user can still select the best library during configure time. e.g.
with autoconf like so...

# Select correct library based on host hardware...
case "$host_cpu" in

# For Intel based hardware, use SSE2 hardware accelerated variant...
i?86) ;&
x86_64) 
PKG_CHECK_MODULES(
[streflop], [streflop-sse >= 0.3], [],
[AC_MSG_ERROR([streflop-sse >= 0.3 missing...])])
;;

# Otherwise fallback to software emulated variant...
*)
PKG_CHECK_MODULES(
[streflop], [streflop-soft >= 0.3], [],
[AC_MSG_ERROR([streflop-soft >= 0.3 missing...])])
;;
esac

> Please talk to upstream about the test suite stuff too.

Believe me, I've tried. He's MIA. The test suite I've "rigged up" in
one of my quilt patches might be sufficient, but we'll never know for
certain until he checks.

> The upstream website says that it uses the SoftFloat library for the
> software floating-point implementation. Since this is a modified
> embedded code copy too, please document this in the security team's
> embedded code copies file and talk to the upstreams about it. 
> Likewise for the old libc code and for Random.cpp.

Yup. And ideally the package would depend on SoftFloat, but I'm really
not sure how much of the latter he's modified or dependent on in the
way it was back when he wrote streflop.

> Great work convincing them!

Yeah. I think it will end up saving them time in not having to maintain
their own embedded copy and be responsible for it.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



signature.asc
Description: This is a digitally signed message part

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Paul Wise]

On Sun, 2016-04-17 at 17:18 -0700, Kip Warner wrote:

> Nice to hear from you again.

Likewise! I hope Avaneya is going well :)

> https://springrts.com/mantis/view.php?id=5058

Cool. Some thoughts:

Hmm, compile-time choice of CPU instructions doesn't sound like a good
idea, because if I build on an old crappy build machine or a base-level 
qemu virtual machine then I won't be getting SSE4 when I run on my fast
powerful desktop machine. Please ask upstream to switch to runtime
choice based on the available instructions on the user's CPU.

Please talk to upstream about the test suite stuff too.

The upstream website says that it uses the SoftFloat library for the
software floating-point implementation. Since this is a modified
embedded code copy too, please document this in the security team's
embedded code copies file and talk to the upstreams about it. Likewise
for the old libc code and for Random.cpp.

> After some discussion upstream (Spring RTS), they were at first
> reluctant to rely on an external package (or even pkg-config at build
> time for that matter!), but eventually they came around. 

Great work convincing them!

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 08:05 +0800, Paul Wise wrote:
> There are some embedded code copies of this already in Debian, it
> would be great if you could get them to use the package you are
> preparing instead of the code copies in the packages. Please also
> ensure the security team knows about these embedded code copies.
> 
> https://codesearch.debian.net/search?perpkg=1=streflop
> https://wiki.debian.org/EmbeddedCodeCopies

Hey Paul,

Nice to hear from you again. MegaGlest I will liaise with, but Spring
RTS is already aware of my effort to Debianize streflop:

https://springrts.com/mantis/view.php?id=5058

This is partially why I had prepared a PPA, for situations like that
(or at least for those developers using Ubuntu):

https://launchpad.net/~kip/+archive/ubuntu/streflop

After some discussion upstream (Spring RTS), they were at first
reluctant to rely on an external package (or even pkg-config at build
time for that matter!), but eventually they came around. Nevertheless,
I still haven't heard back from them on their efforts to test the
package.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



signature.asc
Description: This is a digitally signed message part

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Paul Wise]

On Sat, Apr 9, 2016 at 8:44 AM, Kip Warner wrote:

> * Package name: streflop

There are some embedded code copies of this already in Debian, it
would be great if you could get them to use the package you are
preparing instead of the code copies in the packages. Please also
ensure the security team knows about these embedded code copies.

https://codesearch.debian.net/search?perpkg=1=streflop
https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

Package: wnpp
Severity: wishlist
Owner: Kip Warner 

* Package name: streflop
  Version : 0.3
  Upstream Author : Nicolas Brodu 
* URL : http://nicolas.brodu.net/en/programmation/streflop/
* License : LGPL-2.1
  Programming Lang: C++
  Description : ITP: streflop -- STandalone REproducible FLOating-Point
library

A computer has a finite memory, and cannot represent an infinity of numbers. If
you add 0.1 + 0.1 in C++ you will probably not get the mathematical result 0.2.
The problem is that what you get depends on many parameters. On one
configuration, you may get something like 0.1995, and on another 0.1999. For
the vast majority of programs, these small differences do not matter. But if
you want to reproduce the same results twice, for a scientific experiment for
example, on different machines or even on the same machine but with different
options, then you have to be more careful. Much more careful, because these
small differences can occasionally accumulate quite fast.

The STandalone REproducible FLOating-Point library allows you to control how
the computations are done in C++. The goal is to make your programs give
reliable and reproducible results.