Article: Increasing the D Compiler Speed by Over 75%

[JS]

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

or

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....