Well put, you two.  Exactly the same point I was trying to make, only to get accused of spouting "baloney".

---bb


On Fri, Aug 2, 2013 at 10:44 AM, Peter Alexander < peter.alexander.au@gmail.com> wrote:

> On Friday, 2 August 2013 at 17:16:30 UTC, Andrei Alexandrescu wrote:
>
>> On 2013-08-02 15:44:13 +0000, Leandro Lucarella said:
>>
>>> I'm not say is right or wrong for people to have this reflex of thinking about multipliers, I'm just saying if you care about transmitting the message as clear as you can, is better to use numbers everybody can intuitively think about.
>>>
>>> And this is in reply to Andrei too. I understand your POV, but if your main goal is communication (instead of education about side topics), I think is better to stick with numbers and language that minimizes confusion and misinterpretations.
>>>
>>> Just a humble opinion of yours truly.
>>>
>>
>>
>> Fair enough. So what would have been a better way to convey the quantitative improvement?
>>
>
> Not to speak on Leandro's behalf, but I think the obvious answer is "Reduced compile times by 43%".
>
> It's much more useful to express it that way because it's easier to apply. Say I have a program that takes 100 seconds to compile. Knowing that the compilation time is reduced by 43% makes it easy to see that my program will now take 57 seconds. Knowing that compilation is 75% faster doesn't help much at all - I have to get out a calculator and divide by 1.75.
>
> It's always better to use a measure that is linear with what you care about. Here, most people care about how long their programs take to compile, not how many programs they can compile per second.
>

I am OK with the existing definition of speed, but would like to see the definition mentioned somewhere at the top. speed = lines_compiled/sec. Even though its obvious to some people, it not to me!

I guess that's why all the technical docs I write have a explicit "definitions" section at the top in the template. I should start using it more often.

Andrei Alexandrescu, el  2 de August a las 10:16 me escribiste:
> On 2013-08-02 15:44:13 +0000, Leandro Lucarella said:
> >I'm not say is right or wrong for people to have this reflex of thinking about multipliers, I'm just saying if you care about transmitting the message as clear as you can, is better to use numbers everybody can intuitively think about.
> >
> >And this is in reply to Andrei too. I understand your POV, but if your main goal is communication (instead of education about side topics), I think is better to stick with numbers and language that minimizes confusion and misinterpretations.
> >
> >Just a humble opinion of yours truly.
> 
> 
> Fair enough. So what would have been a better way to convey the quantitative improvement?

Reduced execution time by half?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Mi infancia fue en un loft, bien al costado del río
Cazabamos correcaminos y lo azabamos en el fogón
Después? Después me vine grande y la ciudad me deslumbró
Jugando al tejo en Lavalle me hice amigo del bongó

On 8/2/2013 1:45 PM, user wrote:
> I am OK with the existing definition of speed, but would like to see the
> definition mentioned somewhere at the top. speed = lines_compiled/sec. Even
> though its obvious to some people, it not to me!

Sigh. It's not even lines per second, it's dimensionless when using percentages. Note that I never needed to count the number of lines to get a correct percentage.


> I guess that's why all the technical docs I write have a explicit "definitions"
> section at the top in the template. I should start using it more often.

I wouldn't even read an article that had a sidebar at the top explaining what "speed" was.

02-Aug-2013 20:47, Walter Bright пишет:
> On 8/2/2013 6:16 AM, Dmitry Olshansky wrote:
>> I failed to see much of any improvement on Win32 though, allocations are
>> dominating the picture.
>>
>> And sharing the joy of having a nice sampling profiler, here is what AMD
>> CodeAnalyst have to say (top X functions by CPU clocks not halted).

[snip]

>>
>> This underlies the point that DMC RTL allocator is the biggest speed
>> detractor.
>> It is "followed" by ledata (could it be due to linear search inside?) and
>> surprisingly the tiny Obj::fltused is draining lots of cycles (is it
>> called that
>> often?).
>
> It's not fltused() that is taking up time, it is the static function
> following it. The sampling profiler you're using is unaware of
> non-global function names.
>

Thanks, that must be it! And popping that function above another one gets Obj::far16thunk to be blamed :) Need to watch out for this sort of problem next time. Could it be due to how it works with old CV debug info format?

-- 
Dmitry Olshansky

On 8/2/2013 3:53 PM, Dmitry Olshansky wrote:
> Thanks, that must be it! And popping that function above another one gets
> Obj::far16thunk to be blamed :) Need to watch out for this sort of problem next
> time. Could it be due to how it works with old CV debug info format?

Try compiling with -g.

Otherwise, you only get global symbols.

03-Aug-2013 03:32, Walter Bright пишет:
> On 8/2/2013 3:53 PM, Dmitry Olshansky wrote:
>> Thanks, that must be it! And popping that function above another one gets
>> Obj::far16thunk to be blamed :) Need to watch out for this sort of
>> problem next
>> time. Could it be due to how it works with old CV debug info format?
>
> Try compiling with -g.
>

Actually I do, as I had no symbols w/o it.

This is what I changed in win32.mak:

reldmd:
	$(DMDMAKE) "OPT=-o" "DEBUG=-g" "LFLAGS=-L/ma/co" $(TARGETEXE)

From this:

reldmd:
	$(DMDMAKE) "OPT=-o" "DEBUG=" "LFLAGS=-L/delexe" $(TARGETEXE)

I've no clue what /ma/co does here, but I guess ma is short of "map" and co - "codeview"?

-- 
Dmitry Olshansky

On 8/3/2013 7:06 AM, Dmitry Olshansky wrote:
> 03-Aug-2013 03:32, Walter Bright пишет:
>> On 8/2/2013 3:53 PM, Dmitry Olshansky wrote:
>>> Thanks, that must be it! And popping that function above another one gets
>>> Obj::far16thunk to be blamed :) Need to watch out for this sort of
>>> problem next
>>> time. Could it be due to how it works with old CV debug info format?
>>
>> Try compiling with -g.
>>
>
> Actually I do, as I had no symbols w/o it.
>
> This is what I changed in win32.mak:
>
> reldmd:
>      $(DMDMAKE) "OPT=-o" "DEBUG=-g" "LFLAGS=-L/ma/co" $(TARGETEXE)
>
>  From this:
>
> reldmd:
>      $(DMDMAKE) "OPT=-o" "DEBUG=" "LFLAGS=-L/delexe" $(TARGETEXE)
>
> I've no clue what /ma/co does here, but I guess ma is short of "map" and co -
> "codeview"?

/map

    http://www.digitalmars.com/ctg/ctgLinkSwitches.html#map

/co

    http://www.digitalmars.com/ctg/ctgLinkSwitches.html#codeview

/delexe

    http://www.digitalmars.com/ctg/ctgLinkSwitches.html#delexecutable

On 02/08/2013 14:16, Dmitry Olshansky wrote:

> Function     CPU clocks     DC accesses     DC misses
> RTLHeap::Alloc     51638     552     3538
> Obj::ledata     9936     1346     3290
> Obj::fltused     7392     2948     6
> cgcs_term     3892     1292     638
> TemplateInstance::semantic     3724     2346     20
> Obj::byte     3280     548     676
> vsprintf     3056     3006     4


Random lunchtime observation:

A lot of the calls to vsprintf are from TypeStruct::toDecoBuffer/TypeClass::toDecoBuffer/TypeEnum::toDecoBuffer

which all do

           OutBuffer->printf("%s", name);

Is that needed, or would changing them to

           OutBuffer->writestring(name);

be more efficient?
(it seems like it might, albeit only very slightly).

On 8/5/2013 6:21 AM, Richard Webb wrote:
> Is that needed, or would changing them to
>
>             OutBuffer->writestring(name);
>
> be more efficient?

Yes.