Yes, ofcourse, one can agree with all of that.
But...
As for the most convincing opinion:
If, as we agree, there is no definite answer, then how is the beginning BMax-user to choose between the many sugestions given here?
As for optimizing the algorithms:
That is hard in assembler (especialy in these "pipeline"days) and in a basic-language it's extreemly difficult.
How many buscycles does it take to calculate cos (220)?
Indeed that is a matter of circumstance.
In which case benchmarking (I know) a piece of code, you want to optimize "for speed", is not such a bad idea.
And comparing "single instructions" like accessing an array or calculating cos?
If, in a tight loop, on your computer, something is faster then something else, it doesn't matter wether it's because cache, LUT or FPU; at least it proofes that in some cases that instruction is the fastest.
Chances are, that in some more "extended" loop, that instruction will contribute to faster code.
But...
As for the most convincing opinion:
If, as we agree, there is no definite answer, then how is the beginning BMax-user to choose between the many sugestions given here?
As for optimizing the algorithms:
That is hard in assembler (especialy in these "pipeline"days) and in a basic-language it's extreemly difficult.
How many buscycles does it take to calculate cos (220)?
Indeed that is a matter of circumstance.
In which case benchmarking (I know) a piece of code, you want to optimize "for speed", is not such a bad idea.
And comparing "single instructions" like accessing an array or calculating cos?
If, in a tight loop, on your computer, something is faster then something else, it doesn't matter wether it's because cache, LUT or FPU; at least it proofes that in some cases that instruction is the fastest.
Chances are, that in some more "extended" loop, that instruction will contribute to faster code.