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.

Steven Schveighoffer wrote:
> But it's a moot point, since purity *is* mangled into the symbol name.

Yes, that's done because the caller of a function may depend on that function's purity. Changing the name mangling when purity changes will ensure that the caller gets recompiled as well.

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

I think you overestimate the amount of programmers that can read assembler nowadays.  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 think reading assembly language and understanding the gist of how things work at that level is still an important skill for modern programmers.  While writing assembly is notoriously hard (I've never even tried for anything non-trivial), reading it is a heck of a lot easier to pick up.  I went from zero to basically literate in a few evenings.

On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

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

You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)

-Steve

Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:

> On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> 
>> 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...
> 
> You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)

He forgot:

0. use a better algorithm (the big O notation matters, like in this case)

== Quote from retard (re@tard.com.invalid)'s article
> Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:
> > On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> >
> >> 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...
> >
> > You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)
> He forgot:
> 0. use a better algorithm (the big O notation matters, like in this case)

Yeah, but unless you use a profiler, how are you going to find those spots where N isn't as small as you thought it would be?

Wed, 25 Aug 2010 19:08:37 +0000, dsimcha wrote:

> == Quote from retard (re@tard.com.invalid)'s article
>> Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:
>> > On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>> >
>> >> 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...
>> >
>> > You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)
>> He forgot:
>> 0. use a better algorithm (the big O notation matters, like in this
>> case)
> 
> Yeah, but unless you use a profiler, how are you going to find those spots where N isn't as small as you thought it would be?

Test-driven develoment, automatic testing tools, common sense? Sometimes the profiler's output is too fine-grained.

retard:
> 0. use a better algorithm (the big O notation matters, like in this case)

This is a big mistake, because:
- Optimizing before you know what to optimize is premature optimization. The profiler is one of the best tools to find what to optimize.
- Often data structures and algorithms are a trade-off between different needs. So "better" is not absolute, it's problem-specific, and the profiler helps to find such specific problems.

And regarding the problem of searching in a sequence of items, if the sequence is small (probably up to 10 or 20 if the items are integers, the language is a low level one and the associative array is not very efficient), a linear search or a binary search is often faster.

---------------

dsimcha:
>While writing assembly is notoriously hard (I've never even tried for anything non-trivial),

Using well certain Java frameworks is harder :-)

Bye,
bearophile

On Wed, 25 Aug 2010 15:11:17 -0400, retard <re@tard.com.invalid> wrote:

> Wed, 25 Aug 2010 19:08:37 +0000, dsimcha wrote:
>
>> == Quote from retard (re@tard.com.invalid)'s article
>>> Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:
>>> > On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright
>>> > <newshound2@digitalmars.com> wrote:
>>> >
>>> >> 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...
>>> >
>>> > You mean like asking someone who reported low performance of your
>>> > program on the newsgroup to do it for you? :)
>>> He forgot:
>>> 0. use a better algorithm (the big O notation matters, like in this
>>> case)
>>
>> Yeah, but unless you use a profiler, how are you going to find those
>> spots where N isn't as small as you thought it would be?
>
> Test-driven develoment, automatic testing tools, common sense? Sometimes
> the profiler's output is too fine-grained.

On the contrary, this was one of those bugs that you almost need a profiler for.  Consider that after over 10 years of d compilers nobody has found this deficiency until my little library came along.  And even then, it's hard to say there actually *is* a problem, the compiler runs and outputs valid code, and if you use the -v switch it's continuously doing things.  Even when you profile it, you can see that the errant function only consumes small chunks of time, but it adds up to an unacceptable level.

Test-driven development is only useful if you have a certain criteria you expect to achieve.  How do you define how fast the compiler *should* run until you run it?  It's a very complex piece of software where performance is secondary to correctness.

I can understand not having touched code that outputs an object format for 20 years.  I don't regularly go through my code looking for opportunities to increase big-O performance.

I'm just glad it's been found and will be fixed.

-Steve

dsimcha wrote:
> I think you overestimate the amount of programmers that can read assembler
> nowadays.

The thing is, you *don't* need to be able to read assembler in order to make sense of the assembler output! For example, if:

     f();

is in the source code, you don't need to know much assembler to see if it's generating one instruction or a hundred.


> 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 think reading assembly language and understanding
> the gist of how things work at that level is still an important skill for modern
> programmers.  While writing assembly is notoriously hard (I've never even tried
> for anything non-trivial), reading it is a heck of a lot easier to pick up.  I
> went from zero to basically literate in a few evenings.

Right, assembler isn't hard to read after you spend a few moments with it. After all,

	MOV EAX,3

is hardly rocket science!