From ... From: Erik Naggum Subject: Re: [executables] was: why Haskell hasn't replaced CL yet? Date: 2000/02/28 Message-ID: <3160741395490719@naggum.no>#1/1 X-Deja-AN: 590890376 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> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 951752676 7246 195.0.192.66 (28 Feb 2000 15:44:36 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: 28 Feb 2000 15:44:36 GMT Newsgroups: comp.lang.lisp * Tim Bradshaw | I tried this and it's basically the same (but my machine is a bunch | slower to start than Erik's for reasons I don't really know or care). | I'd assume (perhaps wrongly) that Erik will see a slowdown of 2 for the | serial one because he has a 2-processor machine so he ought to be able to | schedule one process on each cpu for the pll version whereas the serial | one can not do that. Of course that just makes the startup time he's | measuring be the effective time for a ~ 1.2GHz serial machine. So maybe | it's 40ms or something, who cares? nonono, while we're making wild conjectures about the behavior of completely irrelevant tasks, we must not also make serious mistakes, or the data might suddenly become statistically valid. SMP systems don't behave the way people tend to think. like, we used up <1 second of real time, and 1.5 seconds of CPU time, which is not at all close to 40 ms, but more like 30 ms with all the overhead accounted for. however, each process takes less than that, but I don't really know why it takes more than 25 ms per process to fire it up in such a packed loop when it takes close to 20 ms when run once, by itself, but it's fairly consistent. it is not a measurement error -- the real time reported is in 1 ms units, while CPU time is reported in 10 ms units. however, the processor a process runs on doesn't grow any faster just because there's one more of it that can run another process -- it's still a 600MHz processor. it's only during heavy multitasking that such a system can approach 1.2GHz combined performance. otherwise, the big win is only in the interactive response time when one CPU is idle. not that I complain. #:Erik