Article: Increasing the D Compiler Speed by Over 75%

[John Colvin]

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

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