On Tuesday, 30 July 2013 at 10:08:22 UTC, Leandro Lucarella wrote:
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
>>a program is
>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"
>>(again, if we started with 12 second and went to 21 seconds,
>>would be a near
>>75% increase. But a 75% increase is not a 75%
>Speed is the reciprocal of time, meaning a decrease in time
>increase in speed.
You are right, sorry. There is no difference.
I think the issue is interpretation. When I read "X% increase
speed" I think "X% faster [in time]".
I just want to point out that being so much people getting this
(and even fighting to convince other people that the wrong
interpretation is right) might be an indication that the
wanted to give in that blog is not extremely clear :)
That was my whole point. If you used some easier measure to
(like using time instead of speed) you could have avoided all
It depends on the audience, but to write an article that is
informal then use a very formal definition of speed is just
begging for problems.
It's hard for me to really imagine that lines is a measurement of
distance and speed is lines per second... but even if I allow
this I don't understand why it is a better metric than just time
alone(even though it is equivalent mathematically it is a
If a compiler can compile n lines per second, is that really all
that useful as a direct measurement? Are you saying I have to go
count the lines of code in my program? Do I count empty lines?
commented lines? etc... Why don't you just give me the most
Time is really all that matters, everything else is just