On Monday, 29 July 2013 at 12:28:16 UTC, John Colvin wrote:
On Monday, 29 July 2013 at 10:15:31 UTC, JS wrote:
On Thursday, 25 July 2013 at 21:27:47 UTC, Walter Bright wrote:
On 7/25/2013 11:49 AM, Dmitry S wrote:
I am also confused by the numbers. What I see at the end of the article is "21.56 seconds, and the latest development version does it in 12.19", which is
really a 43% improvement. (Which is really great too.)

21.56/12.19 is 1.77, i.e. a >75% improvement in speed.

A reduction in time would be the reciprocal of that.

Actually, it is a 43% speed improvement. 0.43*21.56 = 9.27s

So if it is 43% faster, it means it's reduced the time by 9.27s or, 21.56 - 9.27 = 12.28 seconds total.

Now, if we started at 12.28 seconds and it jumped to 21.56 then it would be 21.56/12.19 = 1.77 ==> 77% longer.

21.56/12.19 != 12.19/21.56.

The order matters.

To make it obvious. Suppose the running time is 20 seconds. You optimize it, it is 100% **faster**(= 1.0*20 = 20s seconds), then it takes 0 seconds(20 - 20).

That is how you fail a physics class.

s = d/t    =>      t = d/s

100% increase in s = 2*s
let s_new = 2*s

t_new = d / s_new

let d = 1 program  (s is measured in programs / unit time_

therefore: t_new = 1 / s_new  =  1 / (2 * s)  =  0.5 * 1/s
                 = 0.5 * t

Seriously... Walter wouldn't have got his mechanical engineering degree if he didn't know how to calculate a speed properly.

I'm sorry but a percentage is not related to distance, speed, or time.

A percentage if a relative quantity that depends on a base for reference. Speed, time, nor distance are relative.

let d = 1 program  (s is measured in programs / unit time_

which is nonsense... programs / unit time?

Trying to use distance and speed as a measure of performance of a program is just ridiculous. The only thing that has any meaning is the execution time and the way to compare them is taking the ratio of the old to new. Which gives a percentage change. If the change > 1 then it is an increase, if < 1 then it is a decrease.

Btw, it should be

t_new = d_new/s_new

and the proper way to calculate a percentage change in time would be

t_new/t_old = d_new/s_new*s_old/d_old = d_new/d_old / (s_new/s_old)

If we assume the distance is constant, say it is the "distance" the program must travel from start to finish, then d_new = d_old and

t_new/t_old = s_old/s_new


p = t_new/t_old = s_old/s_new is the percentage change of the program.

Note that speed is the reciprocal of the time side, if you interpret it wrong for the program(it's not time) then you'll get the wrong answer).

21.56/12.19 = 1.77 ==> 77% (if you dump the 1 for some reason)
12.19/21.56 = 0.56 ==> 56%

but only one is right... Again, it should be obvious:

Starting at 21.56, let's round that to 20s. Ended at 12.19s, let's round that to 10s. 10 seconds is half of 20s, not 75%(or 25%). Note how close 50% is to 56% with how close the rounding is. It's no coincidence...

It seems some people have to go back to kindergarten and study percentages!

(again, if we started with 12 second and went to 21 seconds, it would be a near 75% increase. But a 75% increase is not a 75% decrease!!!!!!!!)

Please study up on basic math before building any bridges. I know computers have made everyone dumb....

Reply via email to