brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/02/91)
Summary: On a more normal machine (a DECsystem running Ultrix), Tom's Perl script is 6% faster than my csh script. However, it uses four times as much memory, six times as much I/O, and more page faults. Furthermore, where my script is just one line with six simple tools piped together, Tom's original script has 28 lines of code, and his most condensed (and hence incomprehensible) version is still 5 lines of code. Furthermore, Tom's script does not solve the problem as *he* stated it; my script does. So: Is it worth several times more space and several times more programmer effort to get a 6% speedup (and fail to solve the problem)? I think not. In article <1991Feb01.180524.26619@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > Ok, here are the problems with the Dan's latest round of pipes: > 1) It runs considerably slower (percentage-wise) than the perl version > in both system and user times. Tom, your Convex is hardly the generic benchmark machine, and you're cheating by not pointing out memory use. Here are times from a DECsystem-5820 running Ultrix 4.0. Tom's Perl version: 2.3u 3.8s 0:20 30% 279+267k 166+25io 6pf+0w My csh version: 2.1u 4.6s 0:06 100% 74+104k 0+34io 5pf+0w A Sun produces similar results. Well, folks, look at those times. Tom's Perl version does run faster overall---0.4 seconds out of 6.7, a 6% difference. It also uses four times as much memory, six times as much I/O, and more page faults. Tom, you're also ignoring the most basic human engineering factors. My shell script is ONE LINE: one TRIVIAL line, with six obvious tools piped together in sequence. Your shortest Perl version has FIVE lines packed with unobvious, unreadable tricks and no obvious data flow; your shortest readable version has TWENTY-EIGHT lines of code. The shell script is trivial to write, trivial to maintain, and trivial to understand. The same cannot be said of your Perl versions. Sorry for shouting, but you keep ignoring this issue. Okay, folks, we have two scripts that do basically the same job. One of them runs 6% faster, but is five times longer and uses about four times more memory. How much memory do you have on your machine? Can you spare four times your old memory use? Are you willing to write one fifth as many programs just to get a 6% speed improvement? Are you sure that speed improvement will remain when you're swapping every two seconds? > 2) It doesn't list where the collisions occur, which > was, after all, my goal in writing it in the first place. BIG FUCKING DEAL. Your stupid script puts in all sorts of extra garbage, which is against every principle of tool design. You have ``which''; learn to use it. Learn to write code once instead of copying it into every single new program. > 3) It screws up on pathological filenames. I addressed this at length in another posting, which you missed since you and your kill file have been acting so manly. > 4) It gets some things truly wrong: > 6 -rwxr--r-- 1 tchrist 4542 Mar 4 1990 /mnt/tchrist/scripts/errlogd > 6 -rwxr--r-- 1 root 4865 Nov 19 16:58 /usr/adm/bin/errlogd > There's no collision there -- I can't execute the one in /usr/adm/bin > even with that in my path. Dan's version thinks I can, whereas mine > and Randal's and Chip's all know better. I dispute that claim. When you say ``duplicate filenames of different executables in PATH,'' the average admin expects a useful list, something that might point out problems or inconsistencies in the system. Should this list depend on which user happens to execute it (or on which directory he happens to be in)? I think not, for the same reason that I don't like ``which'' output relative to the current directory---really for the same reason that I don't like the system-level concept of a single current working directory. To put it simply: The problem statement doesn't depend on the current user, so the solution shouldn't either. Now I know you prefer to be literal rather than sensible when being sensible would lose an argument. But if we take your original problem definition, YOUR script is truly WRONG. YOU defined the problem as only talking about ``executables,'' not ``things that the current user can execute.'' /usr/adm/bin/errlogd is an executable, whether you can execute it or not. ---Dan
tchrist@convex.COM (Tom Christiansen) (02/02/91)
Gods, it's not enough that I should kill the guy -- two people have
actually *MAILED* me his last posting. ***Sigh.***
Ok, here are the problems with the Dan's latest round of pipes:
1) It runs considerably slower (percentage-wise) than the perl version
in both system and user times. Witness:
$ time perl clash.tom > /dev/null
5.286052 real 2.546462 user 2.135102 sys
$ time csh -f clash.dan > /dev/null
8.468490 real 4.665696 user 3.077168 sys
2) It doesn't list where the collisions occur, which
was, after all, my goal in writing it in the first place.
3) It screws up on pathological filenames.
4) It gets some things truly wrong:
6 -rwxr--r-- 1 tchrist 4542 Mar 4 1990 /mnt/tchrist/scripts/errlogd
6 -rwxr--r-- 1 root 4865 Nov 19 16:58 /usr/adm/bin/errlogd
There's no collision there -- I can't execute the one in /usr/adm/bin
even with that in my path. Dan's version thinks I can, whereas mine
and Randal's and Chip's all know better. I didn't check the TCL version.
I can't figure out what to do with this thread. I really wish it would
die. [So don't post to it, Tom. Yeah, yeah.] I readily agree that it's
cluttering this newsgroup. I'm going to send it to alt.religion.computers,
since it's basically a religious issue, so doesn't belong in comp.lang.perl;
sending it there would be like arguing whether women should exist in
soc.women -- none too cool. If they don't like it there, they can redirect
to alt.flame, I guess. There is actually a thread going there in
alt.religion.computers already about the pipes vs programming approach.
--tom
PS: Go check out comp.org.usenix for Lori's amusing contest posting.
--
"Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now
he can finally have the whole O/S built-in to his editor like he
always wanted!" --me (Tom Christiansen <tchrist@convex.com>)shaver@convex.com (Dave Shaver) (02/05/91)
Dan Bernstein writes: >Summary: On a more normal machine (a DECsystem running Ultrix), Tom's >Perl script is 6% faster than my csh script. >[followed by some interesting stuff mixed with useless flames.] Come on, guys. Each solution has value. Move this flame fest totally out of alt.sources.d. I sick of listening to you bicker.