The ArrayFire library offers JIT (Just In Time) compiling for standard arithmetic operations. This includes trigonometric functions,  comparisons, and element-wise operations. At run-time, ArrayFire aggregates these function calls using an Abstract Syntax Tree (AST) data structure such that when ever a JIT supported function is ``met'' it is added into the AST for a given variable instance. The AST of the variable is computed if one of the following conditions is met: 1) an explication evaluation is required by the programmer using the $eval()$ function member or 2) the variable is required for the computation of a different variable that is not-JIT supported it. When the above occurs and the variable needs to be evaluated, the functions and variables in the AST data structure are used to create a single kernel (``function-call''). This is done by a creating a customized kernel on-the-fly that is made up of all the functions in the AST - the customized function is then executed.

This JIT compilation technique has multiple benefits:
<ul>
<li>
A reduced number of kernel calls - a kernel call can be a significant overhead for small data-sets.
</li>
<li>
Better cache performance - there are many instances in which the memory required by a 
single element in the array can be reused multiple or the temporary value of a computation can be stored in the cache and reused by future computations. 
</li>
<li>
Temporary memory allocation and write-back can be reduced - when multiple expressions are evaluated and stored into temporary arrays, these arrays need to be allocated and the results written back to the main memory.
</li>
<li>
Avoid computing elements that are not used - there are cases in which the AST is created for a variable, however the expression is not used later in the computation. Thus, it evaluation can be avoided. 
</li>
<li>
Better performance - all the above in fact can help reduce the total execution time.
</li>
</ul>



<pre>
// As JIT is automatically enabled in ArrayFire, this version of the function forces each expression to be evaluated.
// If the eval() function calls are removed, then the execution of this code would be equivalent to the following function.
static double pi_no_jit(array x, array y, array temp, int samples){
        temp=x*x;
        temp.eval();
        temp+=y*y;
        temp.eval();
        temp=sqrt(temp);
        temp.eval();
        temp=temp<1;
        temp.eval();
        return 4.0 sum<float>(temp)/samples;
}

static double pi_jit(array x, array y, array temp,int samples){
        temp = (sqrt(x*x+y*y)<1); 
        temp.eval();
        return 4.0*sum<float>(temp)/samples;
}
</pre>




Fig. \ref{fig:jitlisting} presents the code for computing the value $\pi$ using a Monte-Carlo simulation where points
are randomly generated within the unit-square.Each point is then tested to see if it is within the unit-circle. The 
ratio of points within the circle and the point in the square approximate the value $\pi$. 
The accuracy of $\pi$ improves as the number of samples are increased. 
There are two implementations in the code listing. One implementation takes advantage of the JIT feature while the 
other implementation does not benefit from the implementation. As the JIT operations are an integral part of the 
ArrayFire framework, the only way for a programmer to side-step the JIT operations is to manually force expressions to be
evaluated as was done in the non-JIT supported implementation.

Fig. \ref{fig:jitperformance} depicts the 
execution time (abscissa) as a function of the number of samples (ordinate) for two implementations in Fig. 
\ref{fig:jitlisting}. When the number of samples is considerably small, the execution time of the non-JIT supported function
is dominated by the launch of multiple kernels. While the JIT supported function only has a single kernel to launch, the
creation of the JIT-code dominates the execution time. Nonetheless, the JIT supported function is $1.4X-2.0X$ than the non-JIT
supported function. In the case of the large number of samples, both the kernel launch overhead and the JIT-code creation, 
are not the limiting factor - the execution time is dominated by the functionality of the kernel. Specifically, the JIT
supported version is $2.0X-2.7X$ faster than the non-JIT support function due to the reduced number of cache-misses.


