On 7/29/2013 4:45 AM, Leandro Motta Barros wrote:
> Well, I kinda have the same feeling when using it. For my ~10kloc
> project, I still haven't felt a real need to use a real build system.
> I just dmd *.d. If any measurable time passes without any error
> message appearing in the console, I know that my compiled successfully
> (and it is the linker that is running now).

That goes back to the interesting effect that every order of magnitude improvement in compile speed has a transformative effect on development procedure.

(For example, if it took overnight to compile, Brad Roberts' autotester would be nigh unusable in its existing form.)

On Monday, 29 July 2013 at 18:34:16 UTC, Walter Bright wrote:
> On 7/29/2013 5:28 AM, John Colvin wrote:
>> Seriously... Walter wouldn't have got his mechanical engineering degree if he
>> didn't know how to calculate a speed properly.
>
> It's a grade school concept :-)
>
> A college freshman physics problem would be calculating the delta V of a rocket fired in space given the fuel weight, rocket empty weight, thrust, etc.

Physics graduate / soon to be PhD student here :) It's sad how few rockets were involved in my degree...

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

On 7/29/2013 12:08 PM, JS wrote:
> Trying to use distance and speed as a measure of performance of a program is
> just ridiculous.

If you google "program execution speed" you'll find it's a commonly used term. "Lines per second" is a common measure of compiler execution speed - google "compiler lines per second" and see.


> (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!!!!!!!!)

Speed is the reciprocal of time, meaning a decrease in time is an increase in speed.

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

On 07/29/2013 12:08 PM, JS wrote:

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

Do you seriously think people who follow this forum need to relearn what a percentage is? :)

> (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!!!!!!!!)

Everyone knows that.

> I know computers have made everyone dumb....

Not me.

Ali

On Monday, 29 July 2013 at 19:38:51 UTC, Walter Bright wrote:
> On 7/29/2013 12:08 PM, JS wrote:
>> Trying to use distance and speed as a measure of performance of a program is
>> just ridiculous.
>
> If you google "program execution speed" you'll find it's a commonly used term. "Lines per second" is a common measure of compiler execution speed - google "compiler lines per second" and see.
>
>
>> (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!!!!!!!!)
>
> Speed is the reciprocal of time, meaning a decrease in time is an increase in speed.

You are right, sorry. There is no difference.

I think the issue is interpretation. When I read "X% increase in speed" I think "X% faster [in time]".

Since you are using speed in a technical way, then it works. I think it is deceptive, in some sense... although not necessarily intentional.

The reason is very few people measure performance of a program in any other way than the time it takes to execute the program. That is all that matters in most cases... and in most cases lines per second mean nothing... but I guess in compilers it is more useful.


What I'm now wondering is why you chose to use % increase in speed rather than % decrease in time? Is it because it is a larger number and looks more impressive?

It think 99.9999% of people using D only care about the absolute time it takes to compile their code, and giving a number that they can actually use directly(instead of having to calculate first) seems more useful.

By knowing you *sped* up the compiler so it is 43% faster lets me know that I should expect compilation time of my code to be approximately cut in half.

When you say 75% increase in speed I have to actually do some calculation and hopefully also interpret speed properly.

Nowhere in the article do you refer to the lines per second or any technical definition of speed.

It's a somewhat informal article but you are using a rather formal definition of speed and it also does not directly give the user an obvious metric as just giving them the percentage change of time.

On Monday, 29 July 2013 at 20:19:34 UTC, John Colvin wrote:
> On Monday, 29 July 2013 at 19:08:28 UTC, JS wrote:
>> Please study up on basic math before building any bridges. I know computers have made everyone dumb....
>
> And again:
>

Honestly, I don't know why you are still trying... At this point, it's not the math that's a problem anymore, it's basic communication.

Back to the main subject: Congrats Walter! Those are some incredible numbers ;)

On Mon, 29 Jul 2013 20:05:08 +0100, John Colvin <john.loughran.colvin@gmail.com> wrote:

> On Monday, 29 July 2013 at 18:34:16 UTC, Walter Bright wrote:
>> On 7/29/2013 5:28 AM, John Colvin wrote:
>>> Seriously... Walter wouldn't have got his mechanical engineering degree if he
>>> didn't know how to calculate a speed properly.
>>
>> It's a grade school concept :-)
>>
>> A college freshman physics problem would be calculating the delta V of a rocket fired in space given the fuel weight, rocket empty weight, thrust, etc.
>
> Physics graduate / soon to be PhD student here :) It's sad how few rockets were involved in my degree...

Time to fix that!
https://kerbalspaceprogram.com/

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

JS, el 29 de July a las 22:32 me escribiste:
> On Monday, 29 July 2013 at 19:38:51 UTC, Walter Bright wrote:
> >On 7/29/2013 12:08 PM, JS wrote:
> >>Trying to use distance and speed as a measure of performance of
> >>a program is
> >>just ridiculous.
> >
> >If you google "program execution speed" you'll find it's a commonly used term. "Lines per second" is a common measure of compiler execution speed - google "compiler lines per second" and see.
> >
> >
> >>(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!!!!!!!!)
> >
> >Speed is the reciprocal of time, meaning a decrease in time is an increase in speed.
> 
> You are right, sorry. There is no difference.
> 
> I think the issue is interpretation. When I read "X% increase in speed" I think "X% faster [in time]".

I just want to point out that being so much people getting this wrong (and even fighting to convince other people that the wrong interpretation is right) might be an indication that the message you wanted to give in that blog is not extremely clear :)

That was my whole point. If you used some easier measure to understand
(like using time instead of speed) you could have avoided all this
confusion :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
A veces quisiera ser un auto,
para chocar como choco siendo humano,
para romperme en mil pedazos.