Re: A case where conventional wisdom may not apply
Bart van Ingen Schenau
> Conventional wisdom says to get the code working and then profile it and
> then make those parts that are too slow faster.
>
My understanding is that this wisdom mostly applies to micro-
optimizations.
When writing software, one of my targets, besides correctness,
readability and maintainability, is to reach a good efficiency, where
efficiency is a trade-off between execution speed, memory usage,
development costs (mostly -time) and implementation constraints
(preferred language, platform limitations, etc.).
At design time, you select the most efficient algorithm.
At coding time, you write the most efficient implementation of the
algorithm.
And only when it is still not fast enough, you break out the profiler
and see what further optimizations are needed. Hopefully only micro-
optimizations, or you made a wrong trade-off in the earlier stages.
And it is only for micro-optimizations that goals like maintainability
may become less important.
regards,
Bart v Ingen Schenau
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Peter Olcott
> In article<hvmiqb$vud$1...@news.eternal-september.org>,
> Walter Bright<wal...@digitalmars-nospamm.com> wrote:
>> Peter Olcott wrote:
>>> So would you say that it is helpful to make it as fast as possible at
>>> design time, instead of just getting it working, and then later making
>>> it fast? (It also sounds like you might follow this with repeated
>>> iterations of speed improvement re-factorings).
>>
>> If you have the experience to know how to design something for speed, sure, do
>> it. Designing for speed isn't inherently bad, the problem comes inexperience
>> with the problem domain leading to a poor choice of tradeoffs.
>>
>> I suppose it's like designing an airplane. If you want the airplane to go fast,
>> you've got to make those decisions favoring speed at every step of the design.
>> But you'll still need an experienced aero engineer to get those tradeoffs right.
>> Trying to retrofit speed in later isn't going to end well.
>
> Yes and no. I teach (and generally use) a structured approach to
> design, and it is imperative to design for speed only at the higher
> levels - the lower ones can be fixed up later. For example, from
> the top down:
>
> Precise formulation of problem, constraints and objectives.
> Well, obviously, if you don't include it here, you will have to
> start from scratch.
>
> Generic design of data structures, control flow and potential
> algorithms. This is the level at which it is critical, and often
> forgotten, because adding it later means a redesign.
>
> Specific design of the same. If you don't include it here, you
> will have to rewrite, but that's not a major problem in general, as
> it's just replacing one code/data unit by another, very similar, one
> and fixing up loose ends.
>
> Actual coding and optimisation. Including it initially is a
> Bad Idea, because it often interferes with making the code clean,
> easy to debug, maintainable and robust.
>
> Old fogies like me do quite a lot of the last semi-automatically,
> because back in the 1960s and 1970s we had no option. Quite a lot
> of people had to rewrite simply to get their code small and fast
> enough to run their initial tests! But that was then, and it is
> almost never an issue nowadays.
>
>
> Regards,
> Nick Maclaren.
>
This is a good detailed breakdown of exactly what I mean by aiming for
the ballpark of the fastest possible code. Design for speed at every
step of design. When you implement the design as code don't bother to
optimize focus on writing clean code. The implemented design is the one
step where further optimization does not require redesign.
Peter Olcott
> Peter Olcott wrote:
>> So would you say that it is helpful to make it as fast as possible at
>> design time, instead of just getting it working, and then later making
>> it fast? (It also sounds like you might follow this with repeated
>> iterations of speed improvement re-factorings).
>
> If you have the experience to know how to design something for speed,
> sure, do
> it. Designing for speed isn't inherently bad, the problem comes
> inexperience
> with the problem domain leading to a poor choice of tradeoffs.
>
> I suppose it's like designing an airplane. If you want the airplane to
> go fast,
> you've got to make those decisions favoring speed at every step of the
> design.
> But you'll still need an experienced aero engineer to get those
> tradeoffs right.
> Trying to retrofit speed in later isn't going to end well.
>
That was exactly the point that I was trying to make with this thread.
Designing speed in from the beginning is much cheaper than just getting
it working, and then later making it faster, if very fast code is
initially known to be a primary design goal.
{ please do not quote signatures - redacted. -mod }
Keith H Duggar
> On 6/21/2010 1:14 AM, Walter Bright wrote:
> > Peter Olcott wrote:
> >> So would you say that it is helpful to make it as fast as possible at
> >> design time, instead of just getting it working, and then later making
> >> it fast? (It also sounds like you might follow this with repeated
> >> iterations of speed improvement re-factorings).
>
> > If you have the experience to know how to design something for speed,
> > sure, do
> > it. Designing for speed isn't inherently bad, the problem comes
> > inexperience
> > with the problem domain leading to a poor choice of tradeoffs.
>
> > I suppose it's like designing an airplane. If you want the airplane to
> > go fast,
> > you've got to make those decisions favoring speed at every step of the
> > design.
> > But you'll still need an experienced aero engineer to get those
> > tradeoffs right.
> > Trying to retrofit speed in later isn't going to end well.
>
> That was exactly the point that I was trying to make with this thread.
> Designing speed in from the beginning is much cheaper than just getting
> it working, and then later making it faster, if very fast code is
> initially known to be a primary design goal.
Umm ... except that your thread title and various statements
tried to create a (false) distinction between "conventional
wisdom" and "this way" that does not exist. What Walter above
describes is conventional wisdom at least among those who are
educated (or have otherwise learned) proper /engineering/
(software and otherwise).
What you described as "conventional wisdom" is more aptly
termed "naive wisdom" ie an oxymoron. That we are working in
an industry where it has somehow become acceptable for those
without proper education and training to produce our product
(software) is another matter entirely; and it shows.
KHD
Peter Olcott
> On Jun 17, 8:54 pm, Peter Olcott<NoS...@OCR4Screen.com> wrote:
>> Conventional wisdom says to get the code working and then profile it and
>> then make those parts that are too slow faster.
>>
> My understanding is that this wisdom mostly applies to micro-
> optimizations.
>
> When writing software, one of my targets, besides correctness,
> readability and maintainability, is to reach a good efficiency, where
> efficiency is a trade-off between execution speed, memory usage,
> development costs (mostly -time) and implementation constraints
> (preferred language, platform limitations, etc.).
>
> At design time, you select the most efficient algorithm.
> At coding time, you write the most efficient implementation of the
> algorithm.
> And only when it is still not fast enough, you break out the profiler
> and see what further optimizations are needed. Hopefully only micro-
> optimizations, or you made a wrong trade-off in the earlier stages.
> And it is only for micro-optimizations that goals like maintainability
> may become less important.
>
> regards,
> Bart v Ingen Schenau
>
>
I had one employer recently where this degree of code quality was far
too expensive. All of the code was to be used internally by this one
small company and it was to be executed in batch mode.
I am thinking that a focus on speed may be most appropriate when speed
directly impacts response time, and the user is idle while waiting for
the response. This is increasingly more important depending on the
number of users, the duration of the response time, and the cost of the
user's time.
Millions of software engineers waiting several minutes for a compiler to
finish (10-100 times a day) would seem to provide a good example of a
great need for very fast execution.
Peter Olcott
necessary to establish the context. -mod }
What I cited as conventional wisdom has been cited to me countless times
as conventional wisdom by various respondents on other similar forums.
Essentially just get it working without considering speed at all, and
then later make it faster as needed. This does sound pretty naive.
However as Pete Becker so aptly pointed out it is very often the case
that the above degree of focus on performance is far too costly. I had
one employer that required batch programs for internal use where any
time spent on performance was time wasted.
nm...@cam.ac.uk
Peter Olcott <peteo...@gmail.com> wrote:
>On 6/21/2010 8:07 AM, Bart van Ingen Schenau wrote:
>>
>>> Conventional wisdom says to get the code working and then profile it and
>>> then make those parts that are too slow faster.
>>>
>> My understanding is that this wisdom mostly applies to micro-
>> optimizations.
>>
>> When writing software, one of my targets, besides correctness,
>> readability and maintainability, is to reach a good efficiency, where
>> efficiency is a trade-off between execution speed, memory usage,
>> development costs (mostly -time) and implementation constraints
>> (preferred language, platform limitations, etc.).
>>
>> At design time, you select the most efficient algorithm.
>> At coding time, you write the most efficient implementation of the
>> algorithm.
>> And only when it is still not fast enough, you break out the profiler
>> and see what further optimizations are needed. Hopefully only micro-
>> optimizations, or you made a wrong trade-off in the earlier stages.
>> And it is only for micro-optimizations that goals like maintainability
>> may become less important.
>
>too expensive. All of the code was to be used internally by this one
>small company and it was to be executed in batch mode.
Er, no. As I teach, increasing quality (mainly including consistency
checking) often doubles the time to get the demonstration working,
and halves the time until you can actually use the results - and that
is for researchers running their own code. One extreme example was
IBM CICS, when it was redesigned using Z - they didn't even start
coding until a long way through the schedule, and finished ahead
of schedule with many fewer bugs than budgetted for! Impressive.
I agree with you about mere performance - that is far less often an
issue than is made out. Nowadays.
>I am thinking that a focus on speed may be most appropriate when speed
>directly impacts response time, and the user is idle while waiting for
>the response. This is increasingly more important depending on the
>number of users, the duration of the response time, and the cost of the
>user's time.
>
>Millions of software engineers waiting several minutes for a compiler to
>finish (10-100 times a day) would seem to provide a good example of a
>great need for very fast execution.
Definitely NOT. If they spend more than a few percent of their time
compiling, someone has got it badly wrong. Again, that was not so
40 years back, but please let's move on!
I will agree that a lot of the time the people who have got it badly
wrong are the language and library designers and implementors. With
both C++ and (modern) Fortran, recompiling a very small amount of
code can take a disproportionate time. But that's NOT an argument
for optimising the code, but of simplifying the (language) design
to allow for genuinely incremental compilation.
Regards,
Nick Maclaren.
Bart van Ingen Schenau
> On 6/21/2010 8:07 AM, Bart van Ingen Schenau wrote:
>
> > When writing software, one of my targets, besides correctness,
> > readability and maintainability, is to reach a good efficiency, where
> > efficiency is a trade-off between execution speed, memory usage,
> > development costs (mostly -time) and implementation constraints
> > (preferred language, platform limitations, etc.).
>
> > At design time, you select the most efficient algorithm.
> > At coding time, you write the most efficient implementation of the
> > algorithm.
> > And only when it is still not fast enough, you break out the profiler
> > and see what further optimizations are needed. Hopefully only micro-
> > optimizations, or you made a wrong trade-off in the earlier stages.
> > And it is only for micro-optimizations that goals like maintainability
> > may become less important.
>
> > regards,
> > Bart v Ingen Schenau
{ ^ such a closing greeting and signature should have been removed
from the quoting in the first place. -mod }
>
> I had one employer recently where this degree of code quality was far
> too expensive.
Somehow I doubt that. Note that I have factored the development cost
also in the efficiency measure. If they don't have the budget to do an
evaluation of the existing algorithms, then they will get what my
experience tells me is best and can be implemented within the given
constraints.
I will not implement a sub-optimal algorithm if I know I can implement
a better one within the same time-frame.
> All of the code was to be used internally by this one
> small company and it was to be executed in batch mode.
>
> I am thinking that a focus on speed may be most appropriate when speed
> directly impacts response time, and the user is idle while waiting for
> the response. This is increasingly more important depending on the
> number of users, the duration of the response time, and the cost of the
> user's time.
But why would you make something that is designed as a batch job
knowingly inefficient?
Perhaps someone will someday try to run the job interactively.
Probably the amount of data being fed into the process will increase
over time, which might mean that an inefficient process causes the
nightly run to take more than a night.
Bart v Ingen Schenau
Keith H Duggar
> On 6/21/2010 6:34 PM, Keith H Duggar wrote:
> > What you described as "conventional wisdom" is more aptly
> > termed "naive wisdom" ie an oxymoron. That we are working in
> > an industry where it has somehow become acceptable for those
> > without proper education and training to produce our product
> > (software) is another matter entirely; and it shows.
>
> as conventional wisdom by various respondents on other similar forums.
> Essentially just get it working without considering speed at all, and
> then later make it faster as needed. This does sound pretty naive.
In my opinion, Joshua Maurice sums up what we are discussing
perfectly in his post
http://groups.google.com/group/comp.lang.c++.moderated/msg/dacba7e87ded4dd7
Engineering hinges on reasoning about the goals and resources.
Once you replace reasoning with mantras it is not engineering.
As Joshua points out, many such mantras are reactions pushing
back against equally naive mantras and practices.
> However as Pete Becker so aptly pointed out it is very often the case
> that the above degree of focus on performance is far too costly. I had
> one employer that required batch programs for internal use where any
> time spent on performance was time wasted.
Sure, and a good engineer will determine where time is well put.
Also, as Walter Bright hinted at, if you have enough experience
knowing which optimizations will pay off can allow one to rather
quickly design and implement with those in mind without losing
much if any productivity even in the short-term. And yeah that
can often pay big dividends over the project lifetime.
KHD
Dragan Milenkovic
> On 6/21/2010 6:34 PM, Keith H Duggar wrote:
>>
>> Umm ... except that your thread title and various statements
>> tried to create a (false) distinction between "conventional
>> wisdom" and "this way" that does not exist. What Walter above
>> describes is conventional wisdom at least among those who are
>> educated (or have otherwise learned) proper /engineering/
>> (software and otherwise).
>>
>> What you described as "conventional wisdom" is more aptly
>> termed "naive wisdom" ie an oxymoron. That we are working in
>> an industry where it has somehow become acceptable for those
>> without proper education and training to produce our product
>> (software) is another matter entirely; and it shows.
>>
>> KHD
>>
>>
>
> What I cited as conventional wisdom has been cited to me countless times
> as conventional wisdom by various respondents on other similar forums.
> Essentially just get it working without considering speed at all, and
> then later make it faster as needed. This does sound pretty naive.
This is true, but only if applied properly. For example, you can
(and should) leave for later revisions to improve data representation,
implemented algorithms, etc. You can also rewrite larger pieces
of your software, provided that the new code can fit well.
But you really need a _proper_ design to start with... redesigning
the compiler is much costly than implementing a faster parser.
By "proper" design, I mean that the software solves specified
goals on the design level, whether those goals include performance,
scalability, response time, reliability, throughput,
user experience :-D ...
So, those who cite "conventional wisdom" are saying: "Why do you care
to write the fastest parser all at once?!?". But they do hope that
you won't have to change 80% of the whole compiler because you
suddenly realized that the parser is not modular and has spread
its roots all over the place. (I'm bad at examples... sorry...)
At least, this is how I interpret Keith's words.
"Conventional wisdom" you mention is there to make you spend more time
on analyzing, design, refactoring... instead of worrying too much
prematurely for lower level implementation and representation.
You _do_ have to worry about those things, too... and know in advance
what can and cannot be done; but you don't need to write it immediately.
--
Dragan
Peter Olcott
>> small company and it was to be executed in batch mode.
>>
>> I am thinking that a focus on speed may be most appropriate when speed
>> directly impacts response time, and the user is idle while waiting for
>> the response. This is increasingly more important depending on the
>> number of users, the duration of the response time, and the cost of the
>> user's time.
>
> But why would you make something that is designed as a batch job
> knowingly inefficient?
You simply don't spend any time on making it efficient.
> Perhaps someone will someday try to run the job interactively.
> Probably the amount of data being fed into the process will increase
> over time, which might mean that an inefficient process causes the
> nightly run to take more than a night.
>
> Bart v Ingen Schenau
>
>
All of this was moot to the employer in question. If time was taken to
make the code fast the whole project would become infeasibly expensive.
Take a look at what Pete Becker said about this, he made a good point.
Peter Olcott
> perfectly in his post
>
> http://groups.google.com/group/comp.lang.c++.moderated/msg/dacba7e87ded4dd7
>
I would agree with this except the statement indicating that my UTF8.h
code was hackery. None of the many comments indicated that there was
anything at all substantively wrong with the provided implementation.
> Engineering hinges on reasoning about the goals and resources.
> Once you replace reasoning with mantras it is not engineering.
> As Joshua points out, many such mantras are reactions pushing
> back against equally naive mantras and practices.
>
>> However as Pete Becker so aptly pointed out it is very often the case
>> that the above degree of focus on performance is far too costly. I had
>> one employer that required batch programs for internal use where any
>> time spent on performance was time wasted.
>
> Sure, and a good engineer will determine where time is well put.
> Also, as Walter Bright hinted at, if you have enough experience
> knowing which optimizations will pay off can allow one to rather
> quickly design and implement with those in mind without losing
> much if any productivity even in the short-term. And yeah that
> can often pay big dividends over the project lifetime.
>
> KHD
>
That is almost a restatement of my own position. My own position would
have the first priority of determining whether or not and to what degree
high performance is necessary, and then provide that degree of
performance especially at design time. Micro optimizations can be
provided later on as needed after a good design has been implemented. If
you really need high speed, then this must be designed in from the start.
Peter Olcott
>> far too expensive. All of the code was to be used internally by
>> this one small company and it was to be executed in batch mode.
>
> Er, no. As I teach, increasing quality (mainly including
> consistency checking) often doubles the time to get the demonstration
> working, and halves the time until you can actually use the results -
> and that is for researchers running their own code. One extreme
> example was
The owner of this company was not aware of this. Also I am not talking
about reducing the quality of the code, merely not spending any time on
improvements to the the performance of the code.
> IBM CICS, when it was redesigned using Z - they didn't even start
> coding until a long way through the schedule, and finished ahead of
> schedule with many fewer bugs than budgetted for! Impressive.
Yes, great design directly results in disproportional reductions in
debugging time.
>
> I agree with you about mere performance - that is far less often an
> issue than is made out. Nowadays.
>
>> I am thinking that a focus on speed may be most appropriate when
>> speed directly impacts response time, and the user is idle while
>> waiting for the response. This is increasingly more important
>> depending on the number of users, the duration of the response
>> time, and the cost of the user's time.
>>
>> Millions of software engineers waiting several minutes for a
>> compiler to finish (10-100 times a day) would seem to provide a
>> good example of a great need for very fast execution.
>
> Definitely NOT. If they spend more than a few percent of their time
> compiling, someone has got it badly wrong. Again, that was not so 40
> years back, but please let's move on!
The original Microsoft Pascal compiler was sixty-fold slower that Turbo
Pascal 3.0. Three seconds on TP took 3 minutes on MS.
>
> I will agree that a lot of the time the people who have got it badly
> wrong are the language and library designers and implementors. With
> both C++ and (modern) Fortran, recompiling a very small amount of
> code can take a disproportionate time. But that's NOT an argument
> for optimising the code, but of simplifying the (language) design to
> allow for genuinely incremental compilation.
Or adapting the compiler design to account for the existing language so
that it can do a better job on incremental compilation.
Peter Olcott
What I am saying is that if high speed is a design goal, than it must be
considered throughout the design process and not postponed to later on.
This would directly contradict the conventional wisdom that I have had
related to me.
Also I agree with you the the implementation of a good design can wait
until later on for additional improvements as needed. This is exactly
what I mean what I am referring to aiming for the ballpark of the
fastest code: Design it to be fast, implement it to be simple.
--
Joshua Maurice
> > In my opinion, Joshua Maurice sums up what we are discussing
> > perfectly in his post
>
>
> I would agree with this except the statement indicating that my UTF8.h
> code was hackery. None of the many comments indicated that there was
> anything at all substantively wrong with the provided implementation.
No offense intended. I'm sure your code is fine quality code. However,
I view this as a micro optimization in the same vein as my coworker
who spent an hour measuring the time of clock() because he was afraid
it would be too slow in a function which allocated 10 MB blocks (or
something). I think both are overkill in a professional setting. It's
hackery in terms of where you put your effort, not in terms of code
quality. If you're doing it just for fun, more power to you.
Peter Olcott
> On Jun 22, 11:30 pm, Peter Olcott<NoS...@OCR4Screen.com> wrote:
>>> In my opinion, Joshua Maurice sums up what we are discussing
>>> perfectly in his post
>>
>>> http://groups.google.com/group/comp.lang.c++.moderated/msg/dacba7e87d...
>>
>> I would agree with this except the statement indicating that my UTF8.h
>> code was hackery. None of the many comments indicated that there was
>> anything at all substantively wrong with the provided implementation.
>
> No offense intended. I'm sure your code is fine quality code. However,
> I view this as a micro optimization in the same vein as my coworker
> who spent an hour measuring the time of clock() because he was afraid
> it would be too slow in a function which allocated 10 MB blocks (or
> something). I think both are overkill in a professional setting. It's
> hackery in terms of where you put your effort, not in terms of code
> quality. If you're doing it just for fun, more power to you.
>
>
I don't see how you consider this a micro optimization. There are
numerous aspects that were deliberately not optimized.
http://www.ocr4screen.com/UTF8.h
Another advantage of this design is that it directly maps to the
definition of UTF-8 so it was very easy to maximize its reliability.
Another implementation that I was considering was 300% faster, yet kept
crashing.
The above code is a concrete example of exactly what I mean by the
ballpark of as fast as possible:
(1) Maximize self-documentation
(2) Minimize inessential complexity
(3) Which minimizes debugging time.
It was the simplicity of this design (the way that the code directly
maps to the definition of UTF-8) that provides its high performance.
Joshua Maurice
> In article <b7mdnUm0cN66woLRnZ2dnUVZ_vmdn...@giganews.com>,
> >I am thinking that a focus on speed may be most appropriate when speed
> >directly impacts response time, and the user is idle while waiting for
> >the response. This is increasingly more important depending on the
> >number of users, the duration of the response time, and the cost of the
> >user's time.
>
> >Millions of software engineers waiting several minutes for a compiler to
> >finish (10-100 times a day) would seem to provide a good example of a
> >great need for very fast execution.
>
> Definitely NOT. If they spend more than a few percent of their time
> compiling, someone has got it badly wrong. Again, that was not so
> 40 years back, but please let's move on!
I'm curious where you have worked where this is the case. First, to
define terms, a good incremental build cascades the build down the
dependency graph and has a termination condition to end the cascade
early. In my current employment, I spend a significant part of my day
waiting on the build. (~1-2 hours for a clean compile \without tests\
on a fast developer computer.) The build is hopelessly not good
incremental. (I hate you Maven.)
Moreover, as I'm trying to discuss here
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c830c7c07951f4a6#
to no avail, as far as I can tell, all build systems in common use
today under idiomatic usage are not incrementally correct. All of
them. GNU Make, Ant, Maven, cook, bjam, etc.
I agree with "If they spend more than a few percent of their time
compiling, someone has got it badly wrong". However, I'm not sure this
is the actual way things are commonly done. I've only had minimal
experience relative to others here, but currently I spend quite a bit
more than "a few percent" of my time compiling (and running [unit /
acceptance / integration / regression / checkin / whatever] tests). I
wonder how other companies do it.
> I will agree that a lot of the time the people who have got it badly
> wrong are the language and library designers and implementors. With
> both C++ and (modern) Fortran, recompiling a very small amount of
> code can take a disproportionate time. But that's NOT an argument
> for optimising the code, but of simplifying the (language) design
> to allow for genuinely incremental compilation.
I think that's not quite true for C++. To get acceptable build times,
first, get an actual correct incremental build system, and then apply
pimpl at crucial junctures to remove lots of edges from the dependency
graph. Voila: a correct incremental build where a small change will
usually result in a small (incremental) build time, or at least one
proportional to the size of the change and not to the size of the code
base.
The problem is I just can't find anyone who really cares about
creating an actual correct incremental build system. The rest of it is
well known, but serious incremental correctness is almost unknown and
unstudied as far as I can tell.
nm...@cam.ac.uk
Joshua Maurice <joshua...@gmail.com> wrote:
>On Jun 22, 4:48 pm, n...@cam.ac.uk wrote:
>> In article <b7mdnUm0cN66woLRnZ2dnUVZ_vmdn...@giganews.com>,
>> >I am thinking that a focus on speed may be most appropriate when speed
>> >directly impacts response time, and the user is idle while waiting for
>> >the response. This is increasingly more important depending on the
>> >number of users, the duration of the response time, and the cost of the
>> >user's time.
>>
>> >Millions of software engineers waiting several minutes for a compiler to
>> >finish (10-100 times a day) would seem to provide a good example of a
>> >great need for very fast execution.
>>
>> Definitely NOT. If they spend more than a few percent of their time
>> compiling, someone has got it badly wrong. Again, that was not so
>> 40 years back, but please let's move on!
>
>I'm curious where you have worked where this is the case. First, to
>define terms, a good incremental build cascades the build down the
>dependency graph and has a termination condition to end the cascade
>early. In my current employment, I spend a significant part of my day
>waiting on the build. (~1-2 hours for a clean compile \without tests\
>on a fast developer computer.) The build is hopelessly not good
>incremental. (I hate you Maven.)
As I said, someone has got it badly wrong. I didn't say who!
Getting it right is not easy, and has to start with the language
standard, include the implementation, and continue onto the way
that the language is used (i.e. the program is designed). But it
is possible.
Regards,
Nick Maclaren.
Peter Olcott
then make those parts that are too slow faster.
What if the original goal is to make the code in the ball park of as
fast as possible?
For example how fast is fast enough for a compiler? In the case of the
time it takes for a compiler to compile, any reduction in time is a
reduction of wasted time.
*** NOTE ***
Since we are only shooting for the ballpark of the fastest code, we only
focus on those things that can have a big impact on speed. In other
words the fastest basic design where the code is extremely readable.
Readability is the first priority and speed is the secondary priority.
I can see where this would take more time to get the code working. It
also seems (from my many years of doing this) to result in high quality
fast code in much less time than the conventional wisdom method.
It results in high quality fast code in less steps than the conventional
wisdom method because it is much faster to improve a design than it is
to improve code. Design is at a much higher level of abstraction than
code so there is much less to change. Because there is much less to
change it takes much less time to improve a design than it does to
improve code.
*** NOTE *** All of the above only applies to the case where the
original design goal is to make the code in the ballpark of as fast as
possible. It may be as much as the majority of the time where the
benefit of extra speed is not worth the additional development costs.
Bo Persson
> Conventional wisdom says to get the code working and then profile
> it and then make those parts that are too slow faster.
>
> What if the original goal is to make the code in the ball park of as
> fast as possible?
>
> For example how fast is fast enough for a compiler? In the case of
> the time it takes for a compiler to compile, any reduction in time
> is a reduction of wasted time.
>
Yes, but you still have to find out where it spends most of its time.
Is it disk I/O? Parsing the source? Symbol table management?
Instantiating templates? Something elsè?
It doesn't help a bit if your parsing is lightning fast, if that just
means the compiler has to wait longer for the next I/O operation to
complete.
Bo Persson
Paul Bibbings
> Conventional wisdom says to get the code working and then profile it
> and then make those parts that are too slow faster.
>From your beginning I would have supposed you to go on to discuss issues
that relate to *execution* time. However...
> What if the original goal is to make the code in the ball park of as
> fast as possible?
>
> For example how fast is fast enough for a compiler? In the case of the
> time it takes for a compiler to compile, any reduction in time is a
> reduction of wasted time.
... you then bring in *build* time, and then ...
> *** NOTE ***
> Since we are only shooting for the ballpark of the fastest code, we
> only focus on those things that can have a big impact on speed. In
> other words the fastest basic design where the code is extremely
> readable. Readability is the first priority and speed is the secondary
> priority.
>
> I can see where this would take more time to get the code working. It
> also seems (from my many years of doing this) to result in high
> quality fast code in much less time than the conventional wisdom
> method.
... we're suddenly talking about *development* time.
I'm, then, left wondering which `time' it is that is important to you
here.
I mention my confusion because I would say that the issues involved in
each case merit different considerations, and it is sometimes the case
that one or more might have to be compromised in order to best promote
the one or more that has the highest priority for a particular project.
Regards
Paul Bibbings
Nick Hounsome
> Conventional wisdom says to get the code working and then profile it and
> then make those parts that are too slow faster.
>
> What if the original goal is to make the code in the ball park of as
> fast as possible?
At what cost?
> For example how fast is fast enough for a compiler? In the case of the
> time it takes for a compiler to compile, any reduction in time is a
> reduction of wasted time.
>
> *** NOTE ***
> Since we are only shooting for the ballpark of the fastest code, we only
> focus on those things that can have a big impact on speed.
How do we know where the ballpark is?
How do we know "those things" without profiling? If we're going to try
to find them by analysis then how much time and money do we spend and
how do we know that we've analyzed the the right things?
> In other
> words the fastest basic design where the code is extremely readable.
> Readability is the first priority and speed is the secondary priority.
If the code is extremely readable then most likely it is either not
the fastest design or it is the design we would have come up with
anyway without being hung up on performance.
> I can see where this would take more time to get the code working.
Why? If it is extremely readable then there should be few bugs.
It might well take more time to DESIGN but that is the problem - How
long do you spend looking for the fastest design (without profiling)?
> It
> also seems (from my many years of doing this) to result in high quality
> fast code in much less time than the conventional wisdom method.
> It results in high quality fast code in less steps than the conventional
> wisdom method because it is much faster to improve a design than it is
> to improve code.
But it is much easier to analyse and test code than design.
> Design is at a much higher level of abstraction than
> code so there is much less to change. Because there is much less to
> change it takes much less time to improve a design than it does to
> improve code.
>
> *** NOTE *** All of the above only applies to the case where the
> original design goal is to make the code in the ballpark of as fast as
> possible. It may be as much as the majority of the time where the
> benefit of extra speed is not worth the additional development costs.
When has anyone EVER said to you "Make this as fast as possible and
damn the cost and delivery date"?
It's never happened to me in over 25 years.
In the real world the first priority is the delivery date every time -
even to the point that most places I've worked would rather send a
customer a product that doesn't meet REAL performance requirements
(not just "as fast as possible") than slip the delivery date.
Peter Olcott
> Peter Olcott wrote:
>> Conventional wisdom says to get the code working and then profile
>> it and then make those parts that are too slow faster.
>>
>> What if the original goal is to make the code in the ball park of as
>> fast as possible?
>>
>> For example how fast is fast enough for a compiler? In the case of
>> the time it takes for a compiler to compile, any reduction in time
>> is a reduction of wasted time.
>>
>
> Yes, but you still have to find out where it spends most of its time.
> Is it disk I/O? Parsing the source? Symbol table management?
>
I just make sure that it does not spend much more time than necessary
anywhere.
Joshua Maurice
software engineering, which is more suited for 'comp.software-eng'.
please either bring it back, or wrap it up. thanks. -mod }
I wrote up my own thoughts on this on the WikiWiki a while back.
There's so many competing "axioms" and maxims like "you aren't going
to need it", "keep it simple, stupid", "rules of optimization: 1-
don't do it, don't do it yet, experts only - profile first". I think
all of these things are just pushback against the practices seen in
certain contexts and cultures. IMHO, they fail to capture what is
really needed, and they fail to capture the actual reasoning which
should be used.
Here is my own thoughts on the subject.
Axiom: The developer is out to make the company money. (Sure other
"moral" axioms are involved like "don't commit murder", but we all
understand what I mean when our primary goal is to make the company
money.) This is the end goal of writing code professionally.
We can then derive some intermediate goals:
- Write maintainable code for future developer productivity gains.
- Write code which compiles quickly for future developer productivity
gains.
- Write code which executes its task quickly to be attractive to
customers.
- Write robust and correct code to be attractive to customers.
And more.
When you are about to write code, you can do "big design up front",
"agile aka hack it as you go and refactor quickly", etc. I think most
of these are just reactionary to certain bad programmer practices.
This is especially true for most developer's understanding of these
things. They become mantras and maxims. They lose their original
intent.
In short, when writing code, there's generally a tradeoff between
maintainable and extensible code vs fast executing code. Some people
focus too much on writing fast executing code. I have a fellow
colleague who took a couple hours to time the system clock() call to
see if it could be a performance bottleneck in a function which
allocates megabytes of data per call (a dynamic memory allocator).
Most people recognize this is overkill and one shouldn't worry about
such things until a profiler tells use we need to. The opposite end is
people who would try to implement a hard number cruncher in Ruby. We
recognize it just as folly.
As an example, let's consider some programmers working on implementing
a GNU Make clone. They have a couple of distinct options when they
first start:
1- Just whip up some working example that covers some portion of use
cases.
2- Big design up front for the entire system.
- Or more likely 3- Somewhere in the middle.
Presuming that they went with 2 or 3, they then have another option:
A- Write the task execution engine to be single threaded from the
start.
B- Write the task execution engine to be multi-threaded from the
start.
C- Write the task execution engine to be distributed from the start.
In this case, there are definite costs associated with implementing
each solution, where A is easier than B, and B is much easier than C.
However, C will outperform B at runtime, and B will outperform A at
runtime.
Without knowing more about the specific problem, the company, the
company's goals, the company's time horizon, the economy, etc.,
something, a developer cannot make an informed decision between A, B,
and C.
Every such question as the OP's basically boils down to the question
"A, B, or C?". It's the question of "Should I write a fast framework
from the beginning?", or "Should I write my code in such a way that
the suspected hotspots can be optimized later if need be?".
Specifically, when writing a piece of code, one must always ask:
1- Is there a better way to do it?
2- How much more expensive is it (in developer time) to do the better
way now?
3- How much "better" execution time (or other metric of the end
product) will the better way give? And what's the likelyhood of a
customer needing this extra power? How important is this better
execution metric to the company and to its customers?
4- How much "better" maintainable and extensible will the code be if
written the better way? Aka how much time developer time will be saved
down the road? Which depends on how likely is this extensibility to be
used in the future? And how important are the features which will use
this extensibility?
5- *Important* Technical debt - how much harder would it be to
implement later if we did the quicker way now?
6- *Important* What is the company's time horizon? Even if the product
would be 10 times better with this feature, if it causes the product
to slip the company could lose marketshare and go out of business.
7- *Important* Opportunity cost - can your time be better spent
elsewhere on the product (or on another product of the company)?
For my example of measuring the runtime of clock() in a function that
allocates 100 MB, the answer is obvious: don't worry about it. For my
example of GNU Make, the answer is not immediately clear. When the
answer is not clear, you, or your product manager, or your team, etc.,
have to make a educated best guess, but for the love of -- something,
don't just repeat a maxim like "keep it simple stupid" without
understanding and making clear the assumptions behind such a maxim.
PS: My own maxims, purely an educated guess on fact and unsupported by
hard scientific studies, are:
As a principle but not a hard rule, designs should be kept modular and
decoupled.
Micro optimizations which can be contained behind a single interface
should not be pursued until a profiler tells you to. (Ex: Peter
Olcott's hackery with his UTF8 finite state machine.) Doing the
"quicker to implement" solution won't accrue any "technical debt", so
it's much more likely in your situation for opportunity cost to
override doing the "faster execution" code now, though again it
depends on the particulars of the situation, aka questions 1-7.
Macro optimizations that cross modules, that affect interfaces and the
architecture, should be considered carefully up front. (Ex: single
threaded vs multi threaded vs distributed.) Here, doing the "quicker
to implement" solution will much more likely accrue a large amount of
"technical debt", so it's more likely that the "right" decision is to
do the "longer to implement" but "faster executing" code now, though
again it depends on the particulars of the situation, aka questions
1-7.
Peter Olcott
> On 17 June, 19:54, Peter Olcott<NoS...@OCR4Screen.com> wrote:
>> Conventional wisdom says to get the code working and then profile it and
>> then make those parts that are too slow faster.
>>
>> What if the original goal is to make the code in the ball park of as
>> fast as possible?
>
> At what cost?
It may cost as much as 50% more than just getting the code working. Very
often this also results in code that is essentially simpler, thus easier
to maintain.
>
>> For example how fast is fast enough for a compiler? In the case of the
>> time it takes for a compiler to compile, any reduction in time is a
>> reduction of wasted time.
>>
>> *** NOTE ***
>> Since we are only shooting for the ballpark of the fastest code, we only
>> focus on those things that can have a big impact on speed.
>
> How do we know where the ballpark is?
>
> How do we know "those things" without profiling? If we're going to try
> to find them by analysis then how much time and money do we spend and
> how do we know that we've analyzed the the right things?
>
I just keep analyzing until I know that the process can not be
accomplished in fewer steps. Minimizing the instructions in the
execution trace. I don't strive to do this perfectly.
>> In other
>> words the fastest basic design where the code is extremely readable.
>> Readability is the first priority and speed is the secondary priority.
>
> If the code is extremely readable then most likely it is either not
> the fastest design or it is the design we would have come up with
> anyway without being hung up on performance.
It has been my experience that when performance is ignored, performance
suffers. A major system that I worked on recently suffered a 30-fold
degradation in performance versus this same system's prior performance
specifically because the performance impact of major redesign choices
was ignored.
>
>> I can see where this would take more time to get the code working.
>
> Why? If it is extremely readable then there should be few bugs.
Paying constant attention to performance tends to take more initial
development time than ignoring performance considerations.
> It might well take more time to DESIGN but that is the problem - How
> long do you spend looking for the fastest design (without profiling)?
Far less time that it would take to implement enough of the design so
that it could be profiled.
>
>> It
>> also seems (from my many years of doing this) to result in high quality
>> fast code in much less time than the conventional wisdom method.
>> It results in high quality fast code in less steps than the conventional
>> wisdom method because it is much faster to improve a design than it is
>> to improve code.
>
> But it is much easier to analyse and test code than design.
How could this be true? This would be like saying it is faster to read a
500 page book, than it is to read the synopsis of this same book. It has
been my experience that it is orders of magnitudes faster to analyze a
design than it is to analyze code that implements this same design.
>
>> Design is at a much higher level of abstraction than
>> code so there is much less to change. Because there is much less to
>> change it takes much less time to improve a design than it does to
>> improve code.
>>
>> *** NOTE *** All of the above only applies to the case where the
>> original design goal is to make the code in the ballpark of as fast as
>> possible. It may be as much as the majority of the time where the
>> benefit of extra speed is not worth the additional development costs.
>
> When has anyone EVER said to you "Make this as fast as possible and
> damn the cost and delivery date"?
> It's never happened to me in over 25 years.
>
Not as fast as possible. In the ballpark (within at least an order of
magnitude) of as fast as possible. Also even this goal only applies to
things such as compilers and operating systems.
Öö Tiib
the topic of our newsgroup. thanks. -mod }
On 17 juuni, 21:54, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Conventional wisdom says to get the code working and then profile it and
> then make those parts that are too slow faster.
Yes. Write prototype, to get the algorithm for the best case tests.
Then you have algorithm and may throw prototype away. Now write real
version 1. with correctness as first goal, safety as second goal. Keep
code also readable with flexible design. Speed is totally forbidden to
think about since there are too much goals already for human being at
once.
> What if the original goal is to make the code in the ball park of as
> fast as possible?
Crap goal. What it does, why, for whom, how correctly, with what
restrictions and how harmlessly are always more important. No one
jumps out of window to leave their apartment. All use door, elevator
etc. Lot more complexity and slower. Why? Because it is more correct
and safe.
> For example how fast is fast enough for a compiler? In the case of the
> time it takes for a compiler to compile, any reduction in time is a
> reduction of wasted time.
Nope. Compiler must be good from all other sides too. Time constraints
are only one of huge pile of constraints. Thinking about speed too
much may result you forget why you do it. Forgetting why you do it is
just entertaining, not serious : http://www.youtube.com/watch?v=7K-vwzozpwE
> *** NOTE ***
> Since we are only shooting for the ballpark of the fastest code, we only
> focus on those things that can have a big impact on speed. In other
> words the fastest basic design where the code is extremely readable.
> Readability is the first priority and speed is the secondary priority.
Typical application takes majority of running time running less than
5% its code base. So 95% of time thinking about speed is thinking
about wrong things. Since it might be not obvious what are the 5% then
also thinking about speed when writing the 5% was premature.
> I can see where this would take more time to get the code working. It
> also seems (from my many years of doing this) to result in high quality
> fast code in much less time than the conventional wisdom method.
>
> It results in high quality fast code in less steps than the conventional
> wisdom method because it is much faster to improve a design than it is
> to improve code. Design is at a much higher level of abstraction than
> code so there is much less to change. Because there is much less to
> change it takes much less time to improve a design than it does to
> improve code.
>
> *** NOTE *** All of the above only applies to the case where the
> original design goal is to make the code in the ballpark of as fast as
> possible. It may be as much as the majority of the time where the
> benefit of extra speed is not worth the additional development costs.
It is expensive to get correct and stable full application with all
important features covered with tests. It is cheaper to throw away
parts of code and to rewrite them to speed up once you have ready
product. Also its sales raise funds for improving it and its
popularity attracts allies who help you. Hoping to do everything right
at first attempt is like thinking that you are a god.
Ulrich Eckhardt
> From your beginning I would have supposed you to go on to discuss
> issues that relate to *execution* time.
He does.
> However...
[...]
> ... you then bring in *build* time
This is the execution time of an exemple program, a compiler.
> , and then ...
[...]
> ... we're suddenly talking about *development* time.
Yes, development time is the cost, execution time is the result. If I
understand him correctly, the question he wants to discuss is what approach
leads to the best result/cost ratio, under the premise that you need high
performance for the resulting program.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
bf
> It doesn't help a bit if your parsing is lightning fast, if that just
> means the compiler has to wait longer for the next I/O operation to
> complete.
This is perfectly true when the only important thing is the time spend
by that program for its task. However, most programs run in an
environment together with lots of other programs. Every resource
consumed by one program is a resource that is unavailable for others.
So, if the program consumes every available CPU-cycle to just barely
avoid waiting for any I/O operation, the time needed for that program
to complete its task is the same as if it was blazingly fast in its
computation but had to wait a lot. However, the latter program will
make the system as a whole remain snappy, while the former will make
the system sluggish. I know which one I'd prefer to run on my system.
As usual, there's a trade off. It's almost always a waste to spend
months squeezing that last cycle out of the program, especially if
it's waiting for I/O. On the other hand, if you know that your program
uses a large data set, selecting a good algorithm and cache-friendly
data representation from the beginning may be a very good choice
indeed.
_
/Bjorn
Pete Becker
> On 6/17/2010 5:40 PM, Bo Persson wrote:
>> Peter Olcott wrote:
>>> Conventional wisdom says to get the code working and then profile
>>> it and then make those parts that are too slow faster.
>>>
>>> What if the original goal is to make the code in the ball park of as
>>> fast as possible?
>>>
>>> For example how fast is fast enough for a compiler? In the case of
>>> the time it takes for a compiler to compile, any reduction in time
>>> is a reduction of wasted time.
>>>
>>
>> Yes, but you still have to find out where it spends most of its time.
>> Is it disk I/O? Parsing the source? Symbol table management?
>> Instantiating templates? Something elsč?
>>
>
> I just make sure that it does not spend much more time than necessary
> anywhere.
The danger is that you can end up spending far more of your own time
than necessary because you're optimizing things that have no
significant effect on performance. This isn't the olden days when it
made sense to spend a great deal of programmer time at $5 per hour to
reduce CPU time that cost $200 per minute (IBM 7094 in 1970, if I
remember correctly). CPU time is cheap and programmer time is not.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Peter Olcott
> On 2010-06-17 15:15:16 -0400, Peter Olcott said:
>
>> On 6/17/2010 5:40 PM, Bo Persson wrote:
>>> Peter Olcott wrote:
>>>> Conventional wisdom says to get the code working and then profile
>>>> it and then make those parts that are too slow faster.
>>>>
>>>> What if the original goal is to make the code in the ball park of as
>>>> fast as possible?
>>>>
>>>> For example how fast is fast enough for a compiler? In the case of
>>>> the time it takes for a compiler to compile, any reduction in time
>>>> is a reduction of wasted time.
>>>>
>>>
>>> Yes, but you still have to find out where it spends most of its time.
>>> Is it disk I/O? Parsing the source? Symbol table management?
>>> Instantiating templates? Something elsč?
>>>
>>
>> I just make sure that it does not spend much more time than necessary
>> anywhere.
>
> The danger is that you can end up spending far more of your own time
> than necessary because you're optimizing things that have no significant
> effect on performance. This isn't the olden days when it made sense to
> spend a great deal of programmer time at $5 per hour to reduce CPU time
> that cost $200 per minute (IBM 7094 in 1970, if I remember correctly).
> CPU time is cheap and programmer time is not.
>
Yes this is true. I am only making this recommendation for senior
developers that can tell what kind of things would tend to have large
impacts on performance in advance. Also the focus is to get a fast basic
approach, not to optimize every minute detail.
This advice is also restricted to things where there is no limit
indicating "fast enough", things such as compilers and operating systems
where any increase in speed directly results in a decrease of wasted time.
--
Nick Hounsome
> > When has anyone EVER said to you "Make this as fast as possible and
> > damn the cost and delivery date"?
> > It's never happened to me in over 25 years.
>
> Not as fast as possible. In the ballpark (within at least an order of
> magnitude) of as fast as possible. Also even this goal only applies to
> things such as compilers and operating systems.
I repeat my previous question - How do you know in advance what the
best possible performance is?
If you don't know then how do you know when you're within an order of
magnitude?
Contrariwise if you DO know and you choose a suboptimal algorithm then
presumably you have a good reason for doing so.
In neither case do you need to depart from "conventional wisdom".
Peter Olcott
> On 18 June, 16:24, Peter Olcott<NoS...@OCR4Screen.com> wrote:
>
>>> When has anyone EVER said to you "Make this as fast as possible and
>>> damn the cost and delivery date"?
>>> It's never happened to me in over 25 years.
>>
>> Not as fast as possible. In the ballpark (within at least an order of
>> magnitude) of as fast as possible. Also even this goal only applies to
>> things such as compilers and operating systems.
>
> I repeat my previous question - How do you know in advance what the
> best possible performance is?
You can know this in advance of coding, not in advance of design.
Also we are not seeking the best possible performance, only the ballpark
of the best possible performance. The ballpark of the best possible
performance can be defined by the following heuristic:
There are only a finite number of ways to achieve any specific
functional result. Simply choose the one with the fewest instructions in
the execution path.
Walter Bright
> Peter Olcott wrote:
>> the time it takes for a compiler to compile, any reduction in time
>> is a reduction of wasted time.
>>
>
> Yes, but you still have to find out where it spends most of its time.
> Is it disk I/O? Parsing the source? Symbol table management?
> Instantiating templates? Something elsè?
>
> It doesn't help a bit if your parsing is lightning fast, if that just
> means the compiler has to wait longer for the next I/O operation to
> complete.
I may have something to say here, having been building (very fast) compilers for
30 years now. Making every part of the compiler fast as hell pays off. It pays
off because you have many thousands of people using it, sitting around at
$$$$/hr twiddling their thumbs reading usenet while waiting for their compiler
to finish, and they do this 10's or 100's of times a day. Every tenth of a
second you can shave off pays off.
Parsing speed *is* the gating factor in compiling C code. If it is dominated by
I/O, you need to revisit the I/O code. (iostreams is miserably slow, even fgetc
is poor.)
Compiling D code tends to be more gated by I/O speed since the language is
designed for fast parsing. I've managed to squeeze more out of this by running
the I/O and the parsing in parallel, a technique that won't work compiling C and
C++. But if you've got a multiprocessing make program, even with C/C++ you can
get the I/O in parallel with the parsing, and then there's no escaping the
penalty for a slow parser.
Yes, I've spent many hours profiling compilers. I/O, parsing, symbol tables, and
instantiating templates all show up as big time consumers in the profile.
How fast is fast enough? From experience: users notice it when you double the
compile speed, even though you get there an agonizing tenth of a second at a
time. If you can get a 10x improvement, it's a game changer.
---
Walter Bright
free C, C++, and D programming language compilers (Javascript too!)
http://www.digitalmars.com
Nick Hounsome
> On 6/18/2010 1:19 PM, Nick Hounsome wrote:
>
> > On 18 June, 16:24, Peter Olcott<NoS...@OCR4Screen.com> wrote:
>
> >>> When has anyone EVER said to you "Make this as fast as possible and
> >>> damn the cost and delivery date"?
> >>> It's never happened to me in over 25 years.
>
> >> Not as fast as possible. In the ballpark (within at least an order of
> >> magnitude) of as fast as possible. Also even this goal only applies to
> >> things such as compilers and operating systems.
>
> > I repeat my previous question - How do you know in advance what the
> > best possible performance is?
>
> You can know this in advance of coding, not in advance of design.
No you can't.
Even in relatively constrained subject areas academics are still
discovering ever more efficient ways of doing things - For an example
consider the problem of cracking public key cryptography by factoring
primes. This is an entire area of academic research occupying the
minds of hundreds of the worlds finest brains. Your typical app has
just you to design it within a timescale acceptable to your boss.
Nobody says that you shouldn't code what you believe to be the most
efficient algorithm. If a computation is at best O(f(n)) then do it
O(f(n)) but that is effectively m*f(n)+c. The whole point of the O
notation is that for large n you don't even need to optimize m and c
to be "in the ballpark".
> Also we are not seeking the best possible performance, only the ballpark
> of the best possible performance. The ballpark of the best possible
> performance can be defined by the following heuristic:
>
> There are only a finite number of ways to achieve any specific
> functional result. Simply choose the one with the fewest instructions in
> the execution path.
1) Disregarding time and memory limitations, there are actually an
infinite number of ways to acheive any specific functional result.
2) Even if there were only a finite number how do you know which has
the fewest instructions without enumerating them?
3) How do you know how many instructions in the execution path without
dissassembling actual code? - Here's an idea - You could profile the
code and the time results are a surrogate for the number of
instructions ;-)
Peter Olcott
> Bo Persson wrote:
>> Peter Olcott wrote:
>>> For example how fast is fast enough for a compiler? In the case of
>>> the time it takes for a compiler to compile, any reduction in time
>>> is a reduction of wasted time.
>>>
>>
>> Yes, but you still have to find out where it spends most of its time.
>> Is it disk I/O? Parsing the source? Symbol table management?
{ reminder: please do not quote signatures. thanks. -mod }
So would you say that it is helpful to make it as fast as possible at
design time, instead of just getting it working, and then later making
it fast? (It also sounds like you might follow this with repeated
iterations of speed improvement re-factorings).
Peter Olcott
I have found that even within the same big-O there is easily another
ten-fold improvement by minimizing the executed instructions in the
execution path. I am not talking about hand tweaked assembly language
here. All that I am referring to is roughly minimizing the number of
instructions that get executed. Also I only do this to the extent that
the resulting faster code is just as readable as the prior slower code.
>
>> Also we are not seeking the best possible performance, only the ballpark
>> of the best possible performance. The ballpark of the best possible
>> performance can be defined by the following heuristic:
>>
>> There are only a finite number of ways to achieve any specific
>> functional result. Simply choose the one with the fewest instructions in
>> the execution path.
>
> 1) Disregarding time and memory limitations, there are actually an
> infinite number of ways to acheive any specific functional result.
Although this may be literally true because one can always add yet
another useless instruction that does not provide any functional benefit
to deriving the desired end result, in practice this is not true.
In practice there are typically only a few basic approaches that can
reasonably derive any desired small unit of functionality. One only need
choose the best one of these and then implement this by roughly
minimizing the instructions in the execution path. The key here is
decomposing the problem into very small units of functionality.
> 2) Even if there were only a finite number how do you know which has
> the fewest instructions without enumerating them?
You probably do have to enumerate the small set of basic approaches. I
have never found this set to be larger than six.
> 3) How do you know how many instructions in the execution path without
> dissassembling actual code?
It is most often not worth this degree of effort. Simply minimize the
C++ source code instructions. I myself do generate assembly language for
my most time critical code and examine certain crucial parts of this.
Profiling won't help here because what I am looking for is code that the
compiler generated that is not really needed.
Walter Bright
> So would you say that it is helpful to make it as fast as possible at
> design time, instead of just getting it working, and then later making
> it fast? (It also sounds like you might follow this with repeated
> iterations of speed improvement re-factorings).
If you have the experience to know how to design something for speed, sure, do
it. Designing for speed isn't inherently bad, the problem comes inexperience
with the problem domain leading to a poor choice of tradeoffs.
I suppose it's like designing an airplane. If you want the airplane to go fast,
you've got to make those decisions favoring speed at every step of the design.
But you'll still need an experienced aero engineer to get those tradeoffs right.
Trying to retrofit speed in later isn't going to end well.
---
Walter Bright
free C, C++, and D programming language compilers (Javascript too!)
http://www.digitalmars.com
--
nm...@cam.ac.uk
Walter Bright <wal...@digitalmars-nospamm.com> wrote:
>Peter Olcott wrote:
>> So would you say that it is helpful to make it as fast as possible at
>> design time, instead of just getting it working, and then later making
>> it fast? (It also sounds like you might follow this with repeated
>> iterations of speed improvement re-factorings).
>
>If you have the experience to know how to design something for speed, sure, do
>it. Designing for speed isn't inherently bad, the problem comes inexperience
>with the problem domain leading to a poor choice of tradeoffs.
>
>I suppose it's like designing an airplane. If you want the airplane to go fast,
>you've got to make those decisions favoring speed at every step of the design.
>But you'll still need an experienced aero engineer to get those tradeoffs right.
>Trying to retrofit speed in later isn't going to end well.
Yes and no. I teach (and generally use) a structured approach to
design, and it is imperative to design for speed only at the higher
levels - the lower ones can be fixed up later. For example, from
the top down:
Precise formulation of problem, constraints and objectives.
Well, obviously, if you don't include it here, you will have to
start from scratch.
Generic design of data structures, control flow and potential
algorithms. This is the level at which it is critical, and often
forgotten, because adding it later means a redesign.
Specific design of the same. If you don't include it here, you
will have to rewrite, but that's not a major problem in general, as
it's just replacing one code/data unit by another, very similar, one
and fixing up loose ends.
Actual coding and optimisation. Including it initially is a
Bad Idea, because it often interferes with making the code clean,
easy to debug, maintainable and robust.
Old fogies like me do quite a lot of the last semi-automatically,
because back in the 1960s and 1970s we had no option. Quite a lot
of people had to rewrite simply to get their code small and fast
enough to run their initial tests! But that was then, and it is
almost never an issue nowadays.
Regards,
Nick Maclaren.