Hi Sean, On 4/14/2015 3:21 PM, Sean Kanaley wrote:
I see you also made the same point about English! But I don't get the units. As far as I see it, the algorithm is doing X effective computation per cycle. A faster algorithm is computing more each cycle,
And that's where we depart. A more efficient algorithm is faster not because it does more work per unit time, but because it does *less* work overall. In essence the faster algorithm takes a straighter path to the solution and doesn't waste time sightseeing.
Saying that it advances more (toward the solution) per unit time is not the same as saying it does more work per unit time.
As somebody said, "it's all semantics". And that's true, but lacking agreement on the semantics you just go in circles ... like this thread :-) .
Using "faster" to mean it finished sooner is independent of the algorithm
Yes. And because we live in the real world of electron mobility and wire length, there are ways to make code faster while doing exactly the same amount of work: by restructuring data to reduce memory access delays (make it more cache friendly) and by reordering instructions to overlap idle time due to memory accesses with real work on independent computations.
However, these cases are ambiguous and highly hardware dependent. You haven't reduced the total work done at all [you might even be doing _more_ total work by changing cache usage], but due to moving your data physically closer to the CPU and/or by overlapping computations with memory accesses, it appears that you've done more work per unit time. The problem is that both techniques are brittle ... move to a different CPU and your "optimization" may well have a "de-" in front of it. These techniques work well on OoO CPUs, but try them on in in-order CPU and you may get no change or even worse performance.
And what do you mean by the motion vector determines which end point is the base?
Sorry, I wrote that quickly. I'm sure that you know what I meant (once I succeed in making that clear). Just bear with me.
The measure I was advocating was "difference percentage" based on the terminology "50% faster". Difference percentage is just the linear relative change (a ratio) multiplied by 100%. A ratio is a fraction and the "base" of a fraction is its denominator. [Different from the "base" of a number. Fraction "base" may be old terminology, but then I am not very young :-P ] Difference is a vector quantity, having both magnitude and direction.
"Faster" vs "slower" is a line and the times for the old and new versions represent points along that continuum. To compare them you must decide which difference you want to compute - that is, in which direction you will be going: new to old, or old to new.
The [verbose] equation for linear relative change is: ( compared - compared_to ) / compared_to.
The difference vector - that is, the direction of the comparison - determines which of the "old" or "new" points should be substituted for "compared_to" and so become the base (denominator) of the resulting fraction.
I slipped in saying "motion", but difference can be thought of as motion along a line.
I hope that clears it up. George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
