{"title":"Freeing the essence of a computation","authors":"K. R. Anderson","doi":"10.1145/224133.224136","DOIUrl":"https://doi.org/10.1145/224133.224136","url":null,"abstract":"In theory, abstraction is important, but in practice, so is performance. Thus, there is a struggle between an abstract description of an algorithm and its efficient implementation. This struggle can be mediated by using an interpreter or a compiler. An interpreter takes a program that is a high level abstract description of an algorithm and applies it to some data. Don't think of an interpreter as slow. An interpreter is important enough to software that it is often implemented in hardware. A compiler takes the program and produces another program, perhaps in another language. The resulting program is applied to some data by another interpreter.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130420177","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Ambitious evaluation: a new reading of an old issue","authors":"K. Pitman","doi":"10.1145/224133.224137","DOIUrl":"https://doi.org/10.1145/224133.224137","url":null,"abstract":"Much has been written about Lazy Evaluation in Lisp---less about the other end of the spectrum---Ambitious Evaluation. Ambition is a very subjective concept, though, and if you have some preconceived idea of what you think an Ambitious Evaluator might be about, you might want to set it aside for a few minutes because this probably isn't going to be what you expect.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123188636","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Parallelism in Lisp","authors":"G. Steele","doi":"10.1145/224133.224134","DOIUrl":"https://doi.org/10.1145/224133.224134","url":null,"abstract":"Maybe not as hot a topic in computer architecture as it used to be, but still of considerable interest, is parallelism. How do you make a faster computer? Just strap 20 or 200 or 2000 processors together? As we have learned, the architectural and hardware difficulties are immense (How do you connect them? A shared bus? A network? Is there a single system clock or many clocks?), and after these have been solved there remains the matter of programming.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126277265","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Futures and multiple values in parallel Lisp","authors":"Tanaka Tomoyuki, Uzuhara Shigeru","doi":"10.1145/224133.224135","DOIUrl":"https://doi.org/10.1145/224133.224135","url":null,"abstract":"We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of future chain elimination which avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125322134","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Performing Lisp analysis of the FANNKUCH benchmark","authors":"K. R. Anderson, Duane Rettig","doi":"10.1145/382109.382124","DOIUrl":"https://doi.org/10.1145/382109.382124","url":null,"abstract":"This paper analyzes the FANNKUCH benchmark, that was discussed on the comp.lang.lisp internet newsgroup during September 1994, and reviews the performance issues underlying it. This benchmark involves operations on integers and vectors of integers so one might expect that Lisp and C versions could have comparable performance. However, the original benchmark suggested that the Lisp version was at least 10 times slower than the C version. While this version appeared to be optimized, several important improvements are possible.The improved version is between 24 and 116 percent slower than C when run on several Lisp implementations. This can be accounted for by differences in the quality of the compiled code of the inner loops of the benchmark, not by an essential difference between the two languages. The GNU C compiler, gcc, produces a loop with a larger overall size (footprint) but with a smaller loop body than the current Lisp compilers. In principle, a Lisp compiler can produce these loops with the same or fewer number of instructions.It is easy to write benchmarks that make Lisp appear slower than C. However, as with any highly tuned benchmark, a small change can have a profound effect on performance. even in C. For example, replacing / 2 by ≫1 makes a 40% improvement. Also changing the representation of integers and arrays of integers among C's built in types varies the performance by 80%.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"498 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116194372","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Scheme: the new generation","authors":"John D. Ramsdell","doi":"10.1145/382109.382668","DOIUrl":"https://doi.org/10.1145/382109.382668","url":null,"abstract":"Scheme has served the community for twenty years. It has demonstrated that a useful language can be constructed which has a very small number of rules for forming expressions. Scheme's set of rules were carefully chosen so as to produce a language flexible enough to support most major programming paradigms in use today, yet allow efficient implementations.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122961115","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Semantics of combinations in scheme","authors":"S. Anglade, J. J. Lacrampe, C. Queinnec","doi":"10.1145/382109.382669","DOIUrl":"https://doi.org/10.1145/382109.382669","url":null,"abstract":"This paper presents a denotational semantics for the combinations of the Scheme language. Scheme leaves unspecified the order of evaluation of the terms of a combination. Our purpose is to formally and denotationally characterize such indeterminacy. We achieve this by extending the denotation as well as the domain of final answers to take into account the various possible orders of evaluation.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133705168","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Concurrent replicating garbage collection","authors":"O'TooleJames, NettlesScott","doi":"10.1145/182590.182425","DOIUrl":"https://doi.org/10.1145/182590.182425","url":null,"abstract":"We have implemented a concurrent copying garbage collector that uses replicating garbage collection. In our design, the client can continuously access the heap during garbage collection. No low-lev...","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1994-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115431813","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A library of high level control operators","authors":"C. Queinnec","doi":"10.1145/181889.181891","DOIUrl":"https://doi.org/10.1145/181889.181891","url":null,"abstract":"Numerous high-level control operators, with various properties, exist in the literature. To understand or compare them is difficult since their definitions use quite different theoretical frameworks; moreover, to our knowledge, no implementation offers them all. This paper tries to explain control operators by the often simple stack manipulation they perform. We therefore present what we think these operators are, in an executable framework derived from abstract continuations. This library is published in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For instance, we do not claim our implementation to be faithful nor we attempt to formally derive these implementations from their original definitions. The goal is to give a flavor of what control operators are, from an implementation point of view. Last but worth to say, all errors are mine.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126614908","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The Boyer benchmark meets linear logic","authors":"H. Baker","doi":"10.1145/181889.181890","DOIUrl":"https://doi.org/10.1145/181889.181890","url":null,"abstract":"Of the Gabriel Lisp Benchmarks, the Boyer Benchmark (\"Boyer\") is the most representative of real AI applications, because it performs Prolog-like rule-directed rewriting, and because it relies heavily on garbage collection (GC) for the recovery of storage. We investigated the notion that such programs are unsuitable for explicit storage management---e.g., by means of a \"linear\" programming style in which every bound name dynamically occurs exactly once. We programmed Boyer in a \"linear\" fragment of Lisp in both interpretive-rule and compiled-rule versions, using both true linear (unshared) and reference count methods.We found that since the intermediate result of rewrite is unshared, the linear interpreted version is slower than the non-linear interpreted version, while the linear compiled version is slightly faster than the non-linear compiled version. When sharing is allowed, requiring reference counts for the linear versions, the linear shared versions are not competitive with the non-linear versions, except when \"anchored pointers\" are used. The anchored pointer reference count version, which reclaims storage, is still 1.25X slower than the non-linear version, which reclaims no storage.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128316336","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
求助内容：
应助结果提醒方式：