{"title":"观点:Lisp是Java的替代品","authors":"E. Gat","doi":"10.1145/355137.355142","DOIUrl":null,"url":null,"abstract":"I n a recent study Prechelt (1999) compared the relative performance of Java and C++ in execution time and memory usage. Unlike many benchmark studies, Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill. Prechelt concluded that \" as of JDK 1.2, Java programs are typically much slower than programs written in C or C++. They also consume much more memory. \" We repeated Prechelt's study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in execution speed; it also has significantly lower variability, which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important. Experiment Our data set consists of 16 programs written by 14 programmers. (Two programmers submitted more than one program, as was the case in the original study.) Twelve of the programs were written in Common Lisp (Steele 1990), and the other four were in Scheme (ACM 1991). All of the subjects were volunteers recruited from an Internet newsgroup. To the extent possible we duplicated the circumstances of the original study. We used the same problem statement (slightly edited but essentially unchanged), the same program input files, and the same kind of machine for the benchmark tests: a SPARC Ultra 1. The only difference was that the original machine had 192 MB of RAM and ours had only 64 MB; however , none of the programs used all the available RAM, so the results should not have changed. Common Lisp benchmarks were run using Allegro CL 4.3. Scheme benchmarks were run using MzScheme (Flatt 2000). All the programs were compiled to native code. Figure 1: Experimental results. The vertical lines from left to right indicate, respectively, the 10th percentile, median, and 90th percentile. The hollow box encloses the 25th to 50th percentile. The thick grey line is the width of two standard deviations centered on the mean.","PeriodicalId":8272,"journal":{"name":"Appl. Intell.","volume":"30 1","pages":"21-24"},"PeriodicalIF":0.0000,"publicationDate":"2000-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"16","resultStr":"{\"title\":\"Point of view: Lisp as an alternative to Java\",\"authors\":\"E. Gat\",\"doi\":\"10.1145/355137.355142\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"I n a recent study Prechelt (1999) compared the relative performance of Java and C++ in execution time and memory usage. Unlike many benchmark studies, Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill. Prechelt concluded that \\\" as of JDK 1.2, Java programs are typically much slower than programs written in C or C++. They also consume much more memory. \\\" We repeated Prechelt's study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in execution speed; it also has significantly lower variability, which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important. Experiment Our data set consists of 16 programs written by 14 programmers. (Two programmers submitted more than one program, as was the case in the original study.) Twelve of the programs were written in Common Lisp (Steele 1990), and the other four were in Scheme (ACM 1991). All of the subjects were volunteers recruited from an Internet newsgroup. To the extent possible we duplicated the circumstances of the original study. We used the same problem statement (slightly edited but essentially unchanged), the same program input files, and the same kind of machine for the benchmark tests: a SPARC Ultra 1. The only difference was that the original machine had 192 MB of RAM and ours had only 64 MB; however , none of the programs used all the available RAM, so the results should not have changed. Common Lisp benchmarks were run using Allegro CL 4.3. Scheme benchmarks were run using MzScheme (Flatt 2000). All the programs were compiled to native code. Figure 1: Experimental results. The vertical lines from left to right indicate, respectively, the 10th percentile, median, and 90th percentile. The hollow box encloses the 25th to 50th percentile. The thick grey line is the width of two standard deviations centered on the mean.\",\"PeriodicalId\":8272,\"journal\":{\"name\":\"Appl. Intell.\",\"volume\":\"30 1\",\"pages\":\"21-24\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2000-12-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"16\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Appl. Intell.\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/355137.355142\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Appl. Intell.","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/355137.355142","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
I n a recent study Prechelt (1999) compared the relative performance of Java and C++ in execution time and memory usage. Unlike many benchmark studies, Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill. Prechelt concluded that " as of JDK 1.2, Java programs are typically much slower than programs written in C or C++. They also consume much more memory. " We repeated Prechelt's study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in execution speed; it also has significantly lower variability, which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important. Experiment Our data set consists of 16 programs written by 14 programmers. (Two programmers submitted more than one program, as was the case in the original study.) Twelve of the programs were written in Common Lisp (Steele 1990), and the other four were in Scheme (ACM 1991). All of the subjects were volunteers recruited from an Internet newsgroup. To the extent possible we duplicated the circumstances of the original study. We used the same problem statement (slightly edited but essentially unchanged), the same program input files, and the same kind of machine for the benchmark tests: a SPARC Ultra 1. The only difference was that the original machine had 192 MB of RAM and ours had only 64 MB; however , none of the programs used all the available RAM, so the results should not have changed. Common Lisp benchmarks were run using Allegro CL 4.3. Scheme benchmarks were run using MzScheme (Flatt 2000). All the programs were compiled to native code. Figure 1: Experimental results. The vertical lines from left to right indicate, respectively, the 10th percentile, median, and 90th percentile. The hollow box encloses the 25th to 50th percentile. The thick grey line is the width of two standard deviations centered on the mean.