On 26/08/10 02:35, Simen kjaeraas wrote:
> Justin Johansson <no@spam.com> wrote:
>>>> FuncAttrPure:
>>>> Na
>>>
>>> So, sodium is pure huh. :)
>>>
>>> - Jonathan M Davis
>>
>> And natrium also? :-)
>
> Natrium and sodium are the same.

Of course!  Just a bit of tautological silliness on my part. :-)

== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> Steven Schveighoffer wrote:
> >> Just goes to show how useful a profiler is.
> >
> > Yes, I'm glad you pushed me to do it.  Looking forward to the fix.
> The two secrets to writing fast code are:
> 1. using a profiler
> 2. looking at the assembler output of the compiler
> In my experience, programmers will go to astonishing lengths to avoid doing
> those two, and will correspondingly expend hundreds of hours "optimizing" and
> getting perplexing results.

  There are also those who are not programmers, and don't know what they are doing
in the first place. A couple years back i was hired as part of a 'rural
our-sourcing' experiment where they took people in the local area who had _some_
technical potential. They would then be hired out cheaper than experienced
programmers. We went through a 14 week course for Java boot camp. Out of 24 I was
the only one who knew anything about programming. Through the course they weren't
told anything about profiling, looking at assembly language, or using a debugger.
They were taught the absolute minimum. I watched several when the program wouldn't
compile or work right they would randomly make changes trying to get the code to work.

  Be afraid. Be very afraid.

"Era Scarecrow" <rtcvb32@yahoo.com> wrote in message news:i54qi9$1d2g$1@digitalmars.com...
> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
>> Steven Schveighoffer wrote:
>> >> Just goes to show how useful a profiler is.
>> >
>> > Yes, I'm glad you pushed me to do it.  Looking forward to the fix.
>> The two secrets to writing fast code are:
>> 1. using a profiler
>> 2. looking at the assembler output of the compiler
>> In my experience, programmers will go to astonishing lengths to avoid
>> doing
>> those two, and will correspondingly expend hundreds of hours "optimizing"
>> and
>> getting perplexing results.
>
>  There are also those who are not programmers, and don't know what they
> are doing
> in the first place. A couple years back i was hired as part of a 'rural
> our-sourcing' experiment where they took people in the local area who had
> _some_
> technical potential. They would then be hired out cheaper than experienced
> programmers. We went through a 14 week course for Java boot camp. Out of
> 24 I was
> the only one who knew anything about programming. Through the course they
> weren't
> told anything about profiling, looking at assembly language, or using a
> debugger.
> They were taught the absolute minimum. I watched several when the program
> wouldn't
> compile or work right they would randomly make changes trying to get the
> code to work.
>
>  Be afraid. Be very afraid.

From what I've seen, you get essentially the same results from most HR depts. The worst applicants always seem to look the best to the HR folks and vice versa.

Era Scarecrow wrote:
> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
>> The two secrets to writing fast code are:
>> 1. using a profiler
>> 2. looking at the assembler output of the compiler
>> In my experience, programmers will go to astonishing lengths to avoid doing
>> those two, and will correspondingly expend hundreds of hours "optimizing" and
>> getting perplexing results.
> 
>   There are also those who are not programmers, and don't know what they are doing
> in the first place.

Sure, but my advice is directed at the people who *do* know what they are doing, but are avoiding using a profiler and looking at the assembly output.

Hello dsimcha,

> FWIW I only learned when I posted a bunch of stuff here about various
> performance issues and you kept asking me to read the disassembly. In
> hindsight it was well worth it, though.
> 

I still thing CS-101 should be in ASM. It would give people a better understanding of what really happens as well weed out the total incompetents.

OTOH I think CS-102 should be in a scheam or one of it's ilk to teach how the theory works independent of the machine. :)

-- 
... <IXOYE><

Steven Schveighoffer wrote:
> On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> With profiling enabled, gprof outputs this as the top hitters:
>>>   Flat profile:
>>>  Each sample counts as 0.01 seconds.
>>>   %   cumulative   self              self     total
>>>  time   seconds   seconds    calls  ms/call  ms/call  name
>>>  77.76      6.68     6.68     2952     2.26     2.26  elf_findstr(Outbuffer*, char const*, char const*)
>>>   2.10      6.86     0.18     4342     0.04     0.04  searchfixlist
>>
>> elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4721

Let me know how this works:

http://www.dsource.org/projects/dmd/changeset/628

On 2010-08-26 08:13, Walter Bright wrote:
> Steven Schveighoffer wrote:
>> On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright
>> <newshound2@digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> With profiling enabled, gprof outputs this as the top hitters:
>>>> Flat profile:
>>>> Each sample counts as 0.01 seconds.
>>>> % cumulative self self total
>>>> time seconds seconds calls ms/call ms/call name
>>>> 77.76 6.68 6.68 2952 2.26 2.26 elf_findstr(Outbuffer*, char const*,
>>>> char const*)
>>>> 2.10 6.86 0.18 4342 0.04 0.04 searchfixlist
>>>
>>> elf_findstr definitely looks like a problem area. I can't look at it
>>> right now, so can you post this to bugzilla please?
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=4721
>
> Let me know how this works:
>
> http://www.dsource.org/projects/dmd/changeset/628

Shouldn't machobj.c get the same optimization?

-- 
/Jacob Carlborg

On Thu, 26 Aug 2010 02:13:34 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> With profiling enabled, gprof outputs this as the top hitters:
>>>>   Flat profile:
>>>>  Each sample counts as 0.01 seconds.
>>>>   %   cumulative   self              self     total
>>>>  time   seconds   seconds    calls  ms/call  ms/call  name
>>>>  77.76      6.68     6.68     2952     2.26     2.26  elf_findstr(Outbuffer*, char const*, char const*)
>>>>   2.10      6.86     0.18     4342     0.04     0.04  searchfixlist
>>>
>>> elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please?
>>  http://d.puremagic.com/issues/show_bug.cgi?id=4721
>
> Let me know how this works:
>
> http://www.dsource.org/projects/dmd/changeset/628

Better, now takes 20 seconds vs over 60.  The new culprit:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 75.79      6.51     6.51     8103     0.80     0.80  TemplateDeclaration::toJsonBuffer(OutBuffer*)
  3.14      6.78     0.27  1668093     0.00     0.00  StructDeclaration::semantic(Scope*)
  2.10      6.96     0.18        1   180.00   180.00  do32bit(FL, evc*, int)
  1.98      7.13     0.17    15445     0.01     0.01  EnumDeclaration::toJsonBuffer(OutBuffer*)
  0.70      7.19     0.06   656268     0.00     0.00  Port::isSignallingNan(long double)
  0.47      7.23     0.04   915560     0.00     0.00  StructDeclaration::toCBuffer(OutBuffer*, HdrGenState*)
  0.47      7.27     0.04                             Dsymbol::searchX(Loc, Scope*, Identifier*)

I haven't looked at toJsonBuffer at all (btw, why are we calling this function if I'm not outputting json?)

-Steve

Steven Schveighoffer:
> I haven't looked at toJsonBuffer at all (btw, why are we calling this function if I'm not outputting json?)

Fit for a new bugzilla entry?

Bye,
bearophile

On Thu, 26 Aug 2010 08:36:44 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> I haven't looked at toJsonBuffer at all (btw, why are we calling this
>> function if I'm not outputting json?)
>
> Fit for a new bugzilla entry?

I'll just put into the same report, and let Walter decide if it's still a bug.  I am less than ignorant when it comes to compiler innards.

-Steve