I/O vs CPU bottlenecks

[yakra]

Writing near-miss point merged wpt files may be the purest example of a disk I/O bottleneck. It's pretty lightweight, consisting mainly of output streams, some sprintf and a couple ifs.

On lab2, it takes all of 0.8s. Reading waypoints for all routes OTOH processes about the same amount of data, and takes 10.8s. And disk read benchmarks on lab2 are way faster than disk write benchmarks.

This all suggests that when Reading waypoints for all routes, the bottleneck is CPU and/or memory based. Running just 4 threads on BiggaTomato, CPU use hovers @~65%. If we know disk I/O isn't our bottleneck, this suggests that mutexes are to blame.

Disk I/O

Building lab3 can help test out disk I/O bottleneck effects. RAID, xor solid state. Hypotheses:

• A speedup for nmp_merged, though it's already pretty fast.
• Not much speed diff Reading waypoints for all routes.

Reading waypoints for all routes

Mutexes:

• awf_mtx is unavoidable, but not a big deal. This quick hash table lookup is used once per route, not per point.
• strtok_mtx can be eliminated, but the jury's out on whether there will be a noticeable benefit.
• all_waypoints->mtx has good potential for improvement.
  • NMP detection can be moved to another part of the program.
  • If that's not enough, we can investigate locking individual quadtree nodes, rather than the structure as a whole.

[yakra]

strtok_mtx: For processing individual .wpt lines, we're only interested in the space character as a delimiter. strchr should be slightly more efficient than strcspn.

strcspn: check for \n before \r

[yakra]

strchr is the tiniest little bit less efficient than strcspn -- because it returns a null pointer if nothing is found, rather than the string length, I have to check whether the pointer is valid before dereferencing it to look for spaces. This is just enough to be a deal-breaker.

Let's try this out for size:

inline size_t strchrspn(const char *str, char chr)
{   size_t c = 0;
    while (str[c] != chr && str[c]) c++;
    return c;
}

[yakra]

testing / benchmarking: HighwayData @ 27a625459516a8f5c53f73a24ce51416ab991677 UserData @ 3ec63996d33e499027a3d4c8f47abc0d3ce7659f