Hi Damian - See below.
On 5/18/15, 8:37 PM, "Damian McGuckin" <[email protected]> wrote: > >Hi Michael, > >On Mon, 18 May 2015, Michael Ferguson wrote: > >> I do have one question for you about this. The C function frexp breaks >> up a floating point number into a normalized fraction (stored as a >> double) and an exponent. > >Yes. > > frexp(double mantissa, int *exponent) > frexpf(float mantissa, int *exponent) > frexpl(long double mantissa, int *exponent) > >I always try to avoid with a passion such call function overhead. They do >tend to confuse optimizers. That is not currently a big issue for Chapel >because Chapel does not by itself create assembler. However, in the >future >when the language gets to be a full-blown compiler, it will be an issue. >Going back to try and fix the problem in hindsight is always difficult >and >frustrating. I have verified that GCC at least does not inline frexp. I don't understand why it couldn't, but it didn't in my experiments. Neither did clang... I agree that you don't want to pay for a function call for this sort of thing. > >In C++ which has the C concept of bit fields, I can to do something like > > #include <ieee754.h> > > float f = (float) 10.5; // copy 10.5 from memory into a register > union ieee754_float ft = {f}; // copy/write-back to memory here > unsigned int negative = ft.ieee.negative; > unsigned int mantissa = ft.ieee.mantissa; > unsigned int exponent = ft.ieee.exponent; > >No overhead except for a copy/write-back into the memory used by 'ft'. >Note that I think those unions in 'ieee754.h' need an extra integral >field, not that I have any input to the standards committee. I'm having trouble finding documentation for it, but it seems that ieee754.h is a GLIBC header file. Do you know more about it? (is it in some standard or other?). > >> I think it would be straightforward to implement something in the >> runtime that calls these C functions. > >> Alternatively, we could use the implementation similar to what you have >> described as some C functions (that are inline) in the runtime. > >That sounds interesting. How do you create/write C functions that then >get >effectively expanded in-line in the C code which Chapel creates? > >> Either way, I think that the best approach here is to implement it as >> part of the runtime (rather than give Chapel the ability to use C >> unions, e.g.). > >Ultimately, that sounds an extremely sound approach. Not reall my field >of >expertise. > >> You could implement it in C for now. > >OK. However, but how far do you take that argument? Such discussions can >degrade to the point where something like writing the module Norm should >be done in C. That becomes a deal-breaker and defeats the >Chapel-ification >purpose. Or heaven forbid, you use some in-line assembler within Chapel. >But then you then need versions for X86-64, ARM, SPARC, MIPS, ..... Yuk. >Not my scene. Oops, probably time for another discussion over a beer, or >considering it is in-line assembler, something stronger???? Right. In this case, we're talking about operations that generally aren't supported by Chapel's type system (namely casting memory arbitrarily between types, and non-tagged unions). So to do those things, the most convenient way is to implement them in C. I'm happy to implement them in the Chapel runtime - I was just saying that if you needed the functionality quickly, you could do it yourself as a stop-gap approach. > >> I suppose an alternative would be to use the Chapel support for C >> interoperability to memcpy from the real(64) to a uint(64) and then do >> your shifting and extracting. > >Hmmmm. That would kill the ootimizer too. I believe such memcpys would normally get optimized away - but it depends on your compiler. I'm quite sure that LLVM based compilers will remove 8 byte memcpys and turn it all into registers. I think that the main optimization issue here is that the processor might use registers for the floating point number that might not support bit extraction - so the value might end up in memory or in general purpose registers than staying in floating point registers. I'm sure it depends on the compiler and the architecture though. >But following on from that, If >you added a new concept to Chapel (to give Brad a few more grey hairs) >and >had a neutral type (bits) that allows copies in/out at will, i.e. without >casting as in ... > > var lf : real(64); > ..... > ...assign value to lf ... > ..... > var vlf : bits(64) = lf; > .... > var ieeelf : int(64) = vlf; > >or even something like > > var lf : real(64); > ..... > ...assign value to lf ... > ..... > var ieeelf : int(64) = lf:bits(64); > >this might be an option because most optimizers would probably sort out >any irrelevant or redundant operations/transformations. This is an interesting idea, but I think the key question is whether or not there are other use cases besides working with parts of floating point numbers. Cheers, -michael ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
