Question: Impact range of *unchecked-math*?
Here is a problem I encountered when testing out computing packages: neaderthal and fluokitten. Below is some code for demonstration:
(use '[uncomplicate.neanderthal core native]
'[uncomplicate.fluokitten.core :refer [fmap! fmap fold foldmap]]
'[criterium.core])
(def n 100000)
(def nx (dv (range n)))
(def ny (dv (range n)))
(defn p+ ^double [^double x ^double y] (+ x y))
(defn p* ^double [^double x ^double y] (* x y))
(do
(set! *unchecked-math* :warn-on-boxed)
(quick-bench (foldmap p+ 0.0 p* nx ny)))
What I found out is: if setting *unchecked-math* right before the foldmap call, its effect won't penetrate the call. Yet, if it is set as a global variable in project.clj, then foldmap would be much faster. If (set! *unchecked-math* :warn-on-boxed) is in effect, the average run time is about 240us on my computer; if it is not, the average run time is about 5ms. Huge difference.
My question is: why *unchecked-math* cannot penetrate function calls. Is there any place I need to look after?
Posted Jan 3, 2019, 6:11 PM UTC · edited
86
This has nothing to do with neanderhal's native engine. Neanderthal's foldmap implementation is strictly Clojure.
*unchecked-math* immediately before the foldmap probably does not affect the call because after it you're only *calling* foldmap, whose implementation, in which unchecked math is used, has already been compiled.
I agree it has nothing to do with neanderhal nor fluokitten. Now I understand the *unchecked-math* option better.
On the other hand, it would be great to set *unchecked-math* to be true as the default for fluokitten.
Then people who expect unchecked-math to be false in their programs would have to adapt. I think that the current setting, in which it's up to the user to set their preferences in their own projects is the most flexible and least surprising.