-------- CONTEXT: -------- I have completely changed the gegl/buffer/gegl-sampler-yafr.c code. Before I put together the patch to the new yafr, I would like to see if I could make the code even faster by using C99/gcc built-in math intrinsics. I have not tried this yet. The method used by the updated code is different from the first generation yafr (at once softer and more pervasive; yes, this is vague: what I mean is that the nonlinear correction is "on" throughout more of the image, but that its effect is never as extreme). The code also runs even faster than before: on my current vintage laptop, yafr scales up about 10% slower than gegl-sampler-linear, and about 10% faster than gegl-sampler-cubic. Regarding further speed-up (using arithmetic branching): With fabs, fmin and copysign I could make my code branch-free (assuming of course that these operations are translated to assembly built-ins by the compiler on the machine on which the code is compiled). That is: the yafr code, which already does not contain "if," "for," "do" or "while," would now contain no "?." I suspect that using arithmetic branching could make my code run noticeably faster. --------- QUESTION: --------- I noticed that fabs, fmin and copysign, or similar C99/gcc built-ins, are not found anywhere in the gegl source. Is there a preferred/tolerated way of using such math functions in gegl? Can I assume that gfloats are floats? Can I assume that gdoubles are doubles? Must I program with the possibility that gfloats be doubles? Must I program with the possibility that gdoubles be floats? Could gfloats or gdoubles be anything else than floats or doubles? Some ideas: Idea 0: It may be that I can use the type-generic fabs, fmin and copysign on gfloats without a speed hit. Hopefully, gcc can use the correct one based on the fact that it acts on gfloats. If not, it may be that using the double versions on gfloats is still faster than the alternatives. Idea 1: If I KNEW for a fact that gfloat = float, I could simply use fabsf, fminf, and copysignf. Idea 2: I could do the necessary parts of the computation with doubles (or gdoubles) and then use the double versions. Hopefully, this will not slow down gegl when run on hardware which is faster on floats than doubles (like some GPUs). Is there any objection to me using straight doubles inside the code (as long as they are not used to communicate with the rest of gegl)? Idea 3: Is there a smarter way, which picks the right one? Idea 4: Change compilation flags to include C99 built-ins? Idea 5: You have another idea? Idea 6: Or should I just stick to C90 gcc built-ins? Nicolas Robidoux Laurentian University/Universite Laurentienne _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
