Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!zen.net.uk!dedekind.zen.co.uk!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Forth reinvention Date: Sat, 22 Feb 2014 10:27:14 -0500 Organization: Aioe.org NNTP Server Lines: 48 Message-ID: References: <2014Feb21.155029@mips.complang.tuwien.ac.at> <2014Feb22.135404@mips.complang.tuwien.ac.at> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:28684 On Sat, 22 Feb 2014 07:54:04 -0500, Anton Ertl wrote: > "Alex McDonald" writes: >> And then, only if you can demonstrate that there are lower hanging >> fruit, >> by which I take it you mean easier ways to programmatically get the 4x >> speedup. I would be surprised if you could point to an example that >> didn't involve an observation as to the general stupidity of programmers >> who select inappropriate and dreadful algorithms. > > In my course on efficient programs the students often optimize a > program I give them, and in several cases I have given them a program > written by someone else, and speedups by a factor of 4 or more were > not rare. Were the original programmers stupid? I don't think so. > In any case, even for relatively small programs, there is a lot of > sequential performance that can be gained, and I expect that there is > more in larger programs. > > With regard to stupidity: In 2009 I chose a program for converting > uids into user names (on a Unix system), which is a performance > bottleneck for ls -l on servers with many users. Some Unix variants > therefore go away from the good old principle of just editing the > passwd file (which contains the mapping), and require to call some > system-specific program afterwards. > > In this case, I think the programmers were stupid. There are lots of > ways to do better without requiring to call that program explicitly; > among them is to call that program automatically when such a mapping > is needed and the passwd file is newer than the mapping file. A group > of my students that used such an approach got a speedup by a factor of > 600 when the cache file is up-to-date (the usual case). Or, you could have "that program" which provides "such a mapping" be called automatically by the Unix tools which update the password file when a new user account is created. Then, "such a mapping" is always up-to-date, and then there is never a need to "call that program explicitly". But, the on-demand or "demand paging" style solution you posted here works too. When I started to read the part of the reply on converting uids to user names, I thought you were going to mention how they unexpectedly used a more efficient method of integer-to-string conversion or a new type of hashing. I.e., anti-climatic. It seems other things have become more important over time than speed, e.g., security, convenience. Rod Pemberton