From ... From: Erik Naggum Subject: Re: [executables] was: why Haskell hasn't replaced CL yet? Date: 2000/03/03 Message-ID: <3161062467384796@naggum.no>#1/1 X-Deja-AN: 592598538 References: <3160523543335494@naggum.no> <38c0b4ec.72508742@news.earthlink.net> <3160693199764094@naggum.no> <38c34a5c.110764821@news.earthlink.net> <3160726754880201@naggum.no> <38c766c6.118038440@news.earthlink.net> <3160735878041395@naggum.no> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 952076582 10386 195.0.192.66 (3 Mar 2000 09:43:02 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 3 Mar 2000 09:43:02 GMT Newsgroups: comp.lang.lisp * Samuel A. Falvo II | With the computer doing absolutely nothing else in the process. Do you | see the difference here? In a real-world situation, a computer could be | handling network connections, performing back-ups, or otherwise running | other CPU-intensive tasks in the background. That all will definately | influence (and lengthen) startup times. oh, geez, when will this _end_? I don't have this powerful a machine just to boast about it and play games. it's a work-horse for serious development, and it has a number of non-trivial duties. at the time I ran those tests, it turns out that it was servicing a few thousand FTP requests from local network machines that were upgrading some software automatically over the span of the few minutes I ran the tests, it ran a bunch of Netscape frames with animated advertising GIFs, and it provided monitoring and backup services for 6 other computers on its local network, which involves network traffic and low CPU consistency checking. it also received four e-mail messages, the processing of which fires up an Emacs in batch mode to handle the filtering and processing of the incoming messages. the only thing not strictly normal about this is the FTP load. regardless, I have no idea exactly how big this load was during each of the individual _seconds_ that I ran my tests. I have reason to suspect that it had very little effect on anything because the machine is in fact able to perform the vast majority of its duties in zero noticeable time -- which is why it is this powerful to begin with. now, this _could_ explain the 5 ms extra execution time I noticed, but that's just pure speculation on my part, and I see little point in spending the time to figure it out. | I was just pointing out that the measurements performed could be | misleading due to the circumstances in which the measurements were made. so let's assume the measurement errors were on the order of 20 vs 25 ms per invocation. that's the difference between 40 and 50 invocations per second. this bothers you a great deal, apparently. it doesn't bother me. and you were "just pointing out" that it could take _minutes_, which is nothing more than really bad fiction on your part. in _minutes_, this machine has compiled GNU Emacs from scratch (2:30), built a new Linux kernel (2:10), installed staroffice (1:20), built CD images for Debian 2.2 (3:10), or upgraded and installed a 100 packages (2:50). to suggest that this machine should suddenly only manage to start 50 Allegro CL processes because of other work it's doing is simply insane. as long as any goddamn fool can cast doubt on anything anybody says, I suggest a much more honest starting point: "I don't want to believe you!" instead of trying to smear whoever is trying to answer their questions. I'm getting sick of the rampant stupidity that comes with benchmarks and any other myth-deflating devices. myths, apparently, are necessary for the mental survival of some people. perhaps it is not a good idea to try to destroy their misguided beliefs because they turn out to be lunatics if they can't keep their myths alive and well. #:Erik