From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Thread: 1008e3,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Thread: 108717,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,gid8d81cdf253,gid5b1e799cdb,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!j21g2000yqh.googlegroups.com!not-for-mail From: Andrea Taverna Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Fri, 26 Mar 2010 17:53:15 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <4BA8BA91.4050905@cherrystonesoftware.com> <4BA8F677.3090206@adalog.fr> <4BA8FD54.8020200@cherrystonesoftware.com> NNTP-Posting-Host: 151.47.209.118 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1269651195 11143 127.0.0.1 (27 Mar 2010 00:53:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 27 Mar 2010 00:53:15 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: j21g2000yqh.googlegroups.com; posting-host=151.47.209.118; posting-account=q_H03goAAABDwevycEkYzGRVjq5lpBVA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.1.8) Gecko/20100216 Fedora/3.5.8-1.fc11 Firefox/3.5.8,gzip(gfe) Xref: g2news1.google.com comp.lang.eiffel:546 comp.lang.ada:9790 comp.lang.modula3:166 comp.programming:14692 Date: 2010-03-26T17:53:15-07:00 List-Id: On 23 Mar, 13:31, balson wrote: > > > Where's performance on this list? Do you not care how fast the > applications run? Yes, I do, but there's a somewhat famouse quote I'd tend to agree with: /While hardware computing horsepower increases at roughly 60%/year, compiler optimizations contribute only 4%. Basically, compiler optimization work makes only marginal contributions. This means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena. (Probesting's Law)./ > Look at the following white paper to see if > performance should or shoild not be high on your list if you are > considering changing development languages: > > http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf With respect to that paper, it fails to account that Java and C# are quite different from the other alternatives I listed. More precisely, C#/Java may be required to perform a lot of checks to ensure "safety" in a very high level sense and both strive to offer a C-like alternative to C++ for some kinds of applications. Ada, CL, M3 and Pascal were designed with quite different goals that are likely to make them easier to optimize than the former two. As an example, I run your insertion-sort benchmark with the following implementations: - C with gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) - Ada with gcc GNAT, compiled with flags -gnatp and -O2 - Common Lisp SBCL 1.0.33, compiler directives are in the source code, the "usual" (speed 3) (space 0) (safety 0) on an Acer Aspire 3000 with 500MB RAM and processor AMD Sempron 3100+ 1.6GHz with Fedora Core 11 installed. Source for Ada and Lisp benchmark can be found here http://pastebin.org/125192 and here http://pastebin.org/125194 respectively. (ALERT: I'm a noob, at least in Ada and Lisp, so the code might be ugly has hell, but, hopefully, correct) The results: [Size] 100'000 200'000 400'000 /Lang] C 23.36 144.90 521.38 Lisp 40.74 147.97 692.51 Ada 22.88 112.92 488.69 [secs] [...] > I included Pascal because once you get up into languages that do bounds > checking, performance will degrade. Being a student, I'm almost ignorant on how coding is supposed to work outside academia, still I'm not convinced on this. For one, some of the languages I listed encourage the use of special idioms for accessing arrays s.t. such accesses are provably correct and efficient, e.g. Ada: for I in V'Range loop .... Lisp: (loop :with n := (length v) :for i :from 0 :below n :do.... ; not sure about this idiom ... and, as other have said, most of the implementation of those languages, with, IIRC, the exception of Java and C#, allow you to turn off those or all of the run-time checks for production code. > Pascal is one of those languages > that does bounds checking. It comes down to this: > > a) Either the programmer writes code to not exceed array bounds, or > b) Use a language that does it for you. But, well, there are other options! c) use a language that help you write correct code seems a viable one. Historically Pascal and the likes cared about providing the programmer a good deal of elementary tools, such as *true arrays*, C/C++ never provided that. Pascal-like languages have had *optional* run-time checks on array access for a long time. But I have seen lot of C/C++ code written by "experts" that followed the Greenspun's 10th rule. They wrote string/number munching code and invented their own run-time checks, so there's also d) write your own checks in a language that provides none Andrea