Sunday, September 13, 2015

Digest for comp.lang.c++@googlegroups.com - 16 updates in 5 topics

Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 13 09:24PM +0200

Is there some work around to get a constexpr version of trigonometric
math functions like sin, cos?
 
I want to store precalculated twiddle factors for GPU accelerated FFT
calculation in the read only data segment. Basically they are all
constants of the form
static const float twiddles[] =
{ (float)cos(M_2PI*0/256), (float)sin(M_2PI*0/256),
(float)cos(M_2PI*1/256), (float)sin(M_2PI*1/256),
...
(float)cos(M_2PI*127/256), (float)sin(M_2PI*127/256),
};
Of course, this will not work since sin/cos are not constexpr.
 
My current work around is to create the twiddle table with the GPU
assembler (it can handle math functions in compile time constants) and
read it with the CPU just to feed them to the shader code.
 
Is there some native C++11 work around?
 
 
Marcel
mark <mark@invalid.invalid>: Sep 13 10:13PM +0200

On 2015-09-13 21:24, Marcel Mueller wrote:
> Is there some work around to get a constexpr version of trigonometric
> math functions like sin, cos?
 
I don't think there is a 'sane' possibility. But, you if you don't care
about sanity, you can evaluate a taylor series as constexpr:
http://prosepoetrycode.potterpcs.net/2015/07/more-fun-with-constexpr/
 
GGC >= 4.7 has the cmath stuff as constexpr, but it's not even required
by C++14.
"Öö Tiib" <ootiib@hot.ee>: Sep 13 01:17PM -0700

On Sunday, 13 September 2015 22:25:10 UTC+3, Marcel Mueller wrote:
> assembler (it can handle math functions in compile time constants) and
> read it with the CPU just to feed them to the shader code.
 
> Is there some native C++11 work around?
 
No. After we, programmers realized how powerful tool is constexpr
some compiler vendors made some things that weren't constexpr to be
constexpr (like 'std::fmod'). Some other compiler vendors who were
late with implementing constexpr whatsoever (only achieved non-fully
in VS 2015) used their power to forbid that.

Their excuse was usual pathetic nonsense about breaking legacy.
Those functions have side effect of setting 'errno' on case of some
domain errors. So one can make code that "breaks" because 'sin' or
'cos' is constexpr.
 
Long story short ... unless you don't mind to use table lookup
(your cosine and sine tables seem to be 128 entries long) there
are no standard ways. You either have to generate your twiddle
factor table with code generators or to use non-standard compiler
intrinsics that work compile time.
"K. Frank" <kfrank29.c@gmail.com>: Sep 13 02:54PM -0700

Hi Marcel!
 
On Sunday, September 13, 2015 at 3:25:10 PM UTC-4, Marcel Mueller wrote:
> ...
 
> Is there some native C++11 work around?
 
> Marcel
 
Just a side note -- I don't have an answer to your
work-around question.
 
Floating-point constexpr raises issues with
cross-compilation, especially with transcendental
functions.
 
This is because, respecting (legitimate) differences
across hardware, c++ does not require floating-point
computation to be exactly portable.
 
So there is really no way to ensure that, for example,
"constexpr cos (1.23)" is equal to "cos (1.23)" as
evaluated at run time. (Although they should be equal
up to some reasonable round-off error, where "reasonable"
is a quality-of-implementation issue).
 
This isn't really a show-stopper, but it does let one
more potential floating-point "gotcha" creep in that
we would then have to avoid tripping over.
 
 
Happy Floating-Point hacking!
 
 
K. Frank
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 14 12:15AM +0200

On 13.09.15 23.54, K. Frank wrote:
 
> This isn't really a show-stopper, but it does let one
> more potential floating-point "gotcha" creep in that
> we would then have to avoid tripping over.
 
Since I need to crop to 32 bit IEEE float anyway to get GPU support,
this is no big deal. Probably any real life platform should have enough
accuracy in the double calculation to produce reasonable exact values in
single precision, even when cross compiling.
 
> Happy Floating-Point hacking!
 
Well, most of the work is not related to numerics but to cache
efficiency and things like that.
 
 
Marcel
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 14 12:16AM +0200

On 13.09.15 22.13, mark wrote:
> http://prosepoetrycode.potterpcs.net/2015/07/more-fun-with-constexpr/
 
> GGC >= 4.7 has the cmath stuff as constexpr, but it's not even required
> by C++14.
 
Hmm, I must have done something wrong...
gcc 4.8.2
I got "initializer element is not a constant expression".
 
I will check this later.
Since the code is platform dependent anyway I could live with the
restriction to gcc at this place.
 
Oops, I got it. This file is named .c - shame on me (not my code).
 
 
Marcel
woodbrian77@gmail.com: Sep 13 05:46AM -0700

I've been thinking about servers lately. From what I can
tell hardware servers are primarily used to run multiple
instances of a single process. These are "dedicated"
servers. I'm wondering about another context where a
variety of software servers run on a hardware server.
I think my back tier (CMW) is an example of the former
and my middle tier (CMW Ambassador) is an example of the
latter. Is there research or terminology to describe
the latter context -- maybe a "mixed" or "hetereogenous"
server? Tia.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
 
 
 

Brian
Ebenezer Enterprises - A person's a person no matter how small.
http://webEbenezer.net
Ian Collins <ian-news@hotmail.com>: Sep 14 09:51AM +1200

> I've been thinking about servers lately. From what I can
> tell hardware servers are primarily used to run multiple
> instances of a single process.
 
Hardware servers are primarily used to run virtualised servers these days.
 
> latter. Is there research or terminology to describe
> the latter context -- maybe a "mixed" or "hetereogenous"
> server? Tia.
 
There isn't really a distinction. Some applications are flexible enough
to run components over multiple hosts, other are not. So the use case
is application, not server, driven.
 
--
Ian Collins
ram@zedat.fu-berlin.de (Stefan Ram): Sep 13 07:53PM

> ...
> (float)cos(M_2PI*127/256), (float)sin(M_2PI*127/256),
> };
 
One could run this in the make process:
 
#include <iostream>
#include <ostream>
#include <string>
#include <cmath>
#include <cfloat>
#include <iomanip>
 
using namespace ::std::literals;
 
#define M_2PI (atan2(1,1)*8.0)
 
#ifndef FLT_DECIMAL_DIG
#define FLT_DECIMAL_DIG \
( int )( ( double )FLT_MANT_DIG / log( 10. ) * log( 2. )) \
/* correct?? */
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)