Very nice, Simon. That's super cool. Would love to have some of these gems in Base Julia. With good documentation of how they can be used would be a really valuable combination that's actually quite hard to find anywhere. These kinds of tricks and the expertise to use them tend to be scattered all around.
On Fri, Aug 29, 2014 at 5:44 AM, Simon Byrne <[email protected]> wrote: > That was an interesting exchange. > > I agree that there's probably no immediate benefit from translating the > libm into julia, but as an exercise it might have some indirect benefits: > * It could provide a sort of "gold standard" of julia numeric code for > people who are interested in poking around and learning about floating > point numbers. > * It might encourage us to develop some useful idioms for cases where you > need just a few extra bits of precision: this is a common trick used in the > openlibm code, and full double-double arithmetic would be overkill (Jiahao > mentioned he was also interested in this for some matrix operations, so I'm > hoping to look at next week while I'm in Boston). > * We could borrow parts to implement more functions: e.g. a pow1p function > for (1+x)^y > * It might be possible modify the code to take advantage of native fma > instructions, as they start to become more prevalent. I think a prime > candidate here is the pow function, as it does a lot of Horner evaluations > and extra precision arithmetic. > > I have a few bits and pieces that I've translated while playing around. In > case anyone else is interested, I've put them together here: > https://github.com/simonbyrne/libm.jl > > simon > > > On Thursday, 28 August 2014 22:28:57 UTC+1, Stefan Karpinski wrote: > >> Interesting. I'm not sure how bad the function call overhead in >> JavaScript is (or why it would be bad), but for us it's the same as one C >> function calling another C function. The main advantages of reimplementing >> things in pure Julia are: (a) generalization – same algorithm can apply to >> many different types and/or (b) the ability to have the call inlined into >> callers. I'm not sure if sin is the kind of function that benefits much >> from inlining. The fdlibm algorithm is going to be pretty type-specific, so >> generality is unlikely to benefit. >> >> >> On Thu, Aug 28, 2014 at 5:05 PM, Jason Merrill <[email protected]> wrote: >> >>> If you love the details of floating point math, may I humbly recommend >>> reading >>> >>> https://code.google.com/p/v8/issues/detail?id=3006 >>> >>> This isn't so Julia related, per se, but I find it fascinating, and >>> can't think of a better place to find other people who might also. >>> >>> Here's my TLDR: >>> >>> 1. Someone working on v8 wants to get rid of the overhead of calling out >>> to C, so they implement floating point trig functions in pure JS. >>> 2. Because of haphazard range reduction, the new code sometimes gives >>> very different answers than the old glibc code. The worst, in my mind, is >>> sin(-1e-18) now returns 0 instead of -1e-18. This shipped! Try >>> Math.sin(-1e-18) in the version of Chrome you're probably using to read >>> this right now. >>> 3. Someone else complains about this, and is nearly shouted down over >>> claims of "the spec allows it." >>> 4. Complainer implements a prototype straight port of fdlibm trig >>> functions in pure JS, which gives both speed and good answers. >>> 5. Original implementer sees the light, and works to shepherd an >>> implementation of this idea into a pull request. >>> >>> I was on the edge of my seat the whole time! >>> >>> And to try to relate this to Julia... would it be a crazy idea to >>> reimplement some of libm (e.g. trig functions) in Julia, as the v8 team has >>> chosen to do for JS here? Is there a reason that v8 has much higher >>> overhead to call out to C for this than Julia does? >>> >> >>
