ARTIQ/RTIO-performance-and-optimizations.md

@@ -11,7 +11,7 @@ This page lists various observations, optimizations, and recommendations regardi
 1. Using `delay_mu(1)` seems to have no effect on the timeline and does not result in serializing events. For minimal delays required for event serialization, use `delay_mu(np.int64(self.core.ref_multiplier))`. We expect this behaviour is caused by the coarse reference clock which by default is a factor 8 slower than the RTIO reference clock.
 1. Sequential calls to `gate_*()` functions (`TTLInOut` and `EdgeCounter`) on the same device need to have minimal delays between them. Without a delay, the gateware is not able to distinguish separate gate periods and fuses them into one larger gate period.
 1. In general, the usage of `parallel` indicates that code is not fully optimized for RTIO performance. The `parallel` statement does not order events _earliest deadline first_ which reduces efficiency. In most cases, rewriting code to prevent usage of the `parallel` statement results in higher RTIO performance.
-1. Floating point arithmetic is relatively slow and usage of machine units is preferred for maximal RTIO performance (see also the `fast-math` flag in the section below). Floating point arithmetic includes conversion of a floating point value to machine units. Preferably, values are converted to machine units once and reused in the remainder of the program.
+1. Floating point arithmetic is relatively slow and usage of machine units is preferred for maximal RTIO performance (see also the `fast-math` flag in the section below). _Floating point arithmetic includes conversion of a floating point value to machine units_. Preferably, values are converted to machine units once and reused in the remainder of the program.
 
 ## Data types