Refactor get3DTableValue

[VitorBoss]

Setup is a 60-2 wheel with a 240 trigger angle, paired 4 inj/cycle injector Loops count with current master

992 @500RPM
972 @1000RPM
799 @6000RPM
712 @8000RPM
577 @12000RPM

Loops count after changes

1002 @500RPM
982 @1000RPM
808 @6000RPM
733 @8000RPM
582 @12000RPM

This is between 5 and 90% faster on my tests and is 95% as accurate as float. The biggest speed improvements are when one input value is exactly as an axis, that scenario is between 25 and 90% faster.

If anyone need the code for test those claims just reach me at slack.

[noisymime]

If I'm looking at this correctly, the main intention is to search from the middle of the axis out rather than from one end?

If so, the difference this will make depends on the current RPM/load and the maximum value in each axis. The current lookup code was designed to perform best at high RPM and high load values, trading that for a small amount of performance at lower loads/rpms. This would appear to play out in the results I'm seeing here, which is that this PR is slightly slower at higher RPMs than the existing routine (Where the load/RPM are closer to the final bin in the maps).

Eg. 24/1 trigger. 6500 RPM (Max value in fuel and ignition tables is 7000rpm). Existing code: 941 PR: 935

The difference is not massive either way, but I'm wondering if practically the small difference (Either way) makes it worthwhile changing anything.

[VitorBoss]

@noisymime The lookup start from middle of axis and can find any value in axisSize/4 interactions. The main reason is blind search and precision, current code have a slight error on results. I'm using the table from tests_tables file, those are some of divergent results:

600RPM 78kpa | Number of loops: 1000
  Buffered -> Stadard:5792 84	|FP Math:4852 85.70	|Clean code:4328(33.83%) 85
some buffer-> Stadard:219400 84	|FP Math:241948 85.70	|Clean code:149012(47.24%) 85
unBuffered -> Stadard:176916 84	|FP Math:228044 85.70	|Clean code:158352(11.72%) 85
700RPM 55kpa | Number of loops: 1000
  Buffered -> Stadard:5736 60	|FP Math:4708 61.00	|Clean code:4264(34.52%) 61
some buffer-> Stadard:169584 60	|FP Math:100080 61.00	|Clean code:87956(92.81%) 61
unBuffered -> Stadard:186372 60	|FP Math:120140 61.00	|Clean code:108084(72.43%) 61
700RPM 83kpa | Number of loops: 1000
  Buffered -> Stadard:5756 92	|FP Math:4708 93.00	|Clean code:4268(34.86%) 93
some buffer-> Stadard:181856 92	|FP Math:99204 93.00	|Clean code:88580(105.30%) 93
unBuffered -> Stadard:186324 92	|FP Math:120140 93.00	|Clean code:108084(72.39%) 93
900RPM 51kpa | Number of loops: 1000
  Buffered -> Stadard:5736 60	|FP Math:4708 61.00	|Clean code:4268(34.40%) 61
some buffer-> Stadard:165748 60	|FP Math:101216 61.00	|Clean code:90096(83.97%) 61
unBuffered -> Stadard:184004 60	|FP Math:122252 61.00	|Clean code:108124(70.18%) 61

[adbancroft]

@VitorBoss could this be closed, with pr #735 being merged recently?

[VitorBoss]

I would like to keep it open for now, I will rework this to compare the speed and accuracy, I'm running my 202108 MOD firmware with this, with the loops per second log is easier to compare and spot the differences