I have not looked at the specifics of what is going on ... Dismissing denormals is particularly dicey when your functional data flow is generating many denormalized values.
Do you what it is causing many values of very small magnitude to occur as you run this? Is the data holding them explicitly? If so, and you have access to preprocess the data, and you are sure that software cannot accumulate or reciprocate or exp etc them, clamp those values to zero and then use the data. Does the code operate as a denormalized value generator? If so, a small alteration to the order of operations may help. On Monday, July 13, 2015 at 9:45:59 AM UTC-4, Jeffrey Sarnoff wrote: > > Cleve Moler's discussion is not quite as "contextually invariant" as are > William Kahan's and James Demmel's. > In fact "the numerical analysis community" has made an overwhelmingly > strong case that, roughly speaking, > one is substantively better situated where denormalized floating point > values will be used whenever they may > arise than being free of those extra cycles at the mercy of an absent > smoothness shoving those values to zero. > And this holds widely for floating point centered applications or > libraries. > > If the world were remade with each sunrise by fixed bitwidth floating > point computations, supporting denormals > is to have made house-calls with few numerical vaccines to everyone who > will be relying on those computations > to inform expectations about non-trivial work with fixed bitwdith floating > point types. It does not wipe out all forms > of numerical untowardness, and some will find the vaccinces more > prophylatic than others; still, the analogy holds. > > We vaccinate many babies against measles even though there are some who > would never have become exposed > to that disease .. and for those who forgot why, not long ago the news was > about a Disney vaction disease nexus > and how far it spread -- then California changed its law to make it more > difficult to opt-out of childhood vaccination. > Having denormals there when the values they cover arise brings benifit > that parallels the good in that law change. > The larger social environment gets better by growing stronger and that > can happen because somethat that had > been bringing weakness (disease or bad consequences from subtile numbery > misadventures) no longer operates. > > There is another way denormals have been shown to be matter -- the way > above ought to help you feel at ease > with deciding not to move your work from Float64 to Float32 for the > purpose of avoiding values that hover around > smaller magnitudes realizable with Float64s. That sounds like a headache, > and you would not have changed > the theory in a way that makes things work (or at all). Recasting the > approch to solving ot transforming at hand > to work with integer values would move the work away from any cost and > benefit that accompany denormals. > Other that that, thank your favorite floating point microarchitect for > giving you greater throughput with denormals > than everyone had a few design cycles ago. > > I would like their presence without measureable cost .. just not enough to > dislike their availability. > > On Monday, July 13, 2015 at 8:02:13 AM UTC-4, Yichao Yu wrote: >> >> > As for doing it in julia, I found @simonbyrne's mxcsr.jl[1]. However, >> > I couldn't get it working without #11604[2]. Inline assembly in >> > llvmcall is working on LLVM 3.6 though[3], in case it's useful for >> > others. >> > >> >> And for future references I find #789, which is not documented >> anywhere AFAICT.... (will probably file a doc issue...) >> It also supports runtime detection of cpu feature so it should be much >> more portable. >> >> [1] https://github.com/JuliaLang/julia/pull/789 >> >> > >> > [1] https://gist.github.com/simonbyrne/9c1e4704be46b66b1485 >> > [2] https://github.com/JuliaLang/julia/pull/11604 >> > [3] >> https://github.com/yuyichao/explore/blob/a47cef8c84ad3f43b18e0fd797dca9debccdd250/julia/array_prop/array_prop.jl#L3 >> >> > >> >
