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 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!news3.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 23 Mar 2010 18:52:37 +0100 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? References: <4BA8BA91.4050905@cherrystonesoftware.com> <4ba8c0f5$0$6984$9b4e6d93@newsspool4.arcor-online.net> <07c318a0-2644-4c02-9447-ed75d9cb3485@g28g2000yqh.googlegroups.com> In-Reply-To: <07c318a0-2644-4c02-9447-ed75d9cb3485@g28g2000yqh.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4ba8ffe6$0$6770$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 23 Mar 2010 18:52:38 CET NNTP-Posting-Host: 87937a11.newsspool3.arcor-online.net X-Trace: DXC=YT\l@A6hMcX1`E>oC;JXEZMcF=Q^Z^V3X4Fo<]lROoRQ8kFZLh>_cHTX3j]Y[[gkYhnCgX X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.eiffel:521 comp.lang.ada:9704 comp.lang.modula3:141 comp.programming:14640 Date: 2010-03-23T18:52:38+01:00 List-Id: Maciej Sobczak schrieb: > On 23 Mar, 14:24, Georg Bauhaus wrote: > >> Note: Cherrystonesoftware markets a product that is not available >> with Java, C#, or other languages. > > Are they supposed to make products for those platforms that they > consider inferior? Why? If only it was stated like this. Anyway, the test cases are interesting for other reasons: Yes, the language implementation matters. E.g., does your JIT compile to MMX or SQRT hardware instructions when running the prime number algorithm? Can you share data efficiently across multiple processors in non-augmented C99 or in Ada? When deciding for/against a programming language, based on likely application performance, it seems equally important to look at some more things. One example is memory management in muticore programs. It seems like malloc() is beginning to show its sequential heritage, with memory management becoming a messy resource conflict, making multithreaded programs slow. This is when VMs using JIT compilers (or programs employing a non-language allocation library...) stand a chance of being faster: they may have built in memory management for multiple processors. Languages like C don't---Cherrystone offers one example. Another benchmarks currently shows rather inconclusive, but instructive results. The same program is run on a single core and on a multicore CPU http://shootout.alioth.debian.org/u64/performance.php?test=chameneosredux http://shootout.alioth.debian.org/u64q/performance.php?test=chameneosredux Thus, I think, language choice may well depend on considering more than massive close-to-the-register CPU operation efficiency. Even when it destroys one's presumptions (that C++, Ada, Eiffel, Modula-3, Fortran, etc. somehow must always be fastest).