Hi,
If I can write a program either using "loop" or "mapcar", which one can run
faster and better? I have try to use "time" on this two programs but got no
difference because of CPU too fast.
Wayne wrote:
> Hi,
>
> If I can write a program either using "loop" or "mapcar", which one can run
> faster and better? I have try to use "time" on this two programs but got no
> difference because of CPU too fast.
Then write functions that call those functions 1,000,000 times and call
those.
The answer is, though, "it depends." More likely loop, but
it is not a certainty.
dave
In article <············@mozo.cc.purdue.edu>, Wayne <··@ecn.purdue.edu> wrote:
>If I can write a program either using "loop" or "mapcar", which one can run
>faster and better? I have try to use "time" on this two programs but got no
>difference because of CPU too fast.
If the difference is so small that you can't tell, why do you care?
Wait until your profiling tells you that this particular loop is the
bottleneck, then worry about it.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
* Wayne wrote:
> If I can write a program either using "loop" or "mapcar", which one can run
> faster and better? I have try to use "time" on this two programs but got no
> difference because of CPU too fast.
If you can't time the difference, it probably doesn't matter!
However, in general you have the right approach. You can usually not
tell by intuition which of LOOP or MAPCAR (or MAP*) will be faster in
a given case, you need to experiment by timing your code (be sure to
time your real code, not something much smaller you think may be the
same). Timing (more generally, profiling) will not always tell you
the answer: when it doesn't the answer likely does not matter. Of
course there are exceptions to all this.
--tim
Wayne wrote in message <············@mozo.cc.purdue.edu>...
>Hi,
>
>If I can write a program either using "loop" or "mapcar", which one can run
>faster and better? I have try to use "time" on this two programs but got no
>difference because of CPU too fast.
A smarter person than me once rightly told me that premature
optimizations are the source of 90% of all bugs. I don't know
if he hit the percentage precisely, but he's right. Don't worry
about this sort of thing; write the code so that it is clear and
simple. Optimize it when it all works and your profiling has
revealed a performance problem. If your code is clear and
simple, it will be easier to find the algorithmic flaws that are
more likely your real performance problems.
"Scott McKay" <···@mediaone.net> writes:
> A smarter person than me once rightly told me that premature
> optimizations are the source of 90% of all bugs. I don't know
I heard it was "the root of all evil".
--
vsync
http://quadium.net/ - last updated Mon Oct 2 17:39:49 PDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
On 02 Oct 2000 22:09:11 -0700, vsync <·····@quadium.net> wrote:
>"Scott McKay" <···@mediaone.net> writes:
>
>> A smarter person than me once rightly told me that premature
>> optimizations are the source of 90% of all bugs. I don't know
>
>I heard it was "the root of all evil".
Don Knuth said that I believe.. but he may have heard it elsewhere.
--
Kenneth P. Turvey <······@SprocketShop.com>
--------------------------------------------------------
IDIOT, n - A member of a large and powerful tribe whose influence in
human affairs has always been dominant and controlling.
-- Ambrose Bierce
"Scott McKay" <···@mediaone.net> writes:
>Wayne wrote in message <············@mozo.cc.purdue.edu>...
>>Hi,
>>
>>If I can write a program either using "loop" or "mapcar", which one can run
>>faster and better? I have try to use "time" on this two programs but got no
>>difference because of CPU too fast.
>A smarter person than me once rightly told me that premature
>optimizations are the source of 90% of all bugs. [...]
I agree but like to add one thing: If your program possibly may make
use of preallocated buffers (even when that is not done in the initial
version), designing your interfaces to make use of them (add arguments
for buffer pointers) is not to be considered premature optimization.
On the contrary, it often leads to bad bugs when people later try to
reuse stuff "from under the hood" of normal argument flow because they
don't want to touch the calling convention again. At the very least,
that bombs when the program becomes threaded.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Martin Cracauer wrote:
> "Scott McKay" <···@mediaone.net> writes:
>
> >A smarter person than me once rightly told me that premature
> >optimizations are the source of 90% of all bugs. [...]
>
> I agree but like to add one thing: If your program possibly may make
> use of preallocated buffers (even when that is not done in the initial
> version), designing your interfaces to make use of them (add arguments
> for buffer pointers) is not to be considered premature optimization.
Yes! Not *all* optimization is premature. A good programmer can
very often tell where a major bottleneck will occur. If she can incorporate
a solution into the overall architecture, this may be a lot better, quicker, and
bug free than retrofitting everything later.
dave
"David Hanley" <···@ncgr.org> wrote in message
······················@ncgr.org...
> Yes! Not *all* optimization is premature. A good programmer can
> very often tell where a major bottleneck will occur.
Then there must not be many "good" programmers out there. The few studies
that have been performed to test this conjecture are conclusive in showing
that your statement is unlikely to be true. Most recognized "good
programmers" also disagree, having learned the hard way that their
suppositions about what is a bottleneck are usually incorrect. However, a
good dose of profiling before optimization can work wonders.
>If she can incorporate
> a solution into the overall architecture, this may be a lot better,
quicker, and
> bug free than retrofitting everything later.
Wow! So if she blindly hacks in (see above for the conjecture that she is
not "blindly" hacking) a sub-optimal solution into the architecture, the
architecture is better for it! It is quicker to do, though - why bother
with messy stuff like profiling when you can just hack it in at the
beginning and declare it faster? And bug free? In general, the code you
end up with when "performance enhancements" are made is generally larger and
more complex than the original code. Sounds like more to debug to me!
No offense, but you are wrong, wrong, WRONG. Incredibly incorrect.
faa
* "Frank A. Adrian" <·······@uswest.net>
| Then there must not be many "good" programmers out there.
Well, duh!
| The few studies that have been performed to test this conjecture are
| conclusive in showing that your statement is unlikely to be true.
| Most recognized "good programmers" also disagree, having learned the
| hard way that their suppositions about what is a bottleneck are
| usually incorrect. However, a good dose of profiling before
| optimization can work wonders.
Has it occurred to that they disagree after the ones they have
agreed on didn't even come up? If you're a good programmer, you
don't do utterly boneheaded things only to discover sometime later
that it's a bottleneck. E.g., good Lisp programmers know when to
use append and don't write O(n�) list traversal algorithms when they
coulud do with O(n).
| No offense, but you are wrong, wrong, WRONG. Incredibly incorrect.
No offense, but you don't listen to what others say, so whether you
think it's incorrect is completely irrelevant.
#:Erik
--
If this is not what you expected, please alter your expectations.
In our last episode (Wed, 04 Oct 2000 14:45:43 -0600),
the artist formerly known as David Hanley said:
>Martin Cracauer wrote:
>
>> "Scott McKay" <···@mediaone.net> writes:
>>
>> >A smarter person than me once rightly told me that premature
>> >optimizations are the source of 90% of all bugs. [...]
>>
>> I agree but like to add one thing: If your program possibly may make
>> use of preallocated buffers (even when that is not done in the initial
>> version), designing your interfaces to make use of them (add arguments
>> for buffer pointers) is not to be considered premature optimization.
>
>Yes! Not *all* optimization is premature. A good programmer can
>very often tell where a major bottleneck will occur. If she can incorporate
>a solution into the overall architecture, this may be a lot better,
>quicker, and bug free than retrofitting everything later.
Quite correct. None less than Donald Knuth suggests that this could be
true oh, um, somewhere around 3% of the time.
As for the notion that one can "very often tell where a major
bottleneck will occur," I'll believe Jon Bentley before I believe you.
His longstanding series on "Programming Pearls" has often looked at the
issue of benchmarking, and found that peoples' intuitions of performance
and efficiency are quite counter to reality.
A group he worked with once did serious benchmarks, found that a whole lot
of time in a system was being consumed by a specific loop, then rewrote
it not merely using assembly language, but using _MICROCODE_, expecting
a ten-fold speedup based on their benchmarks, and then discovered,
much to their chagrin, that there was _NO_ effect on system performance
because they hadn't released that the code in question was a busy-loop
that would only run when the system had no worthwhile work to do.
--
········@acm.org - <http://www.ntlug.org/~cbbrowne/linux.html>
I called that number and they said whom the Lord loveth he chasteneth.
* Christopher Browne
| As for the notion that one can "very often tell where a major
| bottleneck will occur," I'll believe Jon Bentley before I believe you.
| His longstanding series on "Programming Pearls" has often looked at the
| issue of benchmarking, and found that peoples' intuitions of performance
| and efficiency are quite counter to reality.
Sure, _after_ they had removed/avoided all the obvious bottlenecks.
What you and Adrian are doing here is called an "anachronism": You
regard the truth of a statement which applies before writing code to
the measurable problems that occur after the code has been written.
This is obviously a bottleneck to effective and efficient _thinking_
like arriving at reasonable smart conclusions in a reasonably short
time. What I don't understand is why did you guys walked right into
this one.
#:Erik
--
If this is not what you expected, please alter your expectations.
* "Wayne" <··@ecn.purdue.edu>
| If I can write a program either using "loop" or "mapcar", which one
| can run faster and better? I have try to use "time" on this two
| programs but got no difference because of CPU too fast.
That's the best statement of a misguided desire to optimize this
newsgroup has ever seen. Thanks! :)
What are you really asking for? What kind of answer would satisfy
your curiosity?
#:Erik
--
If this is not what you expected, please alter your expectations.
In our last episode (03 Oct 2000 06:12:28 +0000),
the artist formerly known as Erik Naggum said:
>* "Wayne" <··@ecn.purdue.edu>
>| If I can write a program either using "loop" or "mapcar", which one
>| can run faster and better? I have try to use "time" on this two
>| programs but got no difference because of CPU too fast.
>
> That's the best statement of a misguided desire to optimize this
> newsgroup has ever seen. Thanks! :)
>
> What are you really asking for? What kind of answer would satisfy
> your curiosity?
Personally, I'd go with:
(if (= (random 2) 1) #'mapcar #'loop)
And I have to agree; this is indeed the most succinct example of
"misguided optimization" that we'll likely ever see...
--
(concatenate 'string "aa454" ·@" "freenet.carleton.ca")
<http://www.ntlug.org/~cbbrowne/linux.html>
Rules of the Evil Overlord #69. "All midwives will be banned from the
realm. All babies will be delivered at state-approved
hospitals. Orphans will be placed in foster-homes, not abandoned in
the woods to be raised by creatures of the wild."
<http://www.eviloverlord.com/>
In article <···························@test.sdt.com>,
Christopher Browne <········@hex.net> wrote:
>
>Personally, I'd go with:
> (if (= (random 2) 1) #'mapcar #'loop)
>
This makes it seem like Mapcar and Loop can be
plug-in replacements for each other!
--d
In our last episode (4 Oct 2000 14:18:49 GMT),
the artist formerly known as Dorai Sitaram said:
>In article <···························@test.sdt.com>,
>Christopher Browne <········@hex.net> wrote:
>>
>>Personally, I'd go with:
>> (if (= (random 2) 1) #'mapcar #'loop)
>
>This makes it seem like Mapcar and Loop can be
>plug-in replacements for each other!
How well that works depends on how far your particular CL
implementation diverges from the HyperSpec...
--
········@hex.net - <http://www.ntlug.org/~cbbrowne/lisp.html>
He doesn't have much of a reputation, or so I've heard.