On Monday, 29 July 2013 at 19:08:28 UTC, JS wrote:

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 Brightwrote:On 7/25/2013 11:49 AM, Dmitry S wrote:I am also confused by the numbers. What I see at the end ofthe article is"21.56 seconds, and the latest development version does itin 12.19", which isreally 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.27sSo if it is 43% faster, it means it's reduced the time by9.27s or, 21.56 - 9.27 = 12.28 seconds total.Now, if we started at 12.28 seconds and it jumped to 21.56then 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 = 20sseconds), 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 * tSeriously... Walter wouldn't have got his mechanicalengineering degree if he didn't know how to calculate a speedproperly.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 forreference. 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 ofa program is just ridiculous. The only thing that has anymeaning is the execution time and the way to compare them istaking the ratio of the old to new. Which gives a percentagechange. If the change > 1 then it is an increase, if < 1 thenit is a decrease.Btw, it should be t_new = d_new/s_newand the proper way to calculate a percentage change in timewould bet_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 andt_new/t_old = s_old/s_new orp = t_new/t_old = s_old/s_new is the percentage change of theprogram.Note that speed is the reciprocal of the time side, if youinterpret it wrong for the program(it's not time) then you'llget 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%(or25%). Note how close 50% is to 56% with how close the roundingis. It's no coincidence...It seems some people have to go back to kindergarten and studypercentages!(again, if we started with 12 second and went to 21 seconds, itwould be a near 75% increase. But a 75% increase is not a 75%decrease!!!!!!!!)Please study up on basic math before building any bridges. Iknow computers have made everyone dumb....

And again: "speed" of original = f_old = 1 / 21.56 compilations per second "speed" of new = f_new = 1 / 12.19 compilations per second It's a frequency really, so I'm using f

`change in "speed" = delta_f = f_new - f_old = (1 / 12.19) - (1 /`

`21.56)`

`proportional change in "speed" = deltaf / f_old = (f_new / f_old)`

`- 1`

= ((1 / 12.19) / (1 / 21.56)) - 1 = 0.769 percentage change in "speed" = 100 * 0.769 = 76.9%

`If something does the same work in 25% of the time, it is 1/0.25`

`= 4 times faster, i.e. a 300% increase in speed.`

`After Walter's optimisations, dmd did the same work in 56.5% of`

`the time, which is 1/0.565 = 1.769 times faster, representing a`

`76.9% increase in speed.`

The definition it's all coming from: percentage change = 100*(new - old)/old