Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!cwjcc!arun@dsrgsun.ces.cwru.edu From: arun@dsrgsun.ces.cwru.edu (Arun Lakhotia) Newsgroups: comp.lang.prolog Subject: Efficiency, O'Keefe Message-ID: <359@cwjcc.CWRU.Edu> Date: 28 Dec 88 20:04:19 GMT Sender: news@cwjcc.CWRU.Edu Reply-To: arun@dsrgsun.ces.cwru.edu (Arun Lakhotia) Organization: Case Western Reserve University Lines: 54 Thanks Saumya for pointing out some inefficiency in the code I had posted. And also for pointing out that checking for divisors upto "ceil(sqrt(N) + 1)" is sufficient to test for primeness. This property gives a better foundation to the latter code that I'd posted, where I was checking for divisor between I .. N//I+1, (should have read I .. ceil(N//I+1) I think the recursion terminates at ceil(sqrt(N)+1). And regarding my remark on O'K: It was a pun and not a sigh of relief. I have explicitly communicated my appreciation for his taking the time to comment on various issues including coding style in a very early posting, and also to him in person. And I also appreciate Saumya's comments. In particular the insights regarding choice point creation and the possibility of writing code that may enable compilers utilize architecture specific features. Now an offshoot thought. It seems to me that to understand optimization issues in Prolog knowing the architecure of WAM helps a lot. Besides choice point creation things like indexing on the first argument, bypassing the need to shuffle arguments by maintaining the same order for arguments in calls to other subprocedures, etc become clear only after one knows how Prolog is compiled to WAM. (Assuming WAM as the defacto standard abstract machine). To me these issues became clear after reading Gabriel et. al's tutorial on WAM, and Warren's tutorial in Seattle. With the working knowledge of WAM that I have gathered, I can appreciate Saumya's comments. Now some queries: Do people with little or no knowledge of WAM find it a bottleneck in gaining efficiency that is beyond gains achievable due to algorithmic changes or perturbations? Could one say, that the invisibility of control in Prolog is good for writing "declarative programs" but not good enough for writing efficient ones? In contrast, does the visibility of control in other programming languages like Pascal, C, etc help one write efficient programs? How long would it be when the issues like optimizing choice-points can be taken care of by the compiler itself? and at what cost/restriction to the programmer, if any? Arun Lakhotia