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
